Mobility Extensions (MEXT) J. Korhonen Internet-Draft Nokia Siemens Networks Updates: 3775, 3775bis B. Patil (if approved) Nokia Intended status: Standards Track July 6, 2009 Expires: January 7, 2010 TLS-based Mobile IPv6 Security Framework draft-korhonen-mext-mip6-altsec-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 7, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Mobile IPv6 signaling between the mobile node and home agent is Korhonen & Patil Expires January 7, 2010 [Page 1]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6 which relies on IKE/IPsec requires interaction between the Mobile IPv6 protocol part of the IP stack and the IKE/IPsec part of the IP stack. Implementation and deployment concerns exist with such a security architecture. This document proposes an alternate security framework which relies on the reuse of Transport Layer Security for securing Mobile IPv6 signaling and IP traffic between the mobile node and home agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. TLS-based Security Framework . . . . . . . . . . . . . . . . . 4 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Security Association Management . . . . . . . . . . . . . 5 4.3. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 6 4.4. Protecting Traffic Between the Mobile Node and the Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Solution Description . . . . . . . . . . . . . . . . . . . . . 7 5.1. HTTPS-based Mobile IPv6 Bootstrapping . . . . . . . . . . 7 5.2. Configuring Security Association Parameters . . . . . . . 8 5.2.1. Security Parameter Index . . . . . . . . . . . . . . . 9 5.2.2. MN-HA Shared Key . . . . . . . . . . . . . . . . . . . 9 5.2.3. Security Association Validity Time . . . . . . . . . . 9 5.2.4. CipherSuite . . . . . . . . . . . . . . . . . . . . . 9 5.3. Configuring Mobile IPv6 Parameters . . . . . . . . . . . . 9 5.3.1. Home Agent Address . . . . . . . . . . . . . . . . . . 10 5.3.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 10 5.3.3. Home Addresses and Home Network Prefix . . . . . . . . 10 5.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 10 5.4.1. Binding Management Messages . . . . . . . . . . . . . 11 5.4.2. Reverse Tunneled User Data Packets . . . . . . . . . . 12 5.5. Protecting Traffic Between the Mobile Node and the Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Dual Stack Mobile IPv6 Considerations . . . . . . . . . . 15 5.7. Route Optimization . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 16 6.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Korhonen & Patil Expires January 7, 2010 [Page 2]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 1. Introduction Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between a mobile node (MN) and home agent (HA) is secured by IPsec [RFC4301]. The current Mobile IPv6 security architecture is specified in [RFC3776] and [RFC4877]. This security model requires a tight coupling between the Mobile IPv6 protocol part of the IP stack and the IKE/IPsec part of the IP stack. Implementation experience has indicated that the use of IKE/IPsec with Mobile IPv6 is fairly complex. The issues with the IKE/IPsec based security architecture are documented in [I-D.patil-mext-mip6issueswithipsec]. This document proposes an alternate security framework for Mobile IPv6. Transport Layer Security (TLS) [RFC5246] is widely implemented, used and available in most operating systems. The security framework is based on reusing TLS to secure Mobile IPv6 signaling and reverse tunneled traffic between the MN and the HA. The primary advantage of using TLS for Mobile IP6 security is the ease of implementation while providing the equivalent security measures as compared to IPsec. The TLS-based security framework for Mobile IP6 does not deprecate the use of IKE/IPsec for Mobile IP6 security. Rather it provides an alternative security solution to Mobile IPv6 implementations and deployment. 2. Terminology and Abbreviations 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 [RFC2119]. Home Agent Controller (HAC): The home agent Controller is a node responsible for bootstrapping the security association between a mobile node and one or more home agents. The home agent Controller also provides required key distribution to both mobile nodes and home agents. A generic Mobile IPv6 bootstrapping can be done as part of the security association bootstrapping. Binding Management Message: A message used by mobile nodes, Correspondent Nodes, and home agents in all messaging related to the creation and management of bindings. Binding Updates and Binding Acknowledgement messages are examples of binding management messages. Korhonen & Patil Expires January 7, 2010 [Page 3]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 3. Background Work on the design and specification of Mobile IPv6 has been done since the late 90s. The security architecture of Mobile IPv6 was based on the understanding that IPsec is an inherent and integral part of the IPv6 stack and any protocol that needs security should use IPsec unless there is a good reason not to. As a result of this mindset the Mobile IP6 protocol relied on the use of IPsec for security between the MN and HA. It should be noted that Mobile IPv4 [RFC3344] for example does not use IPsec for security and instead has specified its own security solution. Mobile IPv6 has been standardized in 2005 along with the security architecture using IKE/IPsec specified in RFC3776. With the transition to IKEv2 [RFC4306], Mobile IP6 security has also been updated to rely on the use of IKEv2 and specified in [RFC4877]. Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile IPv6 [RFC5555] have identified the complexity of using IPsec and IKEv2 in conjunction with Mobile IP6. At an abstract level it can be said that implementing Mobile IP6 with IPsec and IKEv2 is possible only with modifications to the IPsec and IKEv2 components. The original design intent was to reuse IPsec without having to modify it. There is also a view that IPsec is not necessarily the most well suited security protocol for Mobile IPv6. To alleviate the implementation complexity concerns and to create a security architecture that would be easier to implement, deploy and use, this document proposes a security framework based on TLS. 4. TLS-based Security Framework This specification defines an alternative security and bootstrapping solution for Mobile IPv6. The solution is inherently based on the reuse of TLS provided security functionality, and aims to provide an alternative to the IKE/IPsec based Mobile IPv6 security architecture [RFC3776][RFC4877] and IKEv2 based Mobile IPv6 bootstrapping [RFC5026]. The TLS-based solution is supposedly much easier to implement in MNs and HAs than the IKE/IPsec-based alternative. 4.1. Architecture The generic TLS-based security architecture is shown in Figure 1. The connection between a MN and a Home Agent Controller (HAC) is always secured by a TLS tunnel. It should be noted that a HAC, an AAA server and a HA are logically separate entities and can be collocated in all possible combinations. There MUST be a strong trust relationship between the HA and the HAC, and the communication Korhonen & Patil Expires January 7, 2010 [Page 4]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 between them MUST be both integrity and confidentially protected. +------+ +------+ +------+ |Mobile| TLS |Home | AAA | AAA | | Node |<----------->|Agent |<---------->|Server| | | |Contrl| | | +------+ +------+ +------+ ^ ^ ^ | | | | BU/BA/../ | e.g. AAA | AAA | (Data) | | | v | | +---------+ | | | MIPv6 | | +--------------->| Home |<-------------+ | Agent(s)| +---------+ Figure 1: TLS-based Security Architecture Overview 4.2. Security Association Management Once the MN has contacted the HAC and a mutual authentication has taken place between the MN and the HAC using TLS provided mechanisms, the HAC provisions the MN with all security related information inside the TLS protected tunnel. This security related information constitutes a Security Association (SA) between the MN and the HA. The created SA MUST NOT be tied to the Care-of Address (CoA) of the MN. The HAC may proactively distribute the SA information to HAs under its management, or the HA may query the SA information from the HAC once the MN contacts the HA. The HA MUST be able to index the SA information based on the combination of a MN Identity (typically represented in a Network Access Identifier (NAI) [RFC4282] format) and a Security Parameter Index (SPI). In certain situations, the HA may want the MN to re-establish the SA even if the existing SA is still valid. The HA can indicate this to the MN using a dedicated return code in a BA. As a result, the MN would contact the HAC prior the SA times out, and the HAC would provision the MN and HAs with a new SA information. The SA contains at least the following information: Korhonen & Patil Expires January 7, 2010 [Page 5]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 Mobility SPI: A SPI used by the MN and the HA to index the SA between the MN and the HA. The HAC is responsible for assigning SPIs to MNs. There is only one SPI for both binding management messaging and possible user data protection. The same SPI is used for both directions between the MN and the HA. MN-HA shared key: A key used for ciphering Mobile IPv6 traffic between the MN and the HA. The HAC is responsible for generating this key. The key generation algorithm is specific to the HAC implementation. Security association validity time: The validity time for the Security Association. The HAC is responsible for defining the lifetime value based on its policies. The lifetime may be in order of hours or up to weeks. The MN MUST re-contact the HAC before the SA validity time ends. Selected ciphersuite: The ciphersuite used to protect the traffic between the MN and the HA. The selected algorithms are one of the mutually supported ciphersuites of the negotiated TLS version between the MN and the HAC. The HAC is responsible for assigning the used ciphersuite. Obviously, the HAs under HAC's management MUST implement the same ciphersuites as the HAC. The selected ciphersuite MUST provide integrity and confidentially protection. Sequence number: A monotonically increasing unsigned sequence number used in all protected packets exchanged between the MN and the HA. The initial sequence number MUST always be set to 0 (zero). The sequence number may cycle to 0 (zero) when it increases beyond its maximum defined value. ** Editor's note: the SA contents is subject to more details ** 4.3. Bootstrapping of Additional Mobile IPv6 Parameters When the MN contacts the HAC and does the bootstrapping of the security related information, the HAC may also provision the MN with various Mobile IPv6 related bootstrapping information. Bootstrapping of the following information SHOULD at least be possible: Korhonen & Patil Expires January 7, 2010 [Page 6]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 Home Agent IP Address: Concerns both IPv6 and IPv4 home agent addresses. Mobile IPv6 Service Port Number: The port number where the HA and the MN are listening to UDP [RFC0768] packets. There is no fixed or IANA allocated port number defined in this specification for Mobile IPv6. Rather, deployments are free to choose any valid and available port number for their HAs and MNs. Home Address: Concerns both IPv6 and IPv4 Home Addresses. The Mobile IPv6 related bootstrapping information is delivered from the HAC to the MN over the same TLS protected tunnel as the security related information. 4.4. Protecting Traffic Between the Mobile Node and the Home Agent The same integrity and confidentiality algorithms MUST be used to protect both binding management messages and reverse tunneled user data traffic between the MN and the HA. Generally, all binding management messages (BUs, BAs and so on) MUST be both integrity and confidentially protected. The reverse tunneled user data traffic SHOULD be equivalently protected. Generally, the rules stated in [RFC3775] concerning the protection of the traffic between the MN and the HA apply also in this specification. 5. Solution Description 5.1. HTTPS-based Mobile IPv6 Bootstrapping The alternative Mobile IPv6 security solution described in this specification relies on the reuse of certain existing technologies standardized in the IETF. Namely, we utilize HTTP over TLS (HTTPS) [RFC2818] for the communication between the MN and the HAC, for bootstrapping Mobile IPv6 specific security associations and possible additional configuration data. Figure 2 shows the architecture and the scope of the solution defined in this specification. Korhonen & Patil Expires January 7, 2010 [Page 7]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 +------+ +------+ |Mobile| HTTPS |Home | | Node |<----------->|Agent | | | |Contrl| +------+ +------+ ^ | UDP encapsulated | BU/BA/../Data | packets +---------+ | | MIPv6 | +--------------->| Home | | Agent | +---------+ Figure 2: HTTPS-based Security Architecture The MN can be authenticated towards the HAC in two ways. First, the MN can be authenticated at the TLS layer, assuming the MN and the HAC can mutually authenticate each other. Second, the MN can be authenticated separately using some authentication framework running on top of HTTP. However, it is entirely a deployment specific decision which way to choose. All bootstrapping information, whether that is for setting up the SA or configuring Mobile IPv6 specific information, is exchanged between the MN and the HAC in HTTP request and response headers. The MN MUST have an Universal Resource Identifier (URI) [RFC3986] of some HAC. The URI could be statically configured, provisioned or derived by some deployment specific method. For example https://www.example.com/mip6-login.html could be a valid URI configured in the MN. At minimum the MN does a "GET" to the HAC URI, and receives a successful HTTP response with headers and an empty "page". The encoding of the HTTP headers complies to the augmented Backus- Naur Form (BNF) defined in Section 2.1 of [RFC2616]. All presented hexadecimal numbers are in network byte order. 5.2. Configuring Security Association Parameters During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a single ciphersuite for protecting the traffic between the MN and the HA. The available ciphersuites for this specification are the same as those in TLS v1.2 (see Annex A.5. of [RFC5246]). The selected ciphersuite MUST provide integrity and confidentially protection. Korhonen & Patil Expires January 7, 2010 [Page 8]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 All the parameters described in the following sections apply only to a HTTPS response the MN. The MN has no way affecting to the provisioning decision of the HAC. 5.2.1. Security Parameter Index The 28-bit unsigned SPI number identifies the SA used between the MN and the HA. The value 0 (zero) is reserved and MUST NOT be used. Therefore, values ranging from 1 to 268435455 are valid. The HTTP header corresponding to the SPI number is: mip6-spi = "mip6-spi" ":" 1*DIGIT 5.2.2. MN-HA Shared Key Key used to protect traffic between the MN and the HA. The key length depends on the selected ciphersuite. The HTTP header corresponding to the MN-HA Shared Key is: mip6-mnha-key = "mip6-mnha-key" ":" 1*(HEX HEX) 5.2.3. Security Association Validity Time The validity time of the created SA. The end of the SA validity period is represented in "rfc1123-date" format as defined in Section 3.3.1 of [RFC2616]. The HTTP header corresponding to the SA validity time value is: mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date 5.2.4. CipherSuite The ciphersuites follow the TLS 1.2 numeric representation defined in Annex A.5 of [RFC5246]. The HTTP header corresponding to the selected ciphersuite is: mip6-ciphersuite = "mip6-ciphersuite" ":" 2HEX "," 2HEX 5.3. Configuring Mobile IPv6 Parameters In parallel with the SA information bootstrapping, the HAC SHOULD provision the MN with relevant Mobile IPv6 related bootstrapping information. The following generic BNFs are used to form IP addresses and Korhonen & Patil Expires January 7, 2010 [Page 9]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 prefixes. They are used in the following sections. ip6-addr = 7( word ":" ) word word = 1*4HEX ip6-prefix = ip6-addr "/" 1*2DIGIT ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 5.3.1. Home Agent Address The HAC MAY provision the MN with an IPv4 or IPv6 address of a HA, or both. mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr 5.3.2. Mobile IPv6 Service Port Number The HAC SHOULD provision the MN with an UDP port number. The port number is used by the MNs and the HAs as the UDP destination port number when they initiate messages towards each other. mip6-port = "mip6-port" ":" 1*5DIGIT 5.3.3. Home Addresses and Home Network Prefix The HAC MAY provision the MN with an IPv4 or IPv6 Home Addresses, or both. The HAC MAY also provision the MN with its Home Network Prefix. mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr mip6-hnp-ip6 = "mip6-ip6-hnp" ":" ip6-prefix 5.4. Packet Formats The following sections describe the packet formats used for the traffic between the MN and the HA. This traffic includes binding management messages (e.g., BU/BA/HoTi/.. etc messages), reverse tunneled and encrypted user data, and reverse tunneled plain text user data. This specification defines a generic packet format, where everything is encapsulated inside an UDP. See Section 5.4.1 and Section 5.4.2 for detailed illustrations of the corresponding packet formats. The Mobile IPv6 Service port number, where the HA or the MN expect to receive UDP packets, is negotiated during the SA bootstrapping or statically configured. The same port number is used for both binding management messages and user data packets. The Mobile IPv6 Service MAY use any ephemeral port number as the UDP source port, and MUST use the Mobile IPv6 Service port number as the Korhonen & Patil Expires January 7, 2010 [Page 10]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 UDP destination port. The encapsulating UDP header is immediately followed by a 4-bit Packet Type (PType) field that defines whether the packet contains an encrypted mobility management message, an encrypted user data packet, or a plain text user data packet. The Packet Type field is followed by a 28-bit SPI value, which identifies the correct SA concerning the encrypted packet. In a case encryption is not used, the SPI MUST be set to 0 (zero). There is always only one SPI per mobility session and the same SPI is used for all types of encrypted packets independent of the direction. The SPI value is followed by a 32-bit Sequence Number value that is used to identify retransmissions of encrypted messages. Each endpoint in the security association maintains two "current" Sequence Numbers: the next one to be used for a packet it initiates and the next one it expects to see in a packet from the other end. If the MN and the HA ends initiate very different numbers of messages, the Sequence Numbers in the two directions can be very different. In a case encryption is not used, the Sequence Number MUST be set to 0 (zero). Finally, the Sequence Number field is followed by the data portion, whose content is identified by the Packet Type. When the data portion is protected, it is again encapsulated inside an Encapsulating Security Payload (ESP) [RFC4303] excluding the SPI and Sequence Number fields that were already introduced earlier. Actually, when data protection is used, the construction of the packet on the wire is the same as an UDP encapsulated ESP packet in a tunnel mode as defined in [RFC3948]. More detailed discussion of the handling of the ESP is in Section 5.5. ** Editor's note: the handling of protected traffic (i.e. the "ESP" at the moment) is subject to more detais/changes in the future ** 5.4.1. Binding Management Messages The binding management messages MUST always be protected. All packets that are specific to Mobile IPv6 protocol and contain a Mobility Header (as defined in Section 6.1.1. of RFC 3775) SHOULD use the packet format shown in Figure 3. All binding management messages that are exchanged between the MN and the HA MUST use the packet format shown in Figure 3. Korhonen & Patil Expires January 7, 2010 [Page 11]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UDP header (src-port=Xp,dst-port=Yp) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PType=8| SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Encapsulating Security Payload (ESP) after the Sequence : : Number field as defined in Section 2. of [RFC4303] : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: UDP Encapsulated Binding Management Message Format The PType value 8 (eight) identifies that the UDP encapsulated packet contains an encrypted RFC 3775 defined Mobility Header and other relevant IPv6 extension headers (note, there is no IP header). The Next Header field in the ESP header MUST be set to value of the first encapsulated header. The encapsulated headers follow the natural IPv6 and Mobile IPv6 extension header alignment and formatting rules. The source and destination IP addresses of the outer IP header (i.e. the src-addr and the dst-addr in Figure 3) use the current care-of address of the MN and the HA address. 5.4.2. Reverse Tunneled User Data Packets There are two types of reverse tunneled user data packets between the MN and the HA. Those that are encrypted and those that are plain text. The MN or the HA MAY switch between the encryption and plain text at any time based on local policies. By default all user data SHOULD be encrypted. The reverse tunneled IPv4 or IPv6 user data packets are encapsulated as-is inside the ESP. Korhonen & Patil Expires January 7, 2010 [Page 12]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UDP header (src-port=Xp,dst-port=Yp) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PType=1| SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Encapsulating Security Payload (ESP) after the Sequence : : Number field as defined in Section 2. of [RFC4303] : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: UDP Encapsulated Protected User Data Packet Format The PType value 1 (one) identifies that the UDP encapsulated packet contains an encrypted tunneled IPv4/IPv6 user data packet. The Next Header field in the ESP header MUST be set to value corresponding the tunneled IP packet (e.g. 41 for IPv6). The source and destination IP addresses of the outer IP header (i.e. the src-addr and the dst-addr in Figure 4) use the current care-of address of the MN and the HA address. The ESP protected inner IP header uses the home address of the MN and the correspondent node (CN) address. Korhonen & Patil Expires January 7, 2010 [Page 13]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : UDP header (src-port=Xp,dst-port=Yp) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PType=0| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : IPv4 or IPv6 Packet (plain) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: UDP Encapsulated Non-Protected User Data Packet Format The PType value 0 (zero) identifies that the UDP encapsulated packet contains a plain text tunneled IPv4/IPv6 user data packet. Also the SPI and the Sequence Number fields MUST be set to 0 (zero). The source and destination IP addresses of the outer IP header (i.e. the src-addr and the dst-addr in Figure 5) use the current care-of address of the MN and the HA address. The plain text inner IP header uses the home address of the MN and the CN address. 5.5. Protecting Traffic Between the Mobile Node and the Home Agent As briefly described in Section 5.4, all traffic between the MN and the HA can be protected by ESP-over-UDP type encapsulation. The Figure 6 shows a detailed structure of the ESP packet, which is slightly modified from the ESP packet layout found in Section 2. of RFC4303. The only notable difference is that the SPI is prefixed with 4-bit PType field leaving 28-bit SPI value, although from the ESP processing point of view, the 4-bit PType and 28-bit SPI are handled as one "32-bit SPI". Furthermore, only 32-bit Sequence Numbers are supported. Korhonen & Patil Expires January 7, 2010 [Page 14]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | PType | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | IV (optional) | | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Rest of Payload Data (variable) | | | : : | | | | |Conf. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | TFC Padding * (optional, variable) | |ered +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Padding (0-255 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----- | Integrity Check Value-ICV (variable) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Substructure of ESP Protected Payload Data with a 28-bit SPI and 4-bit PType Modifications * An implementation can add Traffic Flow Confidentiality (TFC) padding (see Section 2.7 of RFC4303) after the Payload Data and before the Padding (0-255 bytes) field. The general processing and construction of the ESP is described in RFC4303. The used integrity and confidentially protection algorithms are defined by the ciphersuite that was provided by the HAC during the TLS-based bootstrapping of the SA. ** Editor's note: this section is subject to more detais/changes in the future regarding how to apply integrity and confidentiality protection algorithms to the "ESP" ** 5.6. Dual Stack Mobile IPv6 Considerations TBD. 5.7. Route Optimization This specification does not address route optimization. However, if the correspondent node (CN) implement HAC functionality locally, the Korhonen & Patil Expires January 7, 2010 [Page 15]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 HTTPS-based bootstrapping of the SA between the MN and the CN can be done. 6. IANA Considerations 6.1. New Registry: Packet Type IANA is requested to create a new registry for the Packet Type as described in Section 5.4. Packet Type | Value ----------------------------------+---------------------------------- non-encrypted IP packet | 0 encrypted IP packet | 1 mobility header | 8 Following the example policies described in [RFC5226] new values for the Packet Type AVP MUST be assigned based on the "RFC Required" policy. 6.2. HTTP Headers A number of HTTP headers with their respective parameters are reserved. See Section 5.2 and Section 5.3 for a list of header names and their parameters. 7. Security Considerations TBD. 8. References 8.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Korhonen & Patil Expires January 7, 2010 [Page 16]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 8.2. Informative References [I-D.patil-mext-mip6issueswithipsec] Patil, B., Perkins, C., and H. Tschofenig, "Issues related to the design choice of IPsec for Mobile IPv6 security", draft-patil-mext-mip6issueswithipsec-00 (work in progress), October 2008. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. Korhonen & Patil Expires January 7, 2010 [Page 17]
Internet-Draft TLS-based MIPv6 Security Framework July 2009 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. Authors' Addresses Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 Espoo FIN-02600 Finland Email: jouni.nospam@gmail.com Basavaraj Patil Nokia 6021 Connection Drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Korhonen & Patil Expires January 7, 2010 [Page 18]