3GPP requirements to SIP, IETF 52

Download Report

Transcript 3GPP requirements to SIP, IETF 52

3GPP requirements to SIP
draft-garcia-sipping-3gpp-reqs-02.txt
Miguel A. Garcia
mailto:[email protected]
Background information


3GPP IP Multimedia Subsystem architecture
and issues, presentation in IETF 51st in
London,
http://www.softarmor.com/sipping/meets/ietf
51/slides/pres-drage-3gpp-arch3-sippingietf51.ppt
3GPP dependencies on IETF (living
document),
http://www.3gpp.org/TB/Other/IETF.htm
Session release (6.14)







Problem: phone dies or administrative disconnection
Must release network resources, stop billing
Network layer 2 can detect and report a dead phone
How to use this information at application layer?
Requires fine granularity (not session timer)
Requires feature transparency (not B2BUA)
Proposals:



Use SUBSCRIBE/NOTIFY (complex solution)
Use another protocol (why)
A proxy sends BYEs (preferred by 3GPP)
Inbound scenario (MT)



Initial message reaches home proxy
Home proxy retargets to registered contact
Message must visit specific remote proxies
before reaching the phone



topology hiding
compression, etc
Proposal

Home proxy stores path and appends it as a
service route on initial message
Outbound scenario (MO)


Phone uses outbound proxy rule to send
message to visited proxy
Message must visit a set of proxies before
reaching final destination



Services provided by home proxy
Services are independent of roaming
Proposal

Visited proxy stores path on registration, appends
as service route on initial message
Remote proxy service (6.15)
Initial requests must visit dynamically assigned
service proxies that can be more than one proxy
hop away
How to discover the set of hops (vector)
How to traverse the vector
Proposals:

1.
2.





3GPP Path header (solves 1)
Preloaded route header (solves 2)
Loose routing parameter in Route header (solves 2)
Service-Route header (solves 2)
Additional signaling information



Need to transport (in existing messages)
additional signaling information between the
mobile and the proxies or between proxies
Examples: Cell-ID (6.13), Visited network
name (6.3.5), Charging-IDs (6.18).
Possible solutions:



Another body (not suitable for the air interface)
Another protocol (why?)
New headers (preferred)
Extensible authentication



Or providing support for past and future
authentication schemes (6.23.1)
Security always needs setup/infra
Undesirable to change the infrastructure




Most of the cost is in the cards, processes …
3GPP requirement on being able to use SIM cards
Only place for a single card, undesirable to have additional
user configurations
Proposal

HTTP Extensible Authentication Protocol (EAP)
Authentication (6.23.2.3)





Want to avoid extra roundtrips (both INVITE and
towards AAA), computation
Initial authentication followed by lower-cost
protection for subsequent signaling
Long term keys are stored outside the SIP server
This issue is raised in both security frameworks
Proposal

Authenticate the first SIP message (typically REGISTER) +
security association between proxies and UA

Enhanced integrity protection in HTTP digest
Picking security scheme (6.23.3)





Or making SIP aware of security in the path
Digest is vulnerable to MitM attack
SIP has many security methods, how to choose
between these
Large, long-lasting deployments can’t switch to new
sw/new policy; still want to use new equipment and
avoid MitM
Proposals:


NEGOTIATE (does not prevent MitM)
Security agreement: draft-arkko-sip-sec-agree-00.txt
Security in the phone (6.23.4)



Can’t have public key operations, PKI
deployment, extra roundtrips, TCP only
operation
Hop-by-hop solves only part of the problem.
Need for end-to-end and end-to-middle
protection
Proposal

Extended digest to improve integrity protection
(not just hop-by-hop) draft-sen-sipping-onehopdigest-00.txt
Conclusion

We will work on the following I-Ds:







PATH header
Source loose routing (rolled into bis?)
Cell-ID, visited network name, charging-ID
headers
Network initiated session release (rolled into bis?)
HTTP extensible authentication protocol
Security agreement
One hop digest