1 / 12

3GPP requirements to SIP draft-garcia-sipping-3gpp-reqs-02.txt

3GPP requirements to SIP draft-garcia-sipping-3gpp-reqs-02.txt. Miguel A. Garcia mailto:miguel.a.garcia@ericsson.com. Background information.

bell
Télécharger la présentation

3GPP requirements to SIP draft-garcia-sipping-3gpp-reqs-02.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 3GPP requirements to SIPdraft-garcia-sipping-3gpp-reqs-02.txt Miguel A. Garcia mailto:miguel.a.garcia@ericsson.com

  2. Background information • 3GPP IP Multimedia Subsystem architecture and issues, presentation in IETF 51st in London, http://www.softarmor.com/sipping/meets/ietf51/slides/pres-drage-3gpp-arch3-sipping-ietf51.ppt • 3GPP dependencies on IETF (living document), http://www.3gpp.org/TB/Other/IETF.htm

  3. 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)

  4. 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

  5. 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

  6. 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: • 3GPP Path header (solves 1) • Preloaded route header (solves 2) • Loose routing parameter in Route header (solves 2) • Service-Route header (solves 2)

  7. 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)

  8. 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)

  9. 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

  10. 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

  11. 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-onehop-digest-00.txt

  12. 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

More Related