Internet Engineering Task Force Duncan Mills Internet Draft Vodafone draft-mills-sip-access-network-info-02.txt Date: May 2002 Expires: November 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 mechanism is useful in SIP networks that provide layer 2/layer 3 connectivity through different access technologies. SIP User Agents This document defines the private SIP extension header P-Access- Network-Info. may use this header to relay information about the access technology 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. Applicability Statement This mechanism is suitable where: a) a UA needs to send to a proxy in its home network, information pertaining to the access network Mills Expiration 11/28/02 1 Internet-Draft The SIP Access-Network-Info header May 2002 through which it reaches that home network; and b) there is transitive trust in intermediate proxies between the UA and the home network proxy via established relationships between the home network and the access network, and generally supported by the use of standard security mechanisms, e.g. IPsec, AKA, and TLS. 3. 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. 4. Table of Contents Status of this Memo 1 1. Abstract 1 2. Applicability Statement 1 3. Conventions used in this document 2 4. Table of Contents 2 5. Introduction 2 6. Overview 2 7. The P-Access-Network-Info header 3 8. Handling of the P-Access-Network-Info header 5 8.1 UAC behavior 5 8.2 Proxy behavior 5 9. Security considerations 5 10. IANA Considerations 6 11. References 7 12. Author's Address 7 Full Copyright Statement 7 5. 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 the network providing the layer 2/layer 3 IP connectivity which in turn provides a user with access to the SIP capabilities or services provided by the home network of that user. 6. 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, Mills Expiration 11/28/02 2 Internet-Draft The SIP Access-Network-Info header May 2002 the type of access being used may influence home network decisions on what level of security to apply to sessions. In other cases, the home network may simply wish to know crude location information in order to provide certain services to the user. For example, many of the location based services available in wireless networks today require the home network to know the identity of the cell the user is being served by. Some regulatory requirements exist mandating that for cellular radio systems, the identity of the cell where an emergency call is established is made available to the emergency authorities. 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. 7. 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 proxies in the home network. The proxy in the home network may act upon any information in the P- Access-Network-Info header if it is present, to provide a different service depending on the network through which the UA is accessing the server. For example, for cellular radio access networks the home network may use the cell ID to provide basic localised services. A proxy in the home network MUST delete the header before forwarding the message outside of its own administrative network domain or outside a trusted administrative network domain. Some systems may require that the P-Access-Network-Info header is only sent by the UAC when a secure connection to the proxy in the home network is present. For example, in 3GPP systems, the UAC MUST NOT send this header in the initial unauthenticated REGISTER request. 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]: Mills Expiration 11/28/02 3 Internet-Draft The SIP Access-Network-Info header May 2002 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-access-info extension-access-info = gen-value 3gpp-cgi = "3gpp-cgi" EQUAL (token / quoted-string) 3gpp-utran-cell-id = "3gpp-utran-cell-id EQUAL (token / 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. The following table expands on tables 2 and 3 in [3]. Mills Expiration 11/28/02 4 Internet-Draft The SIP Access-Network-Info header May 2002 Header field where proxy ACK BYE CAN INV OPT REG ---------------------------------------------------------------- P-Access-Network-Info dr - o - o o o PRA UPD SUB NOT INF REF ---------------------------- o o o o o o Comparisons follow the case-sensitivity rules defined by SIP [3]. 8. Handling of the P-Access-Network-Info header 8.1 UAC behaviour 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 inserting this information MUST trust the home network 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 home network 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. This document does not define either the nature of the information or the messages where the P-Access-Network-Info needs to be inserted. The UA should only use the P-Access-Network-Info header in messages that are to be sent to the home network proxy over a secure connection. For example, even in a private system like 3GPP, the UAC should not use the P-Access-Network-Info header in the initial unauthenticated unprotected REGISTER request. 8.2 Proxy behavior A proxy MUST NOT insert or modify the P-Access-Network-Info header. A proxy, typically located in the home network, and therefore trusted, MUST delete the header when the SIP signaling is forwarded to a SIP server located in a non-trusted administrative network domain. The access network information is used by a home network and is of no interest to the destination network. 9. 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 7. Mills Expiration 11/28/02 5 Internet-Draft The SIP Access-Network-Info header May 2002 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 trusted administrative network domain. The home network uses the information contained in this header to provide additional services and UAs are expected to provide correct information. However, there are no security problems resulting from a UAC inserting incorrect information. Networks providing services based on the information carried in the P-access-network-info header will therefore need to trust the UAC sending the information. A rogue UAC sending false access network information will do no more harm than to restrict the user from using certain services. The mechanism provided in this document is designed primarily for private systems like 3GPP. Most security requirements are met by way of private standardised solutions. For instance, 3GPP will use the P-Access-Network-Info header to carry relatively sensitive information like the cell ID. Therefore the information MUST NOT be sent outside of the 3GPP domain. Section 8.2 of this document satisfies this requirement. The UAC is aware - if it is a 3GPP UAC - that it is operating within a trusted domain. The 3GPP UAC is aware of whether or not a secure connection to the home network domain for transporting SIP signalling, is currently available, and as such the sensitive information carried in the P- Access-Network-Info header should not be sent in any initial unauthenticated and unprotected requests (e.g. REGISTER). This is stated in section 8.1 of this document. Any UAC that is using this extension and is not part of a private trusted domain should not consider the mechanism as secure and as such SHOULD NOT send sensitive information in the P-Access-Network- Info header. Any proxy that is operating in a private trust domain where the P- Access-Network-Info header is supported is required to delete the header, if it is present, from any message prior to forwarding it outside of the trusted domain. This is stated in section 8.2. Therefore, a home network that requires its UACs to send information in the P-access-network-info header must ensure that either that information is not of a sensitive nature or that the information is not sent outside of the trust domain. A proxy receiving a message containing the P-Access-Network-Info header from a non-trusted entity is not able to guarantee the validity of the contents. Mills Expiration 11/28/02 6 Internet-Draft The SIP Access-Network-Info header May 2002 10. 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. 11. 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. 12. 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 Mills Expiration 11/28/02 7 Internet-Draft The SIP Access-Network-Info header May 2002 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." Mills Expiration 11/28/02 8