Internet Engineering Task Force Duncan Mills Internet Draft Vodafone draft-mills-sip-Access-Network-Info-00.txt Date: April 2002 Expires: October 2002 The SIP Access Network Info header Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. The distribution of this memo is unlimited. 1. Abstract This document defines the private SIP extension header P-Access-Network-Info. This mechanism is useful in SIP networks that are partitioned, such as 3G wireless networks which are partitioned at the SIP layer into "access" and "home" networks. SIP User Agents may use this header to relay information about the access network to serving proxies in their home network. The serving proxy may then use this information to optimize services for the UA. For example, a 3GPP terminal uses this header to pass information about the access network such as radio access technology and cell ID to its home service. 2. Conventions used in this document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Table of Contents Status of this Memo 1 1. Abstract 1 2. Conventions used in this document 1 3. Table of Contents 2 4. Introduction 2 5. Overview 2 6. The P-Access-Network-Info header 3 7. Handling of the P-Access-Network-Info header 4 7.1 UAC behavior 4 7.2 UAS behavior 4 7.3 Proxy behavior 5 8. Security considerations 5 10. References 5 11. Author's Address 6 Full Copyright Statement 6 4. Introduction There are many cases where a user is accessing their home network services via a particular access network. An example is a 3GPP wireless terminal that accesses a SIP server via the UMTS Radio Access Network. Other examples include a laptop connected to a wireless LAN at an airport, or a laptop connected to a local ISP from a hotel room. In this document we define an access network as any network that provides a user with access to the SIP capabilities or services provided by the home network of that user. 5. Overview In some cases, the home network may wish to know information about the type of access network that the UA is currently using. Some services are more suitable or less suitable depending on the access type, and some services are of more value to subscribers if the access network details are known in the home network. For instance, the type of access being used may influence home network decisions on what level of security to apply to sessions, or it may influence the value a home network chooses to use for default timers. In other cases, the home network may simply wish to know crude location information in order to provide certain basic services. In most cases, it may be desired that the home network have the knowledge of some information relating to the network that provided access to the service. This is achieved by defining a new private SIP extension header as defined in [3], P-Access-Network-Info. This header carries information relating to the access network between the UAC and its serving proxy in the home network. 6. The P-Access-Network-Info header The P-Access-Network-Info header is used to transport a set of parameters associated with the access characteristics of a particular network. The P-Access-Network-Info header MAY be inserted by a UA. Proxies, MUST NOT add to or modify the contents of the P-Access-Network-Info. The information in the P-Access-Network-Info is privacy sensitive. It is intended for use between the UA and its serving proxy. The serving proxy MUST delete this header before forwarding the message outside of the its domain. The UA inserting this information MUST trust the serving proxy to protect its privacy by deleting the header before forwarding the message outside of the home proxy’s domain. In order to do this it must also have transitive trust in intermediate proxies between it and the serving proxy. This trust is established by business agreements between the home network and the access network, and generally supported by the use of standard security mechanisms, e.g. IPsec, AKA, and TLS. The P-Access-Network-Info header is described using ABNF syntax. The following description of the ABNF syntax is based on the ABNF used for SIP [3]: P-Access-Network-Info = "Access-Network-Info" HCOLON access-network-information access-network-information = access-type [SEMI access-info] access-type ="IEEE-802.11a" | "IEEE-802.11b" | "3GPP-GERAN' | "3GPP-UTRAN-FDD" | "3GPP-UTRAN-TDD" | "3GPP-CDMA2000" | token access-info = "3GPP-CGI" | "3GPP-UTRAN-Cell-ID" | extension 3gpp-cgi = "3GPP-CGI" EQUAL quoted-string 3gpp-utran-cell-id = "3GPP-UTRAN-CELL-ID" EQUAL quoted string extension = token [EQUAL quoted-string] A UAC supporting this extension may be capable of accessing the services provided by its home network via one or more access technologies. Such a UAC must know the values to use for each type of supported access technology. The means of this determination are outside the scope of this document. The home network must know the possible values that a particular UA may use to populate the access-type and access-info fields. In other words, a home network with business agreements allowing users to access via a particular technology must be able to parse the P-Access-Network-Info header containing an access-type for that technology in order to use this information. For example, the access-type could read ‘IEEE-802.11b’. If a home network knows it has a business agreement with a W-LAN access network, it must be ready to understand the value ‘IEEE-802.11b’. Similarly, a UAC supporting this extension that can access via W-LAN must be able to insert the relevant value. Access-info could contain additional information relating to the access network. In particular, the contents of the access-info field may be dependent on the value of the access-type field. For example, where the access-type is ‘3GPP-GERAN’, the access-info SHALL be "3GPP-CGI". These conditions are defined elsewhere by proprietary users of this extension, e.g. by 3GPP. The following table expands on tables 2 and 3 in [3]. Header field where proxy ACK BYE CAN INV OPT REG ---------------------------------------------------------------- P-Access-Network-Info dr o o o o o o Comparisons follow the case-sensitivity rules defined by SIP [3]. 7. Handling of the P-Access-Network-Info header 7.1 UAC behavior A UAC that supports this extension and is willing to disclose the related parameters may insert the P-Access-Network-Info header in any SIP message request The UAC SHOULD insert this header only when it trusts both the access network and the home network. This document does not define either the nature or the information or the messages where the P-Access-Network-Info needs to be inserted. 7.2 UAS behavior A serving proxy that supports this extension and receives the P-Access-Network-Info header MAY use the contents to, e.g., provide a different service depending on the network through which the UA is accessing the server. A serving proxy that supports this extension deletes the P-Access-Network-Info header from a message before forwarding the message outside of the home network domain. The information carried in the header is used by the home network and is of no interest to the destination network. It is implied that a serving proxy using the information contained in this header has to trust the access network. 7.3 Proxy behavior A proxy MUST NOT insert or modify the P-Access-Network-Info header. A serving proxy, typically located in the home network, and therefore trusted, SHOULD delete the header when the SIP signaling is forwarded beyond the home network domain. The serving network information is used by a home network and is of no interest to the destination network. 8. Security considerations This extension assumes that the access network is trusted by the UA (because the UA’s home network has a trust relationship with the access network), as described in section 6. This extension assumes that the information added to the header by the UAC should be sent only to trusted entities and should not be used outside of the home network domain. The home network uses the information contained in this header to provide additional services or enhanced performance to the user, and UAs are expected to provide correct information. However, there are no security problems resulting from a UAC inserting incorrect information. This header SHOULD always be deleted by the serving network prior to forwarding it outside of the home network domain, as described in section 7. 9. IANA Considerations This document defines the SIP extension header "P-Access-Network-Info" which should be included in the registry of SIP headers defined in SIP [3]. As required by the SIP change process draft-tsvarea-sipchange [6] the SIP extension header name "Access-Network-Info" should also be registered in association with this extension. 10. References Normative References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3. Rosenberg, J. et al, "SIP, Session Initiation Protocol", RFC 3261, May 2002. 4. D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," RFC 2234, November 1997. Non-Normative References 1. Mankin, A., "SIP Change Process draft-tsvarea-sipchange", March 2002. 2. Garcia M. et al: "3GPP requirements on SIP", draft-garcia-sipping-3gpp-reqs-03.txt, September 2002, work in progress. 11. Author's Address Duncan Mills The Courtyard, 2-4 London Road Newbury Berkshire RG14 1JX Tel: +44 1635 676074 e-mail: duncan.mills@vf.vodafone.co.uk Full Copyright Statement "Copyright (C) The Internet Society (2000). 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."