Transcript ieprep - Columbia University

Requirements for prioritized
access to PSTN resources
Henning Schulzrinne
Columbia University
superset of
9 April 2016
draft-schulzrinne-ieprep-resource-req-00
Assumptions/Scope
 SIP endpoint wants to access restricted
(prioritized) resources on a circuit-switched
network
 Does not indicate request of IP resource
priority
– may not be available
– may not be necessary
 Examples: GETS, MLPP, eMLPP, ...
 Nothing to do with 112/911
 Also, possibly call from PSTN into SIP network
9 April 2016
Scenarios
SIP
RP-capable gateway
PSTN w/MLPP
GETS, ...
INVITE sip:[email protected]
INVITE tel:1-212-...
INVITE sip:[email protected]
SIP
ISUP
9 April 2016
does not know
destination
network (type)
GSM
Assumptions
 Call resource priority vs. call human priority
– resource priority  indicated by caller (callee can't
see)
– priority of call to caller: indication ("Priority",
content labeling) + callee call handling policy 
out of scope
 Resources:
– IP-to-PSTN gateway channels
– end-to-end PSTN circuits (PSTN network
congestion, not access congestion)
9 April 2016
Assumptions
 Call destination network type may be
unknown to caller
 Call destination does not identify PSTN
resource priority
 May want to reach "any of IEPREP type
1, type 2, ..."
 May have several orthogonal indications
of resource priority (eMLPP + GETS?)
9 April 2016
System assumptions
 What do we assume about the IP side?
– purpose-built: require certain capabilities
(signaling, resource reservation, security, ...)
– any network: use SIP application on standard
platform or plug in own SIP phone
• no network changes
• firewalls  may not allow protocols beyond SIP and RTP
– any SIP (pay) phone
• no modifications to SIP phone
• not much beyond two-stage dialing possible?
9 April 2016
General requirements
 Not specific to one domain (e.g., GETS)
 Not tied to existing PSTN authentication
mechanisms
 Use existing namespaces  different
authorities that manage
 Allow for default behavior
 Separation of indication and policy
– by reference (policy "flash"), not by value
("preempt all except class 'immediate', queue in
relationship to GETS calls, but cut off after 3
minutes and only allow low-bit rate audio")
9 April 2016
Requirement: Discovery and
negotiation
 Caller must be able to discover PSTN
resource priority capabilities
– determines authentication "hat"
– gateway needs for challenge
• "Resource priority FOO level 7 requires use of
BAR authentication"
 Network may disallow discovery
administratively  importance of call
routing
9 April 2016
Requirement: Testing
 Must be able to test largest possible
part of the system without ringing
actual destination
– Systems only used during emergencies are
less likely to work
– Exercise authentication and authorization
– Exercise call routing
9 April 2016
Requirement: Call routing
 Combine with call routing:
– req: specify logical destination, not physical
gateway
– resource priority requirement may enlarge
or constrain set of destinations
• e.g., additional special GETS-only gateway
• only certain gateways (carriers) are capable of
particular calls
– note: TRIP property?
– note: cf. SIP caller preferences
9 April 2016
Security requirements
 End-to-end strong authentication and
authorization of caller
– not just theft of service, but system
stability/performance issue
 Intermediate (proxy?) authentication
– delegate responsibility
– not all VoIP gateways may be
authentication-capable (many aren't)
– harden authentication  DOS attacks
9 April 2016
Security requirements
 Support authentication and authorization
beyond existing PIN schemes
 Authentication must be DOS-resistant
 Allow "early" authentication  cannot wait
until inside PSTN!
– authentication consumes packets vs. circuits
– minimize pre-authentication resource use
• authenticate call signaling, not just resource signaling
9 April 2016
Security requirements
 Do not tie resource priority namespace
to one authentication scheme
– different hardware types
• hard/soft SIP phone
• SIM-equipped cell phone
– from any black phone with dial pad to
smartcard- and biometrics-equipped
9 April 2016
Security requirements
 Cross-domain
– IP endpoint may be in different admin.
domain than gateway
 Require secrets not to be pre-installed
 useability from any device
 Authentication of PSTN gateway
– desirable; required?
9 April 2016
Privacy requirements
 Call content
– very likely  separate docs
 Signaling (resource and/or call setup)
– reveals communication relationships
– cannot rely on hop-by-hop
 Fact of IEPREP call
– sensitivity likely same (or lower) as call
signaling
9 April 2016