Network Working Group M. Garcia Internet Draft Ericsson Expires: December 2002 June 2002 Private Session Initiation Protocol (SIP) extension for Visited Network Identifier Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This memo describes a private extension to SIP in the form of a P-Visited-Network-ID header. The contents of the header identify each of the visited networks the message traversed en-route to the home network. Table of contents 1. Introduction......................................................2 2. Applicability statement...........................................2 Network Working Group Expiration 12/04/02 [Page 1] Garcia The SIP Visited Network ID header June 2002 3. The Visited Network Identifier header.............................3 4. P-Visited-Network-ID syntax and definition........................3 5. Usage.............................................................5 5.1 Procedures at the UA.............................................5 5.2 Procedures at the registrar and proxy............................5 6. Security Considerations...........................................5 7. IANA Considerations...............................................5 8. Author's Addresses................................................6 9. Acknowledgements..................................................6 10. References.......................................................6 10.1 Normative references............................................6 10.2 Informative references..........................................6 1. Introduction The 3rd Generation Partnership Project (3GPP) has chosen SIP [1] as the signaling protocol for the IP Multimedia Subsystem (IMS). A collection of 3GPP requirements related to SIP are stated in the "3GPP requirements to SIP" [2]. 3GPP networks are composed of a collection of so called home networks, visited networks and subscribers. A particular home network may have roaming agreements with one or more visited networks. This has the effect that when a mobile terminal is roaming, it can use resources provided by the visited network in a transparent fashion. One of the conditions for a home network to accept a mobile roaming to a particular visited network is the presence of a roaming agreement between the home and the visited network. There is a need to indicate to the home network which is the visited network that the terminal is using. 3GPP terminals always register to the home network. The REGISTER request is proxied by the visited network to the home network. In the sake of a simple approach, it seems sensible that the visited network includes an identification that is known at the home network. This identification takes the form of a quoted text string or a token. The home network may use this identification to verify the existence of a roaming agreement with the visited network, and to authorize the registration through that visited network. 2. Applicability statement The P-Visited-Network-ID is applicable whenever the following circumstances are met: 1. There is transitive trust in intermediate proxies between the UA and the home network proxy via established relationships between the home network and the visited network, and generally supported by the use of standard security mechanisms, e.g. IPsec, AKA, or TLS. Network Working Group Expiration 12/05/02 [Page 2] Garcia The SIP Visited Network ID header June 2002 2. An endpoint is using resources provided by one or more visited networks (a network to which the user does not have a direct business relationship). 3. A proxy that is located in one of the visited networks wants to be identified at the user's home network. 4. There is no requirement that every visited network needs to be identified at the home network. Those networks that want to be identified make use of the extension defined in this document. Those networks that do not want to be identified do nothing. 5. A commonly pre-agreed text string or token identifies the visited network at the home network. 6. The UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone request outside a dialog (e.g., MESSAGE [8]) to a proxy in a visited network. 7. The request traverses, en route to its destination, a proxy in the home network, or its destination is the registrar in the home network. 8. The registrar or home proxy verifies and authorizes the usage of resources (e.g., proxies) in the visited network. 3. The Visited Network Identifier header The P-Visited-Network-ID header field is used to convey to the registrar or home proxy in the home network the identifier of a visited network. The identifier is a text string or token that is known by both the registrar or the home proxy at the home network and the proxies in the visited network. Typically, the home network authorizes the UA to roam to a particular visited network. This action requires an existing roaming agreement between the home and the visited network. The Visited Network Identifier header is populated with a quoted text string or token that identifies the proxy network at the home network. Someone could argue that it is possible for a home network to identify one or more visited networks by inspecting the domain name in the Via header fields. However, this solution is not reliable, as it has a heavy dependency on DNS. It is an option for a proxy to populate the via header with an IP address, for example, and in the absence of a reverse DNS entry, the IP address will not convey the desired information. 4. P-Visited-Network-ID syntax and definition This document defines a new SIP header field named P-Visited-Network- ID. The syntax of the P-Visited-Network-ID header is based on the ABNF of SIP [1] and its syntax described as follows: P-Visited-Network-ID = "P-Visited-Network-ID" HCOLON vnetwork *(COMMA vnetwork) Network Working Group Expiration 12/05/02 [Page 3] Garcia The SIP Visited Network ID header June 2002 vnetwork = (token / quoted-string) *(SEMI vnetwork-param) vnetwork-param = generic-param Example: P-Visited-Network-ID = "Network number 1", Other-Network Any SIP proxy that receives a REGISTER request, a standalone request outside a dialog (e.g., MESSAGE [8]), or a request that initiates a dialog, MAY insert a P-Visited-Network-ID header when it forwards the request. In case a REGISTER or other request is traversing different administrative domains (e.g., different visited networks), a SIP proxy may insert a new P-Visited-Network-ID header if the request does not contain a P-Visited-Network-ID header with the same network identifier as its own network identifier (e.g., if the request has traversed other different administrative domains). Note also that, there is not requirement for the header to be readable in the proxies. Therefore, a first proxy may insert an encrypted header that only the registrar can decrypt. If the request traverses another proxy (e.g., a second proxy) located in the same administrative domain as the first proxy, the second proxy will not be able to read the contents of the P-Visited-Network-ID header. In this situation, the second proxy will consider that its visited network identifier is not already present in the value of the header, and therefore, it will insert a new P-Visited-Network-ID header value (hopefully with the same visited network identifier). When the request arrives at the registrar, it will notice that the header value is repeated (both the first and the second proxy inserted it). The decrypted values should be the same, because both proxies where part of the same administrative domain. While this situation is not desirable, it does not create any harm at the registrar. The P-Visited-Network-ID is normally used at registration. However, this extension does not preclude other usages. For instance, a proxy in a visited network that does not maintain registration state may insert a P-Visited-Network-ID header into any standalone request outside a dialog or a request that creates a dialog. At the time of writing this document, the only requests that create dialogs are INVITE [1], SUBSCRIBE [2] and REFER [9]. Table 1 below is an addition of the P-Visited-Network-ID to the Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [4], tables 1 and 2 in the SIP INFO method [5], tables 1 and 2 in Reliability of provisional responses in SIP [6], tables 1 and 2 in the SIP UPDATE method [7], tables 1 and 2 in the SIP extension for Instant Messaging [8] and table 1 in the SIP REFER method [9]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Visited-Network-ID R ad - - - o o o Network Working Group Expiration 12/05/02 [Page 4] Garcia The SIP Visited Network ID header June 2002 Header field SUB NOT PRA INF UPD MES REF _______________________________________________________________ P-Visited-Network-ID o - - - - o o Table 1: Header field support 5. Usage 5.1 Procedures at the UA This memo does not define any procedure at the UA. The UA MUST NOT insert the P-Visited-Network-ID header. 5.2 Procedures at the registrar and proxy A proxy that is located in a visited network MAY insert a P-Visited- Network-ID header field in any of the requests indicated in the Table 1. The header is populated with the contents of a text string or a token that identifies the administrative domain of the network where the proxy is operating at the user's home network. The home proxy or registrar in the home network may use the contents of the P-Visited-Network-ID as an identifier of one or more visited networks that the request traversed. The home proxy or registrar may take local policy driven actions based on the existence or not of a roaming agreement between the home and the visited networks. This means, for instance, authorize the actions of the request based on the contents of the P-Visited-Network-ID header. A home proxy MUST delete this header when forwarding the message outside the home network administrative domain, in order to retain the user's privacy. A home proxy SHOULD delete this header, even when the request is not forwarded outside the home network administrative domain, when the home proxy has used the contents of the header or the request is routed based on the called party. 6. Security Considerations For this mechanism to work, it is assumed that there is trust relationship between a home network and one or more transited visited networks. It is possible for other proxies between the proxy in the visited network that inserts the header, and the registrar or the home proxy, to modify the value of P-Visited-Network-ID header. It is therefore desirable to apply an integrity protection mechanism such us IPsec or other available mechanisms in order to prevent such attacks. 7. IANA Considerations Network Working Group Expiration 12/05/02 [Page 5] Garcia The SIP Visited Network ID header June 2002 This document defines the SIP extension header "P-Visited-Network-ID" which should be included in the registry of SIP headers defined in SIP [1]. As required by the SIP change process [4] the SIP extension header name "Visited-Network-ID" should also be registered in association with this extension. The following is the registration for the P-Visited-Network-ID header field: RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: P-Visited-Network-ID Compact Form: none The following is the registration for the Visited-Network-ID header field: RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] (not yet specified, only reserved) Header Field Name: Visited-Network-ID Compact Form: none 8. Author's Addresses Miguel A. Garcia Ericsson FIN-02420, Jorvas, Finland Tel: +358 9299 3553 e-mail: miguel.a.garcia@ericsson.com 9. Acknowledgements The author would like to thank Andrew Allen, Gabor Bajko, Gonzalo Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Ya-Ching Tan and the 3GPP CN1 WG members for the comments on this document. 10. References 10.1 Normative references 1. J. Rosenberg, H. Schulzrinne, G. Camarillo et al, Session Initiation Protocol, RFC 3261, March 2002. 10.2 Informative references 2. M. Garcia et al, 3GPP requirements on SIP, draft-garcia-sipping- 3gpp-reqs-03.txt, work in progress. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. Network Working Group Expiration 12/05/02 [Page 6] Garcia The SIP Visited Network ID header June 2002 3. S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, D. Willis, SIP change process, draft-tsvarea-sipchange-01.txt, February 2002, work in progress. 4. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. 5. S. Donovan, The SIP INFO method, RFC 2976, October 2000. 6. J. Rosenberg, H. Schulzrinne, Reliability of Provisional Responses in SIP, RFC 3262, March 2002. 7. J. Rosenberg, The Session Initiation Protocol UPDATE Method, draft-ietf-sip-update-02.txt, April 2002, work in progress. 8. B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, Session Initiation Protocol Extension for Instant Messaging, draft-ietf-sip-message-04.txt, May 2002, work in progress. 9. R. Sparks, The SIP Refer method, draft-ietf-sip-refer-05.txt, June 2002, work in progress. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Expiration Date This memo is filed as and expires December 5, 2002. Network Working Group Expiration 12/05/02 [Page 7]