Individual Submission G. Bajko Internet-Draft B. Patil Intended status: Standards Track T. Savolainen Expires: January 13, 2012 Nokia July 12, 2011 Security on Demand for Mobile IPv6 and Dual-stack Mobile IPv6 draft-bajko-mext-sod-02 Abstract Mobile IPv6 and Dual-stack Mobile IPv6 protocols require the signaling messages between the mobile node and home agent to be secured. However security for the user plane/traffic is optional and is a choice left to the mobile node. This document proposes extensions to Mobile IPv6 signaling which enables the user plane traffic to be secured on a need or on-demand basis. The mobile node or the home agent can request at any time security for the user plane traffic. Security for user plane traffic can be triggered as a result of policy or, mobility or, at the user's choice. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 13, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Bajko, et al. Expires January 13, 2012 [Page 1] Internet-Draft Mobile IPv6: Security on demand July 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. When to apply Security to user plane traffic . . . . . . . . . 4 3. Triggering user plane traffic security . . . . . . . . . . . . 4 4. Extensions to Mobile IPv6 . . . . . . . . . . . . . . . . . . . 5 4.1. Extensions to Binding Update and Binding Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 5 4.2. New binding Update Mobility Options . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Normative References . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Bajko, et al. Expires January 13, 2012 [Page 2] Internet-Draft Mobile IPv6: Security on demand July 2011 1. Introduction Mobile IPv6 [RFC3775] and Dual-stack Mobile IPv6 [RFC5555] provide the option to secure the user plane data between the Mobile Node (MN) and and the Home Agent (HA) when needed. The user plane traffic between the MN and HA is secured via an IPsec security association (SA) which is established between them specifically for the purpose of user plane data. IPsec is used for securing the user plane traffic when the security between the MN and HA is based on IPsec. However security between the MN and HA could also be enabled via other protocols. The MEXT WG is evaluating on an experimental basis various alternatives to IPsec such as the one specified in [I-D.ietf-mext-mip6-tls]. As per the current specifications for MIP6 and DSMIP6, security of the user plane traffic is optional. When the MN is attached to 3G/4G network such as HSPA, LTE or EV-DO, the MN may not require security for the user plane traffic since these networks already provide ciphering over the air-interface and deploy hop-by-hop security, which makes these networks secure. However the MN may attach to less secure or unsecured accesses such as wireless lan (WLAN) or it may roam in countries where the user may prefer the data between the MN and the HA to be encrypted (even when using cellular accesses). There is no solution in the protocol specification today which provides the capability to trigger the security for the user plane traffic on a need basis. The problem that is being addressed is the triggering of security for user plane traffic between the MN and HA on a need basis. Policy information at the MN or information provided to the MN via other means at the time of attachment may assist the MN to determine if security needs to be enabled for user plane traffic. The user may also consciously decide to enable security when attached to certain networks. Furthermore, the operator of HA may have policies that define when user plane security is to be used. This document describes a mechanism which can enable security for user plane traffic on-demand or need. An obvious implementation alternative would be to encrypt user plane traffic always (as is commonly done with VPN use-cases), but that would unnecessarily consume resources on the HA. For the HA operator there is clear economic incentive to encrypt user-plane data only when necessary. The MIP6/DSMIP6 protocols only provide a means to secure the user plane traffic but do not provide any mechanisms by which the security is triggered as a result of mobility or the MN attaching via different access networks. As per the current MIP6 [RFC3775] specification, only the MN has the Bajko, et al. Expires January 13, 2012 [Page 3] Internet-Draft Mobile IPv6: Security on demand July 2011 ability to enable security for user-plane traffic. The HA has no ability to force the MN to secure user traffic. 2. When to apply Security to user plane traffic An MN MUST have security for the control plane messages. Hence all signaling between the MN and HA are secured. The MN establishes an IPsec SA between itself and the assigned HA prior to sending a Binding Update. However, the MN is not required to establish an SA for securing the user plane traffic. It is up to the MN whether it establishes SAs for the control plane and user plane at the same time or if it only establishes the control plane SA. The MN may choose to establish the SA for user plane traffic at any time [RFC4877]. When the MN attaches to an access network, it is usually able to determine if the access network is viewed as trusted or untrusted. The MN can make this determination, for example, based on the PLMN ID of the cellular network; or wifi_SSID/MAC_address of a wifi network; or location information provided by the MN, or user input. The MN has either a stored policy about trusted and untrusted access networks or it may be provided with such information from policy stores such as the ANDSF [23.402] or AAA server at the time of network attachment. An interface exists generally between the policy store such as AAA or ANDSF and the Home Agent (HA). If the MN is attached to an access network which is viewed as trusted or where encryption is not allowed, the MN chooses not to secure the user plane traffic. If the MN is attached to an access network which is not trusted, the MN may want to secure its user plane traffic. The HA may also be able to determine from the source address of the binding update (BU) message the access network to which the MN is currently attached. Based on this information, the HA may require that the user plane traffic be encrypted on the MN-HA link. The MN or HA can determine when to use security for the user plane traffic using static policies or dynamic policies which can be obtained at the time of network attachment; or e.g. which are provisioned and maintained on a smartcard (eg, a UICC or SIM). 3GPP policy stores such as the ANDSF can also provide information about the access networks to which an MN is attached. Location of the MN can also be used as input. 3. Triggering user plane traffic security This document proposes extensions to MIPv6/DSMIPv6 protocol, allowing Bajko, et al. Expires January 13, 2012 [Page 4] Internet-Draft Mobile IPv6: Security on demand July 2011 the MN to signal to the HA its preference for user plane traffic security, and for the HA to override that preference based on the policy settings. One of the reserved bits of the Binding Update [RFC3775] message is defined to be the 'Security' flag "S", and one of the reserved bits of the Binding Acknowledgement [RFC3775] message is also defined to be the 'Security' flag "S". The MN sends a binding update with the "S" flag set to 0, when indicating that the user plane traffic will not be encrypted. The HA processes the binding update message from the MN and sends a response acknowledging the request and setting the flag for user plane traffic security to Null indicating to the MN that the traffic on the link between the MN and HA will not be encrypted. The MN sends a binding update with the "S" flag set to 1, when indicating that prefers the user plane traffic be encrypted. The HA processes the binding update message from the MN and sends a response acknowledging the request and setting the flag for user plane traffic security to 1, indicating to the MN that the traffic on the link between the MN and HA will be encrypted. The HA MAY always overwrite the MN's security preference on the user plane traffic indicated in the Binding Update message, by setting the "S" flag in the Binding Acknowledgement to a different value. The MN SHALL always follow the indication in the Binding Acknowledgement to set the security of the MN to HA user plane traffic. 4. Extensions to Mobile IPv6 4.1. Extensions to Binding Update and Binding Acknowledgement This section defines the new "S" flag for the Binding Update and the corresponding Binding Acknowledgement message: Bajko, et al. Expires January 13, 2012 [Page 5] Internet-Draft Mobile IPv6: Security on demand July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|F|S| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: S flag in BU S When set, this flag indicates MN prefers to turn on user plane traffic encryption. When clear, MN prefers not to use security for user plane data. The corresponding Binding Acknowledgement Message looks as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: S flag in BAck S When set, this flag indicates HA acknowledges, or strongly recommends, use of user plane encryption. When clear, HA does not support or allow use of user plane encryption. Bajko, et al. Expires January 13, 2012 [Page 6] Internet-Draft Mobile IPv6: Security on demand July 2011 4.2. New binding Update Mobility Options A new mobility Options for carrying location of the MN is defined to be used in a Binding Update message with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |N| Reserved | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: MN location Type: tbd N set to 1 indicates that the data contains a location in XML format as defined in RFC5139, N set to zero indicates that the data part contains an http URI pointing to a resource where the MN uploaded its location 5. IANA Considerations This document will require actions on the part of IANA to assign values for the new binding update mobility option. 6. Security Considerations This I-D introduces extensions to Mobile IPv6 signaling messages. There is no impact to the security model and architecture that is currently specified for MIP6 [RFC3775]. The extensions specified in this document do not introduce any new vulnerabilities of threats to the security architecture of Mobile IPv6. 7. Summary Security for the user plane traffic between the MN and Home agent can be switched on or off as a result of policy, location or, request by the user. The ability to control and trigger the security for the user plane traffic rests with the MN as well as the HA with the HA having the final say. Bajko, et al. Expires January 13, 2012 [Page 7] Internet-Draft Mobile IPv6: Security on demand July 2011 8. Acknowledgments The authors acknowledge the reviews by Julien Laganier, Jouni Korhonen, Stefano Faccin and Kent Leung. Their comments and suggestions will be incorporated in the next revision. 9. References 9.1. Informative References [23.402] 3rd generation partnership project (3GPP), "3GPP TS 23.402, Architecture enhancements for non-3GPP accesses,". 9.2. Normative References [I-D.ietf-mext-mip6-tls] Korhonen, J., Patil, B., Tschofenig, H., and D. Kroeselberg, "Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication", draft-ietf-mext-mip6-tls-00 (work in progress), March 2011. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. Authors' Addresses Gabor Bajko Nokia 323 Fairchild drive 6 Mountain view, CA 94043 USA Email: gabor.bajko@nokia.com Bajko, et al. Expires January 13, 2012 [Page 8] Internet-Draft Mobile IPv6: Security on demand July 2011 Basavaraj Patil Nokia 6021 Connection drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Teemu Savolainen Nokia Hermainkatu 12 D Tampere, FI 33720 Finland Email: teemu.savolainen@nokia.com Bajko, et al. Expires January 13, 2012 [Page 9]