Sipping J. Arauz Internet-Draft Ericsson Expires: November 21, 2006 May 19, 2006 Registration Event Package Extension for Session Initiation Protocol (SIP) Temporarily Routeable User Agent URIs (TRUUs) draft-jarauz-sipping-truu-reg-event-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft defines an extension to RFC 3680 [2] for representing the TRUU(s) associated with registered contact addresses in registration event notifications. Arauz Expires November 21, 2006 [Page 1] Internet-Draft Reg Event TRUU Extension May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Notifier Processing of SUBSCRIBE Requests . . . . . . . . . . 3 5. Notifier Generation of NOTIFY Requests . . . . . . . . . . . . 3 6. Subscriber Processing of NOTIFY Requests . . . . . . . . . . . 3 7. Sample reginfo Document . . . . . . . . . . . . . . . . . . . 3 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Example: Implicit Registration . . . . . . . . . . . . . . 4 9. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Arauz Expires November 21, 2006 [Page 2] Internet-Draft Reg Event TRUU Extension May 2006 1. Introduction The addition of TRUU (Temporarily Routable User-agent URI) support to the REGISTER transaction, defined in [3], introduces yet another element of state in the registrar. Subscribers to the registration event package [2] may need to have knowledge of the new state in certain situations. The most relevant amongst these situations is the IP Multi-media Subsystem (IMS). In IMS a User Agent (UA) is forced to access the SIP network through a single SIP proxy, and it must use the same proxy as long as it is registered. An IMS user may have several AoRs, e.g. one for friends and another one for business. When the IMS user registers her UA in the IMS using one of her AoRs, all the other AoRs associated to that user get implicitly registered as well. If a TRUU is requested and obtained for the explicitly registered AoR as part of the registration transaction, then additional TRUUs will also be needed for the implicitly registered AoRs. While assigning the additional TRUUs is straightforward, informing the registering UA of them is not. Moreover, the SIP proxy used by the registering UA to access the IMS must also be aware of the TRUUs associated to the registered AoRs since when a SIP request issued by a UA does include a TRUU as the only identification of the requesting user, since the proxy must add to the request the AoR to which the TRUU is associated to allow identity verification and charging within the IMS. In IMS, both the UAs and the SIP proxies used to access the IMS must subscribe to the 'reg' event, and subscriptions to the 'reg' event for an AoR result in notifications containing registration state for all the associated AoRs. The proposed extension provides a way to easily deliver the TRUUs associated to the AoRs to both the UE and the SIP proxy. The reg event package has provision for including extension elements within the element. This document defines a new element that may be used in that context to deliver the TRUU corresponding to the contact. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [1] Arauz Expires November 21, 2006 [Page 3] Internet-Draft Reg Event TRUU Extension May 2006 3. Description A new element () is defined which contains a TRUU. This optional element is included within the body of a NOTIFY for the "reg" event package when a TRUU is associated with the AoR. As many elements as TRUUs are associated to the AoR are included by the notifier. In this way both the AoR URI and its associated TRUU(s) are then available to the watcher. 4. Notifier Processing of SUBSCRIBE Requests Unchanged from RFC 3680 [2]. 5. Notifier Generation of NOTIFY Requests A notifier for the "reg" event package [2] SHOULD include the element when a TRUU is associated with that AoR. As many elements as TRUUs are associated to the AoR SHOULD be included by the notifier. When present, the element MUST be be positioned as an instance of the element within the element. 6. Subscriber Processing of NOTIFY Requests When a subscriber receives a "reg" event notification [2] with a containing a , it MAY use the TRUU instead of the corresponding when sending SIP requests to the contact. Subscribers that are unaware of this extension will, as required by [2], ignore the element. 7. Sample reginfo Document Note: This example and others in the following section are indented for readability by the addition of a fixed amount of whitespace to the beginning of each line. This whitespace is not part of the example. The conventions of [8] are used to describe representation of long message lines. The following is an example registration information document including the new element: Arauz Expires November 21, 2006 [Page 4] Internet-Draft Reg Event TRUU Extension May 2006 sip:user@192.0.2.1 1 300 sip:fsj5y8gh94vn4@example.com ;trid=1;truu-expires=100 sip:4895unifr8932@example.com ;trid=1;truu-expires=300 8. Examples Note: In the following examples the SIP messages have been simplified, removing headers that are not pertinent to the example. 8.1. Example: Implicit Registration In an IMS network, a UA may send a single register message, requesting assignment of a TRUU, as follows: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds7 From: ;tag=3n8cf To: Contact: ;expires=3600;trid=1 Route: Path: Require: path Proxy-Require: truu Content-Length: 0 The UE routes the request through the SIP proxy it knows it must use to access the IMS, in this case pcscf@foreign.net. Arauz Expires November 21, 2006 [Page 5] Internet-Draft Reg Event TRUU Extension May 2006 The response reports success of the registration and returns the TRUU(s) assigned for the explicitly registered AoR. It also indicates (via the P-Associated-URI header [6]) that there are other associated AoRs that may have been implicitly registered using the same contact. But each of those implicitly registered AoRs will have one or more unique TRUU(s) assigned, and there is no way defined to report that assignment in the response. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds7 From: ;tag=3n8cf To: ;tag=fj3894f Supported: path Require: truu Service-Route: Contact: ;expires=3600;trid=1 P-Associated-URI: , Indirect-Contact: ;trid=1;truu-expires=300 Content-Length: 0 The UA then subscribes to the 'reg' event package as follows: SUBSCRIBE sip:alice@example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds8 From: ;tag=fj34890c To: Route: Route: Event: reg Expires: 3600 Accept: application/reginfo+xml Contact: Content-Length: 0 (The successful response to the subscription is not shown.) Once the Arauz Expires November 21, 2006 [Page 6] Internet-Draft Reg Event TRUU Extension May 2006 subscription is established an initial notification is sent giving registration status. In IMS deployments the response includes, in addition to the status for the requested URI, the status for the other associated URIs. NOTIFY sip:wonderland.foreign.net SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pcscf.foreign.net;branch=z9hG4bKnashdq4 Via: SIP/2.0/UDP scscf1.example.com;branch=z9hG4bKnashdr2 From: ;tag=fj34890c To: ;tag=j23902 Subscription-State: active;expires=3600 Event: reg Content-Type: application/reginfo+xml Contact: Content-Length: (...) sip:wonderland.foreign.net 1 300 sip:fsj5y8gh94vn4@example.com ;trid=1;truu-expires=100 sip:4895unifr8932@example.com ;trid=1;truu-expires=300 sip:wonderland.foreign.net Arauz Expires November 21, 2006 [Page 7] Internet-Draft Reg Event TRUU Extension May 2006 sip:pefpqwhjiasdjl@example.com ;truu-expires=300 sip:wonderland.foreign.net sip:hcfnfiawlcadhvf@example.com ;truu-expires=300 The status indicates that the associated AoRs all have the same contact registered. It also includes the TRUUs that have been assigned to each AoR. The UA may then retain those TRUUs for use them when establishing dialogs instead of the corresponding AoRs. Notice how the explicitly registered AoR (sip:alice@example.com) does have two simultaneously active TRUUs. One of them will be valid during 100 seconds more only, while the other one will be valid during 300 seconds. This is because the UA has requested a new TRUU while a previously assigned one has not expired yet, hence the differences in life times. 9. XML Schema Definition A TRUU document is an XML document that MUST be well-formed and SHOULD be valid. TRUU documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying TRUU documents. The namespace URI for elements defined for this purpose is a URN, using the namespace identifier 'ietf'. This URN is: urn:ietf:params:xml:ns:gruuinfo Arauz Expires November 21, 2006 [Page 8] Internet-Draft Reg Event TRUU Extension May 2006 BEGIN END 10. IANA Considerations There are no IANA considerations associated with this specification. 11. Security Considerations Security considerations for the registration event package is discussed in RFC 3680 [2], and those considerations apply here. The addition of TRUU information to the registration event package provides a way for a subscriber to that package to find out the relationship between a TRUU and its associated contact address. The relationship between a contact address and an AoR is already part of the package so combining both relationships a subscriber has a way to find out also the AoR to which a TRUU is associated. Since the main motivation of TRUU is to provide privacy and disallow direct contact, the ability to discover the TRUU<->contact<->AoR associations defeats the purpose of TRUU. Therefore access to the registration event information MUST be restricted to trusted parties. Access MAY be allowed to non-trusted parties but in that case the TRUU information MUST be filtered out from the event information. 12. Acknowledgements This work is heavily based on a similar one carried out by Paul E. Kyzivat in relation to GRUU[9]. Arauz Expires November 21, 2006 [Page 9] Internet-Draft Reg Event TRUU Extension May 2006 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004. [3] Van Bemmel, J., "Obtaining and Using Temporarily Routable User Agent (UA) URIs (TRUU) in the Session Initiation Protocol (SIP)", draft-jbemmel-sip-truu-02 (work in progress), April 2006. [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 13.2. Informative References [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003. [7] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [8] Sparks, R., "Session Initiation Protocol Torture Test Messages", draft-ietf-sipping-torture-tests-09 (work in progress), November 2005. [9] Kyzivat, P., "Registration Event Package Extension for Session Initiation Protocol (SIP) Globablly Routeable User Agent URIs (GRUUs)", draft-ietf-sipping-gruu-reg-event-04 (work in progress), April 2006 Arauz Expires November 21, 2006 [Page 10] Internet-Draft Reg Event TRUU Extension May 2006 Author's Address Javier Arauz Ericsson Via de los Poblados 13 Madrid 28033 SPAIN Email: jesus.javier.arauz@ericsson.com Arauz Expires November 21, 2006 [Page 11] Internet-Draft Reg Event TRUU Extension May 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Arauz Expires November 21, 2006 [Page 12] Internet-Draft Reg Event TRUU Extension May 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Arauz Expires November 21, 2006 [Page 13]