SIPPING 3FPP AD HOC Date: 20 March 2002 Location: Hilton Duluth
Moderator: Georg Mayer Scribe: Eric Burger
Three topics: Status Overview, Security and Authentication, and Path
Status Overview
The IMS is the enhanced-services, SIP-based network of 3GPP. Choices made so far: o SIP solution for IMS: - Loose routing, max-forwards, DTMF over RFC 2833 (not INFO) - Manyfolks-05 and Update under consideration (as just written; likely to be adopted). - Path header: still working on it, with IETF o Loose Service Binding - IMS built on Packet Switched (PS) 3GPP network - IMS is 100% SIP - SIP is throughout network; special stuff going on in IMS, however - IMS requires Registration - UMTS (PS outside IMS) does not need Registration
Juha: What can't I get without IMS extensions? Georg: Access to home network services when roaming Rohan: Two examples of value-added services (VAS): - Billing service (esp. roaming) - Only way to get media-appropriate QoS Juha describes that QoS done today in GPRS; lots of discussion between Juha, Miguel and Rohan, resulting in realization that QoS negotiation isn't an issue.
Markus: SIM-card authentication is a VAS Georg: This allows users (edge services) and service provider to provide SIM-card auth services
Privacy: - Privacy request in extra header - Issue: where is caller-identity transported? o If in FROM header, P-CSCF and S-CSCF would need to be able to modify it to hide identity o Discuss in IETF Jon: Thinks it is better to not change TO/FROM header because of interoperability problems outside IMS. Introduces concept of Privacy Server, which is more than a Proxy but less than a full B2BUA. Georg calls it a "transparent proxy". Dean: This protects signaling identity, but does not protect caller's IP address, as the media stream exposes it. It is the FROM header the user does not want the remote side to see. If I want to hide it, I can set it to "protected" or "anonymous". The point is the network should not let my identity slip out. The issue is, changing the FROM field is not what the *user* wants. Keith: Changing FROM/TO field breaks interop. Is this an issue? Dean: Gives example where it does, today. Keith: That is why we want to use RPID. Trusted network entities can still know who the caller is, while you can use fake FROM/TO fields. Jon: Today, anonymization is all or nothing: you can whack all the VIA's and hack the media stream addresses (enhanced) or nothing really useful (basic). Need something more than basic, but without having to modify the media stream. RPID is OK so long as it is network-generated and not end-user specifiable. Dean: If privacy set at handset, it should send FROM: anonymous@localhost and set Privacy header. Keith: Issue is what network requires anonymity. For example, there was a time when all calls from France to Germany had Caller ID blocked. Rohan: Is network-applied privacy still a requirement? Dean: P-CSCF could hand back "don't ever give out address" to handset. Georg: It's not that easy; take it to the list.
- XML Bodies & P-Headers 3GPP sent information as XML bodies in SIP messages. They are migrating signaling information to P-Headers. Information not SIP-related will still get carried in XML bodies. Cullen: What about cell ID? That has geoloc implications. Georg: That will be a P-Header Dean: That is OK, if not touched by a proxy. Georg: 3GPP "Proxies" won't :-) <Georg lists the P-Headers proposed by 3GPP> Rohan: Better to wait for "Originally Dialed Public User ID" for history work; it won't get approved in its current form as the work group is working on similar stuff. Keith: Everything related to billing must be completed by June. XML bodies work now, but stuff that impacts terminals should be nailed-down and correct. Cullen: Advantage of not hiding information in XML body is proxy performance (Dean earlier made that point). Other work group work on charging may conflict with P-Header. Georg: We need something now. <Take offline: discuss Originally Dialed Public User ID, Visited header, history issues.> Miguel: We need Originally Dialed ID for things like distinctive ring (work number vs. personal number). TO header is not satisfactory, as it may get changed by the network (e.g., adding/striping international access codes). Dean: What are the real requirements? Use cases? Especially for Forwarding and Secretary Answer? Georg: Will be in an I-D Keith: Use cases have been in drafts for quite a while.
Security: Mostly discussed in SIP WG meeting. 3GPP will vote next week on AKA via HTTP-Digest vs. IPSec (leaning towards IPSec in IETF) Issue: How to transport keys form S-CSCF to P-CSCF; thinking of P-Header Rohan: P-Header for is Informational, non-protocol machineray. Up to 3GPP for how to proceed.
Path Extension Open Issues – Dean Willis <See presentation; lots of animated graphics> Sriram: Why not just use NAT/Firewall solution? Dean: Doesn't work for multiple proxies Paul Rupsis: Doesn't firewall control proxy (FCP) have global address? Dean: No. Rohan: The Translate header only has the local address in a different form than the real address. It does not have the path to the address. Paul: Why not just hack SDP Dean: Doesn't work for NAT Cullen: Why not have FCP rewrite Contact? Dean: Doesn't work if E2E protecting Contact field, as it gets changed. Cullen: Why not compound Contact (with embedded route)? Dean: Breaks everything Cullen: Doesn't think it breaks anything
Proposal: Record-Route for Register Issue: What to call it? RegisterRecordRoute? Path? Juha: Proposed RegisterRecordRoute, as people know what RecordRoute is. Dean (& group): Long names are bad, especially for 3GPP. Can abbreviate as RRR. Paul: How is hacking Path different from hacking Content? Dean: Hmmmm. I think that's documented in the draft. Can't use IPSec beyond one hop, which forces digest authentication.
Open Issues: Q: Dean: Is it OK to follow OPES principle of letting end-user know that stuff is in the middle? A: Yes.
Q: Eric: OPES also says that the end user can bypass the intervening elements. A: True, but if you don't have a direct route to your home network, too bad.
Draft on service-route discovery uses P-Header because the path to the IMS may be different than the register path. Draft is on the softarmor site. Sriram: How is this different from 3GPP Path? Dean: Can have different routes between call proxy farm and service proxy farm. Cullen: Could Registrar, receiving Path A->B->C, return C2, C1, B, A? Dean: No. That would be evil. Juha: Can only take or drop information; you can't mangle it. Dean: AD's won't like it.
Rohan: Can we move forward with approach in IETF? If so, is it good enough for 3GPP? Dean: AD's seem to think it is OK. Miguel: Looks like it works. 3GPP may not think it is ideal, but if it works, 3GPP will use it. Keith: Looks like it is the same concept and information as the old 3GPP Path proposal. Since it essentially works the same, it looks good.
3GPP Ad Hoc Participants: [Transcription errors the fault of the scribe] Eric Burger eburger@snowshore.com Aki Nieman aki.neiman@nokia.com Vesa Torvinen vesa.torvinen@ericsson.fi Pekka Pessi Pekka.Pessi@nokia.com Jari Arkko jari.arkko@ericsson.fi Markus Isomaki markus.isomaki@nokia.com Krisztian Kiss krisztian.kiss@nokia.com Oliver Paridaons oliver.paridaons@alcatel.be Suresh Coroy suresh.coroy@alcatel.be Dirk Kroeselley dirk.kroeselley@mchp.siemens.de James Undery james@ubiquity.net Jo Hornsby jhornsby@ubiquity.net Marianne Lepp mlepp@juniper.net Keith Drage drage@lucent.com Hugh Shieh hugh.shieh@attws.com Tomi Mikkonen tomi.mikkonen@ssh.com Santhana Krishnasamy santhana.krishnasamy@rd.francetelecom.com Kue Wong jkwonge@nortelnetworks.com Ilkka Uusitalo ilkka.uusitalo@ericsson.fi Pete McCann mccap@lucent.com Juha Yericenn jh@sn.net Dave Anand danand@5by5networks.com Paul Francis francis@tahoenetworks.com Hakan Persson hakan.n.person@telia.se Bert Culpepper bert.culpepper@intervoice-brite.com Itamar Gilad itamag@radvision.com Goran Enenoth goran.enenoth@era.ericsson.se Zhigang Liu zhigang.c.liu@nokia.com Edwin Aoki aoki@aol.net Paul Reynolds paul.Reynolds@orange.co.uk Raziq Taqub ryaqub@eari.toshiba.com Sriram Paramerwar sriramp@nortelnetworks.com Don Estberg done@activate.net John Waclawsky jgw@cisco.com Mahfuzun Rahman mahfuz@research.panasonic.com Sathya Narayanan sathya@research.panasonic.com Paul Kyzivat pkyzivat@cisco.com Daniel Petrie dpetrie@pingtel.com Jiri Kuthan jkuthan@dynamicsoft.com Ernie Tacsik ernie.tacsik@nokia.com Wolfgang Beck beckw@t-systems.com Aushalom Houri aushalom@il.ibm.com Robert Patzer rpatzer1@email.mot.com Kari Laihonen kari.laihonen@sonera.com Jorge Cuellar Jorge.cuellar@mchp.siemens.de Mehmet Ersu mehmet@ersue.de Hannes Tschoteip hannes.tschofenig@mchp.siemens.de Phil Mart philipmart@verizon.com Prakash Sesha psesha@meginfo.com Carsten Bosmann cabo@tri.org Jorg Ott jo@ipdialog.com Ram Dantu rdantu@netrake.com Rohan Mahy rohan@cisco.com Dean Willis dwillis@dynamicsoft.com Mikko Lonnfors mikko.lonnfors@nokia.com Miguel A. Garcia miguel.a.Garcia@ericsson.com David Bryan dbryan@jasomi.com Gonzalo Camarillo gonzalo.camarillo@ericsson.com Christer Holmberg christer.holmberg@ericsson.com Alexandre Harmand alexandre.harmand@oz.com Duncan Mills duncan.mills@uf.vodafone.co.uk Atle Monrad atle.monrad@ericsson.com Mark Becktiann mark.becktiann@siemens.com
21 Mar 2002 21:06 -0600