| Mobility Extensions (MEXT) | B. Patil |
| Internet-Draft | Nokia |
| Intended status: Experimental Protocol | C. Perkins |
| Expires: April 13, 2012 | Tellabs |
| H. Tschofenig | |
| Nokia Siemens Networks | |
| D. Premec | |
| Unaffiliated | |
| October 11, 2011 |
Problems with the use of IPsec as the security protocol for Mobile IPv6
draft-patil-mext-mip6issueswithipsec-04.txt
Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the signaling messages and user plane traffic between the mobile node and home agent. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies.
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 April 13, 2012.
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 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.
Mobile IPv6 as specified in [RFC3775] requires an IPsec security association between the mobile node (MN) and home agent (HA). The IPsec SA protects the mobility signaling messages between the MN and HA. The user data may be optionally protected by the IPsec SA but is not required. The use of IPsec by most hosts today is primarily as a solution for enterprise connectivity through VPN applications. IPsec has not evolved into a generic security protocol.
The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 working groups in the IETF chose to mandate IPsec as the default security protocol for Mobile IPv6 based on various criteria and lengthy discussions that occured between the years 2000 and 2004. Implementation experience with Mobile IPv6 and the security variants with which it has been specified in some SDOs indicates a need to revisit the design choice for MIP6 signaling security. The analysis and recommendation to revisit the security protocol architecture for MIP6 should not be interpreted as a recommendation for Authentication Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight the misfit of IPsec and IKEv2 as the security protocol for MIP6 and hence the need for considering alternatives. A simpler security architecture for securing the signaling and traffic between the MN and HA can co-exist with the IPsec based solution as well.
The objective of Mobile IPv6 [RFC3775] is to enable IP mobility for IPv6 hosts. The security aspect of the protocol is a critical component for consideration in terms of deployment and operation on large scales. If complexity of implementation were a consideration then the current specification dealing with Mobile IPv6, i.e RFC3775 [RFC3775] and RFC5555 [RFC5555] would win high accolades. An implementer spends 20% of his time on implementing the Mobile IPv6 protocol and 80% of the time integrating it with IPsec and IKEv2. And even after that interoperability of the client with home agents is not guaranteed. The IPsec/IKEv2 security architecture may work in implementations wherein the OS, the IPsec/IKEv2 stack and mobile ipv6 client software are all implemented by a single entity. It just does not work on open systems.
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].
This document refers to [RFC3775][RFC4877] for terminology.
IP mobility support in IPv6 was considered to be an integral feature of the IPv6 stack based on the experience gained from developing mobility support for IPv4. The design of Mobile IPv6 was worked on by the Mobile IP WG in the late 90s and by the MIP6 WG until its publication as [RFC3775] in 2004.
IPsec [RFC4301] was also intended to be a default component of the IPv6 stack and was the preferred protocol choice for use by any other IPv6 protocol that needed security. Rather than design security into every protocol feature, the intent was to reuse a well-defined security protocol to meet the security needs. Hence Mobile IPv6 has been designed with a security architecture that relies on reusing IPsec.
The Mobile IPv6 specification [RFC3775] was published along with the companion specification "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", [RFC3776]. The establishment of the IPsec SA between the MN and HA as per RFC 3776 is based on the use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec SA establishment did not gain traction because of factors such as complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG completed the specification, Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] is considered as the default security protocol solution for MIP6 and updates [RFC3776].
Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an implementation and deployment perspective. As a protocol solution for host based mobility, MIP6 can be simpler without the IPsec baggage. The issues with IPsec are even more exacerbated in the case of dual-stack MIP6 [RFC5555].
IPsec SAs between the MN and HA are established either manually or via the use of IKEv2 [RFC4306]. Manual SA configuration is not a scalable solution and hence MIP6 hosts and Home agents rely on IKEv2 for establishing dynamically IPsec SAs. As a result MIP6 depends on the existence of IPsec and IKEv2 for successful operation.
IPsec is unable to provide security protection for MIP6 in a transparent way, and numerous interactions between the host's security subsystems and the MIP6 application are needed in the course of the regular operation of the MIP6 application. Besides requiring an extensive communications channel between the security subsystems and the MIP6 application, those interactions often also require modification of the MNs security subsystems code. The situation today is such that the communications channel between the IPsec subsystems and the MIP6 application is non existent and this is generally true for most of the commercially available platforms. Even if such a channel were to be available, there does not exist a standardized protocol over that channel which would enable the MIP6 application to communicate with the security modules in a non- implementation specific way.
Considering a third party application developer who would like to provide a MIP6 application for a particular platform, the need for numerous interactions with the IPsec subsystem and the unavailability of the standardized communications channel through which such interactions could take place is a major obstacle to the implementation of the mobility protocol. Without such a communication channel being available it is not possible to implement a MIP6 application as a third party developer.
Even if the platform would provide such a communication interface for the MIP6 daemon, this is still insufficient as the MIP6 protocol standardized today [RFC3775] requires numerous changes to the host's IPsec and IKEv2 implementation. This document enumerates various implementation issues related to the interactions between the MIP6 application and the host's security subsystems.
An argument can be made that the MIP6 application itself should provide the required changes to the IPsec subsystems of the platform (maybe in the form of patches). While this is possible at least for some open source platforms to provide modifications to the host's IPsec implementation as well as the key management application(s), this is still an issue for several reasons:
The above discussion shows why it is unrealistic to expect that the MIP6 application could provide the needed modifications to the IKEv2 and IPsec subsystems of the host. Section 6 presents a more technical discussion of various implementation issues related to the interworking between the MIP6 application and the IPsec/key management modules.
The problem in a nutshell for MIP6 is the dependence on IPsec and IKEv2 for successful operation.
This section captures several issues with the use of IPsec by MIP6.
The issues listed above can be speculatively attributed as some of the causes for MIP6 not being implemented widely.
Once the MN has contacted the HAC and mutual authentication has taken place between the MN and the HAC inside the TLS protected tunnel, 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. If the HA queries for the SA information from the HAC, then the HA MUST be able to query/index the SA information from the HAC based on the 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 Status Code in a BA (value set to REINIT_SA_WITH_HAC). 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:
When the MN contacts the HAC to distribute 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:
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.
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 SHOULD be 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.
The MN and the HAC communicate with each other using a simple lock-step request-response protocol that is run directly on top of the TLS-tunnel. We define only one message container framing for the request messages and for the response messages. The message containers are only meant to be exchanged on top of connection oriented TLS-layer. Therefore, the end of message exchange is determined by the other end closing the transport connection (assuming the "application layer" has also indicated the completion of the message exchange). The peer initiating the TLS-connection is always sending "Requests" and the peer accepting the TLS-connection is always sending "Responses". The format of the message container is shown in Figure 1.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Rsrvd | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content portion.. ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All data inside the Content portion of the message container MUST be encoded using octets. Fragmentation of message containers is not supported, which means one request or response at the "application layer" MUST NOT exceed the maximum size allowed by the message container format.
The three bit Ver field identifies the protocol version. The current version is 0 i.e. all bits are set to value 0 (zero).
The Rsrvd field MUST be set to value 0 (zero),
The Identifier field is meant for matching requests and responses. The valid Identifier values are between 1-255. The value 0 MUST NOT be used. The first request for each communication session between the MN and the HAC MUST have the Identifier values set to 1.
The Length field tells the length of the Content portion of the container (i.e. Reserved octet, Identifier octet and Length field are excluded). The Content portion length MUST always be at least one octet up to 65535 octets. The value is in network order.
The encoding of the message content is similar to HTTP header encoding, and complies to the augmented Backus-Naur Form (BNF) defined in Section 2.1 of [RFC2616]. All presented hexadecimal numbers are in network byte order. From now on, we use TypeValue header (TV-header) term to refer request-response message content HTTP-like headers.
The message exchange between the MN and the HAC is a simple lock-step request-response type as stated in Section 5.1. A request message includes monotonically increasing Identifier value that is copied to the corresponding response message. Each request MUST have a different Identifier value and due the assumption of a reliable connection oriented transport below the message container framing. The number of request-response message exchanges MUST NOT exceed 255.
Each new communication session between the MN and the HAC MUST reset the Identifier value to 1. The MN is also the peer that always sends only request messages and the HAC only sends response messages. Once the request-response message exchange completes, the HAC and the MN MUST close the transport connection and the corresponding TLS-tunnel.
In a case of a HAC side error, the HAC MUST send a response back to a MN with an appropriate status code and then close the transport connection.
The first request message - MHAuth-Init - (i.e. the Identifier is 1) MUST always contain at least the following parameters:
The first response message - MHAuth-Init - (i.e. the Identifier is 1) MUST contain at minimum the following parameters:
The last request message from the MN side - MHAuth-Done - MUST contain the following parameters:
The last response message - MHAuth-Done - that ends the request-response message exchange MUST contain the following parameters:
And in a case of successful authentication the following additional parameters:
All bootstrapping information, whether for setting up the SA or for bootstrapping Mobile IPv6 specific information, is exchanged between the MN and the HAC using the framing protocol defined in Section 5.1. The IP address of the HAC MAY be statically configured to the MN or dynamically discovered using for example DNS. In a case of DNS-based HAC discovery, the MN either queries an A/AAAA or a SRV record for the HAC IP address. The actual domain name used in queries is up to the deployment to decide and out of scope of this specification.
An identifier that identifies a MN. The Mobile Node Identifier is in form of a Network Access Identifier (NAI) [RFC4282].
The HAC is the peer that mandates the used authentication method. The MN sends its proposal to the HAC but eventually the used authentication method returned from the HAC defines the one to be used. The MN MUST propose at least one authentication method and it SHOULD propose more than one. The HAC MUST select exactly one authentication method, or return an error and then close the connection.
Each Extensible Authentication Protocol (EAP) [RFC3748] message is encoded string of hexadecimal numbers. The "eap-payload" is completely transparent what EAP-method or EAP message is carried inside it. The "eap-payload" can appear in both request and response messages:
The "status-code" MUST only be present in the response message that ends the request-response message exchange. The "status-code" follows the principles of HTTP and the definitions found in Section 10 of RFC 2616 also apply for these status codes listed below:
The "auth" header contains data used for authentication purposes. It MUST be the last TV-header in the message and calculated over the whole message till the start of the "msg-header":
Random number generated by the MN or the HAC. The length of the random number MUST be 32 octets (before TV-header encoding):
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 allowed ciphersuites for this specification are a subset of those in TLS v1.2 (see Annex A.5 of [RFC5246]) as per Section 5.6.5. This might appear as a constraint as the HA and the HAC may have implemented different ciphersuites. These two nodes are, however, assumed to belong to the same administrative domain. In order to avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol and to reuse the TLS ciphersuite negotiation procedure we make this simplifying assumption. The selected ciphersuite MUST provide integrity and confidentially protection.
Section 5.6.5 provides the mapping from the TLS ciphersuites to the integrity and encryption algorithms allowed for MN-HA protection. This mapping mainly ignores the authentication algorithm part that is not required within the context of this specification. For example, [RFC3268] defines a number of AES based ciphersuites for TLS including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the relevant part is 'AES_128_CBC_SHA'.
All the parameters described in the following sections apply only to a request-response protocol response message to the MN. The MN has no way affecting to the provisioning decision of the HAC.
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 TV-header corresponding to the SPI number is:
The MN-HA shared integrity (ikey) and encryption (ekey) keys are used to protect the traffic between the MN and the HA. The length of these keys depend on the selected ciphersuite.
The TV-headers that carry these two parameters are:
The end of the SA validity time is encoded using the "rfc1123-date" format, as defined in Section 3.3.1 of [RFC2616].
The TV-header corresponding to the SA validity time value is:
The SA is applied either to Mobile IPv6 signaling messages only, or to both Mobile IPv6 signaling messages and data traffic. This parameter MUST be agreed between the MN and HA prior to using the SA. Otherwise the receiving side would not be aware of whether the SA applies to data traffic and could not decide how to act when receiving unprotected packets of PType 1 (see Section 6.4).
where a value of “0” indicates that the SA does not protect data traffic and a value of “1” indicates that all data traffic MUST be protected by the SA. If the mip6-sas value of an SA is set to 1, any packet with PType = 0 MUST be silently discarded when received.
The HAC is the peer that mandates the used security association scope. The MN sends its proposal to the HAC but eventually the security association scope returned from the HAC defines the used scope.
The ciphersuite negotiation between HAC and MN uses a subset of the TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation defined in Annex A.5 of [RFC5246]. The TV-headers corresponding to the selected ciphersuite and ciphersuite list are:
All other Ciphersuite values are reserved and subject to future specifications.
HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566]
The following integrity algorithms MUST be supported by all implementations:
The binding management messages between the MN and HA MUST be integrity protected. Implementations MUST NOT use a NULL integrity algorithm.
NULL [RFC2410] TripleDES-CBC [RFC2451] AES-CBC with 128-bit keys [RFC3602]
The following encryption algorithms MUST be supported:
Traffic between MN and HA MAY be encrypted. Any integrity-only CipherSuite makes use of the NULL encryption algorithm.
+-------------------+-----------------+--------------------------+|Ciphersuite |Integ. Algorithm |Encr. Algorithm | +-------------------+-----------------+--------------------------+|NULL_SHA |HMAC-SHA1-96 |NULL ||NULL_SHA256 |AES-XCBC-MAC-96 |NULL ||3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC ||AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys ||AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys | +-------------------+----------------+---------------------------+
Note: In the present version, this document does not consider combined algorithms. The following table provides the mapping of each ciphersuite to a combination of integrity and encryption algorithms that are part of the negotiated SA between MN and HA.
In parallel with the SA bootstrapping, the HAC SHOULD provision the MN with relevant Mobile IPv6 related bootstrapping information.
ip6-addr = 7( word ":" ) word CRLF word = 1*4HEX ip6-prefix = ip6-addr "/" 1*2DIGIT ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
The following generic BNFs are used to form IP addresses and prefixes. They are used in subsequent sections.
The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, or both.
The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or both. The HAC MAY also provision the MN with its home network prefix.
This section describes the basic operation required for the MN-HAC mutual authentication and the channel binding. The authentication protocol described as part of this section is a simple exchange that follows the GPSK exchange used by EAP-GPSK [RFC5433]. It is secured by the TLS tunnel and is cryptographically bound to the TLS tunnel through channel binding based on [RFC5056] and on the channel binding type 'tls-server-endpoint' described in [I-D.altman-tls-channel-bindings]. As a result of the channel binding type, this method can only be used with TLS ciphersuites that use server certificates and the Certificate handshake message. For example, TLS ciphersuites based on PSK or anonymous authentication cannot be used.
The authentication exchange MUST be performed through the encrypted TLS tunnel. It performs mutual authentication between the MN and the HAC based on a pre-shared key (PSK) or based on an EAP-method (see Section 5.9). The PSK protocol is described in this section. It consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth-Done) in which both sides exchange nonces and their identities, and compute and exchange a message authenticator 'auth' over the previously exchanged values, keyed with the pre-shared key. The MHAuth-Done messages are used to deal with error situations. Key binding with the TLS tunnel is ensured by channel binding of the type "tls-server-endpoint" as described by [I-D.altman-tls-channel-bindings] where the hash of the TLS server certificate serves as input to the 'auth' calculation of the MHAuth messages.
Note: The authentication exchange is based on the GPSK exchange used by EAP-GPSK. In comparison to GPSK, it does not support exchanging an encrypted container (it always runs through an already protected TLS tunnel). Furthermore, the initial request of the authentication exchange (MHAuth-Init) is sent by the MN (client side) and is comparable to EAP-Response/Identity, which reverses the roles of request and response messages compared to EAP-GPSK. Figure 6 shows a successful protocol exchange.
MN HAC | | | Request/MHAuth-Init (...) | |------------------------------------------------------>| | | | Response/MHAuth-Init (...) | |<------------------------------------------------------| | | | Request/MHAuth-Done (...) | |------------------------------------------------------>| | | | Response/MHAuth-Done (...) | |<------------------------------------------------------| | |
Where:
The length "mn-rand", "hac-rand" is 32 octets. Note that "|" indicates concatenation and optional parameters are shown in square brackets [..]. The square brackets can be nested.
The shared secret PSK can be variable length. 'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the auth calculation that is the "TLS-server-endpoint" channel binding type. The content and algorithm (only required for the "TLS-server-endpoint" type) are the same as described in [I-D.altman-tls-channel-bindings].
The MN starts by selecting a random number 'mn-rand' and choosing a list of supported authentication methods coded in 'auth-method'. The MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to the HAC in MHAuth-Init. The decision of which authentication method to offer and which to pick is policy- and implementation-dependent and, therefore, outside the scope of this document.
In MHAuth-Done, the HAC sends a random number 'hac-rand' and the selected ciphersuite. The selection MUST be one of the MN-supported ciphersuites as received in 'ciphersuite-list'. Furthermore, it repeats the received parameters of the MHAuth-Init message 'mn-rand'. It computes a message authenticator 'auth' over all the transmitted parameters except 'auth' itself. The HAC calculates 'auth' over all parameters and appends it to the message.
The MN verifies the received MAC and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Auth. In case of successful verification, the MN computes a MAC over the session parameter and returns it to the HAC in MHAuth-Done. The HAC verifies the received MAC and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Init. If the verification is successful, MHAuth-Done is prepared and sent by the HAC to confirm successful completion of the exchange.
Basic operation required for the MN-HAC mutual authentication using EAP-based methods.
MN HAC | | | Request/MHAuth-Init (...) | |------------------------------------------------------>| | | | Response/MHAuth-Init (..., | | eap-payload=EAP-Request/Identity) | |<------------------------------------------------------| | | | Request/MHAuth-Mid (eap-payload= | | EAP-Response/Identity) | |------------------------------------------------------>| | | | Response/MHAuth-Mid (eap-payload=EAP-Request/...) | |<------------------------------------------------------| | | : : : ..EAP-method specific exchanges.. : : : | | | Request/MHAuth-Done (eap-payload=EAP-Response/..., | | ..., auth) | |------------------------------------------------------>| | | | Response/MHAuth-Done (eap-payload=EAP-Success, | | ..., auth) | |<------------------------------------------------------| | |
Where:
In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If the EAP-method is key-deriving and creates a shared MSK key as a side effect of Authentication shared-key MUST be the MSK in all MHAuth-Done messages. This MSK MUST NOT be used for any other purpose. In case the EAP method does not generate an MSK key, shared-key is set to "1".
'msg-octets' includes all payload parameters of the respective message to be signed except the 'auth' payload. CB-octets is the channel binding input to the AUTH calculation that is the "TLS-server-endpoint" channel binding type. The content and algorithm (only required for the "TLS-server-endpoint" type) are the same as described in [I-D.altman-tls-channel-bindings].
The following sections describe the packet formats used for the traffic between the MN and the HA. This traffic includes binding management messages (for example, BU and BA 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 UDP. See Section 6.3 and Section 6.4 for detailed illustrations of the corresponding packet formats.
The Mobile IPv6 service port number (HALTSEC), where the HA expects to receive UDP packets, is reserved by IANA. The same port number is used for both binding management messages and user data packets. The reason for multiplexing data and control messages over the same port number is due to the possibility of Network Address and Port Translators located along the path between the MN and the HA. The Mobile IPv6 service MAY use any ephemeral port number as the UDP source port, and MUST use the Mobile IPv6 service port number (HALTSEC) as the 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 or a, 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. For any packet that is neither integrity protected nor encrypted (i.e. no SA is applied by the originator) the SPI MUST be set to 0 (zero). ). Mobility management messages MUST always be at least integrity protected. Hence, mobility management messages MUST NOT be sent with a SPI value of 0 (zero).
There is always only one SPI per MN-HA mobility session and the same SPI is used for all types of protected 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). Note that the HA SHOULD initiate a re-establishement of the SA before any of the Sequence Number cycle.
Finally, the Sequence Number field is followed by the data portion, whose content is identified by the Packet Type. The data portion may be protected.
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 | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SPI is a 32-bit field, where the first 4 bits indicate the Packet Type (PType) of the UDP encapsulated packet. The SPI value itself consists of the remaining 28-bit of the SPI field. The SPI field is treated as one 32-bit field during the integrity protection calculation.
The binding management messages that are only meant to be exchanged between the MN and the HA MUST be integrity protected and MAY be encrypted. They MUST use the packet format shown in Figure 9. All packets that are specific to the 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 9. (This means that some Mobile IPv6 mobility management messages, such as the HoTI message, as treated as data packets and using encapsulation described in Section 6.4).
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 | ^Int.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| Sequence Number | |ered+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----| Payload Data* (variable) | | ^: : | || | |Conf.+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| | Padding (0-255 bytes) | |ered*+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad Length | Next Header | v v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------| Integrity Check Value-ICV (variable) |: :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PType value 8 (eight) identifies that the UDP encapsulated packet contains a RFC 3775 defined Mobility Header and other relevant IPv6 extension headers. Note, there is no additional IP header inside the encapsulated part. The Next Header field 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 Padding, Pad Length, Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document. For a SPI value of 0 (zero) that indicates an unprotected packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT be present.
The source and destination IP addresses of the outer IP header (i.e. the src-addr and the dst-addr in Figure 9) use the current care-of address of the MN and the HA address.
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 | ^Int.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| Sequence Number | |ered+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----| Payload Data* (variable) | | ^: : | || | |Conf.+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| | Padding (0-255 bytes) | |ered*+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad Length | Next Header | v v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------| Integrity Check Value-ICV (variable) |: :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are two types of reverse tunneled user data packets between the MN and the HA. Those that are integrity protected and encrypted and those that are plaintext. The MN or the HA decide whether to apply integrity protection and encryption to a packet or to send it in plaintext based on the mip6-sas value in the SA. If the mip6-sas is set to 1 the originator MUST NOT send any plaintext packet, and the receiver MUST silently discard any packet with the PType set to 0 (unprotected). It is RECOMMENDED to apply confidentiality and integrity protection of user data traffic. The reverse tunneled IPv4 or IPv6 user data packets are encapsulated as-is inside the 'Payload Data' shown in Figure 10. and Figure 11.
The PType value 1 (one) identifies that the UDP encapsulated packet contains an encrypted tunneled IPv4/IPv6 user data packet. The Next Header field header MUST be set to value corresponding the tunneled IP packet (e.g., 41 for IPv6).
The Padding, Pad Length, Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document. For a SPI value of 0 (zero) that indicates an unprotected packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT be present.
The source and destination IP addresses of the outer IP header (i.e., the src-addr and the dst-addr in Figure 10) use the current care-of address of the MN and the HA address. The ESP protected inner IP header, which is not shown in Figure 10, uses the home address of the MN and the correspondent node (CN) address.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Payload Data (plain IPv4 or IPv6 Packet) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PType value 0 (zero) identifies that the UDP encapsulated packet contains a plaintext 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 11) 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.
The treatment of MN-CN route optimization is outside the scope of this document.
Packet Type | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
IANA is requested to create a new registry for the Packet Type as described in Section 6.1.
Following the allocation policies from [RFC5226] new values for the Packet Type AVP MUST be assigned based on the "RFC Required" policy.
A number of HTTP headers with their respective parameters are reserved. See Section 5.6 and Section 5.7 for a list of header names and their parameters.
REINIT_SA_WITH_HAC TBD1
A new Status Code (to be used in BA messages) is reserved for the cases where the HA wants to indicate to the MN that it needs to re-establish the SA information with the HAC. The Result Code is reserved from the 0-127 code space:
HALTSEC TBD2
A new port number (HALTSEC) for UDP packets is reserved from the PORT NUMBERS registry.
This document describes and uses a number of building blocks that introduce security mechanisms and need to interwork in a secure manner.
The following building blocks are considered from a security point of view:
No dynamic procedure for discovering the HAC by the MN is described in this document. As such, no specific security considerations apply to the scope of this document.
This document describes a simple authentication and MN-HA SA negotiation exchange over TLS. The TLS procedures remain unchanged; however, channel binding is provided.
The AAA backend infrastructure interworking is not defined in this document and therefore out-of-scope.
The authors would like to thank Pasi Eronen, Domagoj Premec, and Christian Bauer for their comments.