RFC 6618
Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent
RFC 6618 💖 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent
- Publisher: Internet Engineering Task Force (IETF) 🌸
- Authors: J. Korhonen, Ed. (Nokia Siemens Networks), B. Patil (Nokia), H. Tschofenig (Nokia Siemens Networks), D. Kroeselberg (Siemens) 👩💻
- Category: Experimental 🧪
- ISSN: 2070-1721
- Date: May 2012 📅
- Obsoletes / Updates: This one doesn't obsolete or update anything. Its header doesn't list any. 🙅♀️
Abstract ✨
okay so Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent (HA) is locked down with IPsec 🔐. The security association (SA) between the MN and the HA gets set up with Internet Key Exchange Protocol (IKE) version 1 or 2. The Mobile IPv6 security model we already have leans on IKE/IPsec, which means the Mobile IPv6 protocol bit and the IKE/IPsec module of the IP stack have to talk to each other constantly 🙃. This document is pitching a different security framework for Mobile IPv6 and Dual-Stack Mobile IPv6. It uses Transport Layer Security to set up the keying material and other bootstrapping parameters needed to protect Mobile IPv6 signaling and data traffic between the MN and HA. It's giving clean and simple 💅.
Status of This Memo 📝
This document is not an Internet Standards Track specification. It's being published for examination, experimental implementation, and evaluation 🧪.
This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🤓.
For info about the current status of this document, any errata, and how to give feedback on it, go to http://www.rfc-editor.org/info/rfc6618 🔗.
Copyright Notice ©️
Copyright (c) 2012 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 read these carefully, because they spell out your rights and restrictions with respect to this document. Code components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology and Abbreviations ...................................4
3. Background ......................................................5
4. TLS-Based Security Establishment ................................5
4.1. Overview ...................................................5
4.2. Architecture ...............................................7
4.3. Security Association Management ............................7
4.4. Bootstrapping of Additional Mobile IPv6 Parameters .........9
4.5. Protecting Traffic between Mobile Node and Home Agent .....10
5. MN-to-HAC Communication ........................................10
5.1. Request-Response Message Framing over TLS-Tunnel ..........10
5.2. Request-Response Message Content Encoding .................11
5.3. Request-Response Message Exchange .........................12
5.4. Home Agent Controller Discovery ...........................13
5.5. Generic Request-Response Parameters .......................13
5.5.1. Mobile Node Identifier .............................13
5.5.2. Authentication Method ..............................13
5.5.3. Extensible Authentication Protocol Payload .........14
5.5.4. Status Code ........................................14
5.5.5. Message Authenticator ..............................14
5.5.6. Retry After ........................................14
5.5.7. End of Message Content .............................14
5.5.8. Random Values ......................................15
5.6. Security Association Configuration Parameters .............15
5.6.1. Security Parameter Index ...........................15
5.6.2. MN-HA Shared Keys ..................................16
5.6.3. Security Association Validity Time .................16
5.6.4. Security Association Scope (SAS) ...................16
5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping ..17
5.7. Mobile IPv6 Bootstrapping Parameters ......................18
5.7.1. Home Agent Address .................................18
5.7.2. Mobile IPv6 Service Port Number ....................18
5.7.3. Home Addresses and Home Network Prefix .............18
5.7.4. DNS Server .........................................19
5.8. Authentication of the Mobile Node .........................19
5.9. Extensible Authentication Protocol Methods ................22
6. Mobile Node to Home Agent Communication ........................23
6.1. General ...................................................23
6.2. PType and Security Parameter Index ........................25
6.3. Binding Management Message Formats ........................25
6.4. Reverse-Tunneled User Data Packet Formats .................27
7. Route Optimization .............................................29
8. IANA Considerations ............................................29
8.1. New Registry: Packet Type .................................29
8.2. Status Codes ..............................................29
8.3. Port Numbers ..............................................29
9. Security Considerations ........................................30
9.1. Discovery of the HAC ......................................30
9.2. Authentication and Key Exchange Executed between
the MN and the HAC ........................................30
9.3. Protection of MN and HA Communication .....................33
9.4. AAA Interworking ..........................................35
10. Acknowledgements ..............................................35
11. References ....................................................35
11.1. Normative References .....................................35
11.2. Informative References ...................................361. Introduction ✨
okay so Mobile IPv6 (MIPv6) [RFC6275] signaling, and optionally user traffic, between a Mobile Node (MN) and Home Agent (HA) gets protected by IPsec [RFC4301]. The current Mobile IPv6 security architecture is specified in [RFC3776] and [RFC4877]. This security model needs a tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/IPsec part of the IP stack. Client implementers have found that using IKE(v2)/IPsec with Mobile IPv6 is pretty complex 😩.
So this document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6 🎀. The goal is to simplify implementations and make the protocol easy to deploy without giving up on security 🔒. Transport Layer Security (TLS) [RFC5246] is already implemented in almost every major operating system and used all over the place by different applications 🌈. So instead of using IKEv2 to set up security associations, the framework here is built on TLS-protected messages. Those messages exchange keys and bootstrapping parameters between the MN and a new functional entity called the "Home Agent Controller" (HAC) 🧚. After that, the Mobile IPv6 signaling between the mobile node and home agent is secured with the resulting keys and the negotiated ciphersuite 🦋. The HAC can be co-located with the HA, or it can be its own independent entity. If it's independent, the communication between the HAC and HA is not defined by this document. That kind of communication could be built on top of AAA protocols such as Diameter 🤷♀️.
The big perk of using TLS to set up Mobile IPv6 security associations, compared to IKEv2, is that it's way easier to implement (especially on the mobile nodes) while still giving an equivalent level of security 💜. This document proposes a solution that decouples Mobile IPv6 security from IPsec, for securing signaling messages and user plane traffic, which cuts down on client implementation complexity. Main character energy 👑.
The security framework in this document is not meant to replace the currently specified architecture that relies on IPsec and IKEv2. It's an alternative that's more optimal for certain deployment scenarios 🍓. The MEXT working group at the IETF has looked at this and other alternative security models, and the decision was that the alternatives should be published as Experimental RFCs, so more implementation and deployment experience can be gathered 📚. The status of this proposal may be reconsidered in the future if it becomes clear that it's superior to the others 👀.
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]. Those are the key words, so pay attention to them 🫶.
Home Agent Controller (HAC) 🎀
The home agent controller is a node responsible for bootstrapping Mobile IPv6 security associations between a mobile node and one or more home agents. It also provides key distribution to both mobile nodes and home agents. Mobile IPv6 bootstrapping is also performed by the HA, in addition to the security association bootstrapping between the mobile node and home agent controller 🔑.
Binding Management Messages 📨
Mobile IPv6 signaling messages between a mobile node and a home agent, correspondent node, or mobility access point, used to manage the bindings, are referred to as binding management messages. Binding Updates (BUs) and Binding Acknowledgement (BA) messages are examples of binding management messages 💌.
to be continued... 🧚 part 1 of 8, more parts coming bestie! 💖
3. Background ✨
Okay bestie, let's do a little history lesson 📜🦋. Mobile IPv6 design and specification started in the mid-to-late 90s 🌸. Back then the security vibe was 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 💅. So the Mobile IP6 protocol relied on IPsec for security between the MN and HA. Reusing security components that are built right into the IP stack is a good design goal for any protocol, ngl 🫶. The catch is that for Mobile IPv6 it makes implementation more complicated 😭.
It should be noted that Mobile IPv4 [RFC5944], for example, does not use IPsec for security and instead has specified its own security solution 🎀. Mobile IPv4 has been implemented and deployed on a reasonably large scale, and its security model has proven itself to be sound 👑.
Mobile IPv6 standardization was completed in 2005, along with the security architecture using IKE/IPsec specified in RFC 3776 [RFC3776] ⭐. Then came IKEv2 [RFC5996], so Mobile IPv6 security was updated to rely on IKEv2 [RFC4877] too 🔥. Implementation exercises of Mobile IPv6 and Dual-Stack Mobile IPv6 [RFC5555] showed how complicated it is to use IPsec and IKEv2 together with Mobile IPv6 💀. Implementing Mobile IPv6 with IPsec and IKEv2 requires modifications to both the IPsec and IKEv2 components, because of the communication models that Mobile IPv6 uses and the changing IP addresses 🙈. For further details, see Section 7.1 in [RFC3776] 🧚.
This document proposes a security framework based on TLS-protected establishment of Mobile IPv6 security associations 🌈. It reduces implementation complexity while maintaining an equivalent (to IKEv2/IPsec) level of security 💜.
4. TLS-Based Security Establishment ✨
4.1. Overview
The security architecture proposed in this document relies on a secure TLS session established between the MN and the HAC for mutual authentication and MN-HA security association bootstrapping 🔐. The HAC authenticates itself through standard TLS operation, where it uses a TLS server certificate as its credentials 📜. The HAC authenticates the MN through signaling messages that are secured by the TLS connection 🫶. Any Extensible Authentication Protocol (EAP) method or Pre-Shared Key (PSK) can be used to authenticate the MN to the HAC 🦋. Once authentication succeeds, the HAC generates keys and delivers them to the MN through the secure TLS channel 💖. The same keys are also provided to the assigned HA ✨. The HAC also hands the MN its MIPv6 bootstrapping information, such as the IPv6 and IPv4 address of the HA, the home network prefix, the IPv6 and/or IPv4 Home Address (HoA), and the DNS server address 🎀.
The MN and HA use security associations based on the keys and Security Parameter Indexes (SPIs) that the HAC generates and delivers to the MN and HA 🌸. They use these to secure signaling and, optionally, user plane traffic 🍓. Figure 1 below illustrates the process 👑.
Signaling messages and user plane traffic between the MN and HA are always UDP encapsulated 🌊. The packet formats for the signaling and user plane traffic are described in Sections 6.3 and 6.4 📦.
MN HAC HA
-- --- --
| | |
| /-------------------------\ | |
|/ \| |
|\ TLS session setup /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ MN Authentication \| |
|\ /| |
| \-------------------------/ | |
| | |
| /-------------------------\ | |
|/ HAC provisions the MN \| |
|\ keys, SPI, & MIPv6 parms /| |
| \-------------------------/ | |
| | |
| |--MNID, keys, SPI->|
| | |
| /--------------------------------------------\ |
|/ MN-HA SA established; Secures \ |
|\ signaling and optionally user traffic / |
| \--------------------------------------------/ |
| |
|------------BU(encrypted)----------------------->|
| |
|<---------BAck(encrypted)------------------------|Figure 1: High-Level Architecture
4.2. Architecture
The TLS-based security architecture is shown in Figure 2 🏗️. The signaling message exchange between the MN and the HAC is protected by TLS 🔒. It should be noted that an HAC, a AAA server, and an HA are logically separate entities, and they can be collocated in all possible combinations 🧩. There MUST be a strong trust relationship between the HA and the HAC 💪, and the communication 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 2: TLS-Based Security Architecture Overview
4.3. Security Association Management
Once the MN has contacted the HAC and mutual authentication has taken place between the MN and the HAC, the HAC securely provisions the MN with all security-related information inside the TLS protected tunnel 🚇. This security-related information makes up 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 📨. Or the HA may query the SA information from the HAC once the MN contacts the HA 🔍. If the HA requests SA information from the HAC, then the HA MUST be able to query and index the SA information from the HAC based on the SPI that identifies the correct security association between the MN and the HA 🗂️.
The HA may want the MN to re-establish the SA even if the existing SA is still valid 🔄. The HA can tell the MN this using a dedicated Status Code in a BA (value set to REINIT_SA_WITH_HAC) 🚩. As a result, the MN SHOULD contact the HAC before the SA times out, and the HAC would provision the MN and HAs with a new SA to be used from then on ✨.
The SA established between the MN and HAC SHALL contain at least the following information 📋:
- Mobility SPI: This parameter is an 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. The HAC assigns the SPI values. The HAC MUST ensure uniqueness of the SPI values across all MNs controlled by the HAC 🔑.
- MN-HA keys for ciphering: A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering Mobile IPv6 traffic between the MN and the HA. The HAC is responsible for generating these keys. The key generation algorithm is specific to the HAC implementation 🔐.
- MN-HA shared key for integrity protection: A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity protecting Mobile IPv6 traffic between the MN and the HA. This covers both binding management messages and reverse-tunneled user data traffic between the MN and the HA. The HAC is responsible for generating these keys. The key generation algorithm is specific to the HAC implementation. In the case of combined algorithms, a separate integrity protection key is not needed and may be omitted, i.e., the encryption keys SHALL be used 🧁.
- Security association validity time: This parameter represents the validity time for the security association. The HAC is responsible for defining the lifetime value based on its policies. The lifetime may be on the order of hours or weeks ⏳. The MN MUST re-contact the HAC before the SA validity time ends ⏰.
- Security association scope: This parameter defines whether the security association is applied to Mobile IPv6 signaling messages only, or to both Mobile IPv6 signaling messages and data traffic 🎯.
- Selected ciphersuite: This parameter is the ciphersuite used to protect the traffic between the MN and the HA. This covers both binding management messages and reverse-tunneled user data traffic between the MN and the HA. The selected algorithms SHOULD be one of the mutually supported ciphersuites of the negotiated TLS version between the MN and the HAC. The HAC is responsible for choosing the mutually supported ciphersuite that complies with the policy of the HAC. Obviously, the HAs under the HAC's management must have at least one ciphersuite in common with the HAC, and they need to be aware of the implemented ciphersuites 🧠. The selected ciphersuite is the same for both directions (MN -> HA and HA -> MN) 🪞.
- Sequence numbers: A monotonically increasing unsigned sequence number used in all protected packets exchanged between the MN and the HA in the same direction. Sequence numbers are maintained per direction, so each SA includes two independent sequence numbers (MN -> HA, HA -> MN). The initial sequence number for each direction MUST always be set to 0 (zero). Sequence numbers cycle back to 0 (zero) when they increase beyond their maximum defined value 🔢.
4.4. Bootstrapping of Additional Mobile IPv6 Parameters
When the MN contacts the HAC to receive the security-related information, the HAC may also provision the MN with various MIPv6-related bootstrapping information 🎁. Bootstrapping of the following information SHOULD at least be possible 💅:
- Home Agent IP Address: The IPv6 and IPv4 address of the home agent assigned by the HAC 🏠.
- Mobile IPv6 Service Port Number: The port number where the HA is listening to UDP [RFC0768] packets 🚪.
- Home Address: The IPv6 and/or IPv4 home address assigned to the mobile node by the HAC 🏡.
- Home Link Prefix: Concerns the IPv6 Home link prefix and the associated prefix length 🛣️.
- DNS Server Address: The address of a DNS server that can be reached via the HA. DNS queries in certain cases cannot be routed to the DNS servers assigned by the access network to which the MN is attached. Hence, an additional DNS server address that is reachable via the HA needs to be configured 🌐.
The MIPv6-related bootstrapping information is delivered from the HAC to the MN over the same TLS protected tunnel as the security-related information 🚇💖.
4.5. Protecting Traffic between Mobile Node and Home Agent
okay bestie, this part is all about locking down the MN-HA connection 🔒✨ The same integrity and confidentiality algorithms MUST be used to protect both the binding management messages and the reverse-tunneled user data traffic between the MN and the HA 💅 Generally, every binding management message (BUs, BAs, and so on) MUST be integrity protected 🫶 and SHOULD be confidentially protected 🔐 The reverse-tunneled user data SHOULD be equivalently protected too 🌸 And the requirements in [RFC6275] about protecting traffic between the MN and the HA also apply to the mechanisms defined here 🦋
5. MN-to-HAC Communication ✨
5.1. Request-Response Message Framing over TLS-Tunnel
okay so the MN and the HAC talk to each other using a super simple lockstep request-response protocol 🎀 that runs inside the protected TLS-tunnel 🔐 There's a generic message container framing for the requests and for the responses. These containers are only meant to be exchanged on top of a connection-oriented TLS-layer 🌈 so the end of the message exchange is determined by the other end closing the transport connection (assuming the "application layer" has also indicated the message exchange is finished) 💀 The peer that starts the TLS connection is always sending "Requests" 💜 and the peer that accepts the TLS connection is always sending "Responses" ✨ The message container format is shown in Figure 3 🧚
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 🙈
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.. ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Request-Response Message ContainerThe 3-bit Ver field tells you the protocol version 🦋 The current version is 0, i.e., all bits are set to a value of 0 (zero) 💖
The Rsrvd field MUST be set to a value of 0 (zero), 🌸
The Identifier field is what matches requests with 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 value set to 1 👑
The Length field tells you the length of the Content portion of the container (i.e., the Reserved octet, Identifier octet, and Length field are excluded) 📏 The Content portion length MUST always be at least one octet and up to 65535 octets 🌈 The value is in network order ✨
5.2. Request-Response Message Content Encoding
the encoding of the message content is giving HTTP header encoding vibes 💅 and it complies with the augmented Backus-Naur Form (BNF) defined in Section 2.1 of [RFC2616] 🎀 All the hexadecimal numbers shown are in network byte order 🔢 From now on, we're calling the request-response message content HTTP-like headers the TypeValue header (TV-header) term 🫶
5.3. Request-Response Message Exchange
the message exchange between the MN and the HAC is a simple lockstep request-response type, as we covered in Section 5.1 🔁 A request message includes a monotonically increasing Identifier value that gets copied to the matching response message 💜 Each request MUST have a different Identifier value 🙈 So a reliable connection-oriented transport below the message container framing is assumed 🦋 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 always the peer that 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 🔐
If there's an HAC-side error, the HAC MUST send a response back to the 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:
- MN-Identity - See Section 5.5.1.
- Authentication Method - See Section 5.5.2.
The first response message, MHAuth-Init (i.e., the Identifier is 1), MUST contain at minimum the following parameters:
- Selected authentication Method - See Section 5.5.2.
The last request message from the MN side, MHAuth-Done, MUST contain the following parameters:
- Security association scope - See Section 5.6.4.
- Proposed ciphersuites - See Section 5.6.5.
- Message Authenticator - See Section 5.5.5.
The last response message, MHAuth-Done, which ends the request-response message exchange, MUST contain the following parameters:
- Status Code - See Section 5.5.4.
- Message Authenticator - See Section 5.5.5.
If authentication succeeds, these additional parameters show up too 🎉
- Selected ciphersuite - See Section 5.6.5.
- Security association scope - See Section 5.6.4.
- The rest of the security association data - See Section 5.6.
5.4. Home Agent Controller Discovery
all the bootstrapping info, whether it's for setting up the SA or for bootstrapping MIPv6-specific info, gets exchanged between the MN and the HAC using the framing protocol from Section 5.1 📦 The IP address of the HAC MAY be statically configured in the MN, or it MAY be dynamically discovered using DNS 🗺️ For DNS-based HAC discovery, the MN queries either an A/AAAA or an SRV record for the HAC IP address 🔍 The actual domain name used in queries is up to the deployment to decide and is out of scope for this specification 🤷♀️
5.5. Generic Request-Response Parameters
the grammar in the following sections is the augmented Backus-Naur Form (BNF), same as what HTTP uses [RFC2616] 📖
5.5.1. Mobile Node Identifier
this is just an identifier that identifies an MN 🪪 The Mobile Node Identifier is in the form of a Network Access Identifier (NAI) [RFC4282] 💅
mn-id = "mn-id" ":" RFC4282-NAI CRLF5.5.2. Authentication Method
the HAC is the peer that mandates the authentication method 👑 The MN sends its authentication method proposal to the HAC, and the HAC, once it gets that proposal, sends back the selected authentication method 🔁 The MN MUST propose at least one authentication method 🙌 The HAC MUST select exactly one authentication method or return an error and then close the connection 🚪
auth-method = "auth-method" ":" a-method *("," a-method) CRLF
a-method =
"psk" ; PSK-based authentication
| "eap" ; EAP-based authentication5.5.3. Extensible Authentication Protocol Payload
each Extensible Authentication Protocol (EAP) [RFC3748] message is an encoded string of hexadecimal numbers 🔢 The "eap-payload" is completely transparent as to which EAP-method or EAP message is carried inside it 🫥 The "eap-payload" can show up in both request and response messages 🎀
eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF5.5.4. Status Code
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 to the status codes listed below 📋
status-code = "status-code" ":" status-value CRLF
status-value =
"100" ; Continue
| "200" ; OK
| "400" ; Bad Request
| "401" ; Unauthorized
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "503" ; Service Unavailable
| "504" ; Gateway Time-out5.5.5. Message Authenticator
the "auth" header holds the data used for authentication purposes 🔐 It MUST be the last TV-header in the message, and it's calculated over the whole message up until the start of the "msg-header" 🧮
msg-auth = "auth" ":" 1*(HEX HEX) CRLF5.5.6. Retry After
retry-after = "retry-after" ":" rfc1123-date CRLF5.5.7. End of Message Content
end-of-message = 2CRLF5.5.8. Random Values
random numbers generated by the MN and the HAC, respectively 🎲 The length of the random number MUST be 32 octets (before TV-header encoding) 💯
mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF
hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF5.6. Security Association Configuration Parameters
during 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 version 1.2 (see Appendix A.5 of [RFC5246]) per Section 5.6.5 🎯 This might seem like a constraint, since the HA and the HAC may have implemented different ciphersuites 🤔 But these two nodes are assumed to belong to the same administrative domain 🏠 So 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 confidentiality protection 🔒
Section 5.6.5 maps the TLS ciphersuites to the integrity and encryption algorithms allowed for MN-HA protection 🗂️ This mapping mostly ignores the authentication algorithm part, which isn't required within the context of this specification 🙅♀️ For example, [RFC5246] defines a bunch of AES-based ciphersuites for TLS, includingTLS_RSA_WITH_AES_128_CBC_SHA. For this specification, the relevant part isAES_128_CBC_SHA🍰
All the parameters in the following sections apply only to a request-response protocol response message to the MN 📨 The MN has no way of affecting the provisioning decision of the HAC 😤
5.6.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 🚫 So values from 1 to 268435455 are valid 💜
The TV-header for the SPI number looks like this:
mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF5.6.2. MN-HA Shared Keys
the MN-HA shared integrity (ikey) and encryption (ekey) keys protect the traffic between the MN and the HA 🗝️ The length of these keys depends on the selected ciphersuite 📏
The TV-headers that carry these two parameters are:
mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF
mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF
mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF5.6.3. Security Association Validity Time
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 for the SA validity time value looks like this:
mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date CRLF5.6.4. Security Association Scope (SAS) 💖
Okay so an SA can protect just the Mobile IPv6 signaling messages, or it can cover both the signaling and the data traffic 🫶. This policy MUST be agreed between the MN and HA before anyone uses the SA, bestie. Otherwise the receiving side won't know whether the SA covers data traffic, so it can't decide what to do when it gets unprotected packets of PType 1 (see Section 6.4) 💀.
mip6-sas = "mip6-sas" ":" 1DIGIT CRLFHere, a value of "O" means the SA does not protect data traffic, and a value of "1" means all data traffic MUST be protected by the SA. If the mip6-sas value of an SA is set to 1, any packet received with a PType value that does not match the mip6-sas value of the SA MUST be silently discarded 🚫.
The HAC is the peer that mandates the security association scope that gets used. The MN sends its proposal to the HAC, but in the end, the scope the HAC sends back is the one that defines what gets used ✨.
5.6.5. Ciphersuites and Ciphersuite-to-Algorithm Mapping 🦋
The ciphersuite negotiation between the HAC and the MN uses a subset of the TLS 1.2 ciphersuites, and it follows the TLS 1.2 numeric representation defined in Appendix A.5 of [RFC5246]. These are the TV-headers for the selected ciphersuite and the ciphersuite list 🎀:
mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF
csuite = "{" suite "}"
suite =
"00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02}
| "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B}
| "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A}
| "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F}
| "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C}
mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLFAll other Ciphersuite values are reserved 🙈.
The following integrity algorithms MUST be supported by all implementations 🔥:
HMAC-SHA1-96 [RFC2404]
AES-XCBC-MAC-96 [RFC3566]The binding management messages between the MN and HA MUST be integrity protected. Implementations MUST NOT use a NULL integrity algorithm 🙅♀️.
The following encryption algorithms MUST be supported 💜:
NULL [RFC2410]
TripleDES-CBC [RFC2451]
AES-CBC with 128-bit keys [RFC3602]Traffic between MN and HA MAY be encrypted. Any integrity-only Ciphersuite makes use of the NULL encryption algorithm 🌸.
Note: This document does not consider combined algorithms. The table below maps each ciphersuite to a combination of integrity and encryption algorithms that are part of the negotiated SA between MN and HA 🍓.
+-------------------+-----------------+--------------------------+
|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 |
+-------------------+----------------+---------------------------+Ciphersuite-to-Algorithm Mapping
5.7. Mobile IPv6 Bootstrapping Parameters ✨
In parallel with the SA bootstrapping, the HAC SHOULD provision the MN with relevant MIPv6-related bootstrapping information 🧚.
These generic BNFs are used to form IP addresses and prefixes. They get used in the sections that follow 💅.
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
ip4-subnet = ip4-addr "/" 1*2DIGIT5.7.1. Home Agent Address 🏡
The HAC MAY provision the MN with an IPv4 or an IPv6 address of an HA, or both 🦋.
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF5.7.2. Mobile IPv6 Service Port Number 🔌
The HAC SHOULD provision the MN with a UDP port number, where the HA expects to receive UDP packets. If this parameter is not present, then the IANA reserved port number (mipv6tls) MUST be used instead 👑.
mip6-port = "mip6-port" ":" 1*5DIGIT CRLF5.7.3. Home Addresses and Home Network Prefix 🌈
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 🫶.
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF
mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF
mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF5.7.4. DNS Server 🧁
The HAC may also provide the MN with DNS server configuration options. These DNS servers are reachable via the home agent 💜.
dns-ip6 = "dns-ip6" ":" ip6-addr CRLF
dns-ip4 = "dns-ip4" ":" ip4-addr CRLF5.8. Authentication of the Mobile Node 🔐
This section describes the basic operation required for the MN-HAC mutual authentication and the channel binding. The authentication protocol described here is a simple exchange that follows the Generalized Pre-Shared Key (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 [RFC5929]. Because of that 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 PSK or based on an EAP-method (see Section 5.9). Note that an HAC MUST NOT allow MNs to renegotiate TLS sessions 🚨. 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 [RFC5929], 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. Compared to GPSK, it does not support exchanging an encrypted container, because it always runs through an already protected TLS tunnel. Also, the initial request of the authentication exchange (MHAuth-Init) is sent by the MN (client side). It is comparable to EAP-Response/Identity, which reverses the roles of request and response messages compared to EAP-GPSK. Figure 4 shows a successful protocol exchange 📸.
MN HAC
| |
| Request/MHAuth-Init (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Init (...) |
|<------------------------------------------------------|
| |
| Request/MHAuth-Done (...) |
|------------------------------------------------------>|
| |
| Response/MHAuth-Done (...) |
|<------------------------------------------------------|
| |Figure 4: Authentication of the Mobile Node Using Shared Secrets
- Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=psk- Response/MHAuth-Init: (MN <- HAC)
[mn-rand, hac-rand, auth-method=psk, [status],] auth- Request/MHAuth-Done: (MN -> HAC)
mn-rand, hac-rand, sa-scope, ciphersuite-list, auth- Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand,
hac-rand, status, authWhere 'auth' for the MN -> HAC direction is as follows 🧮:
auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets)Where 'auth' for the MN <- HAC direction is as follows:
auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets)In the above, "MN" is 2 ASCII characters without null termination, and "HAC" is 3 ASCII characters without null termination. The length of "mn-rand" and "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, which 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 [RFC5929] 💫.
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. Deciding which authentication method to offer and which to pick is policy and implementation dependent, and therefore it is 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 Message Authentication Code (MAC) and the consistency of the identities, nonces, and ciphersuite parameters transmitted in MHAuth-Auth. If the verification succeeds, 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 🥳.
5.9. Extensible Authentication Protocol Methods ✨
okay so this section is all about the basic flow for MN-HAC mutual authentication when you're using EAP-based methods 🔐 it's giving handshake energy, and the diagram below shows the whole vibe, step by step 💖
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) |
|<------------------------------------------------------|
| |
Figure 5: Authentication of the Mobile Node Using EAPHere's the message-by-message breakdown 🎀 each step lists which fields ride along:
- Request/MHAuth-Init: (MN -> HAC)
mn-id, mn-rand, auth-method=eap - Response/MHAuth-Init: (MN <- HAC)
[auth-method=eap, eap, [status,]] auth - Request/MHAuth-Mid: (MN -> HAC)
eap, auth - Response/MHAuth-Mid: (MN <- HAC)
eap, auth
The MHAuth-Mid exchange gets repeated as many times as the used EAP-method needs 🔁
- Request/MHAuth-Done: (MN -> HAC)
sa-scope, ciphersuite-list, eap, auth - Response/MHAuth-Done: (MN <- HAC)
[sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, status, auth
Now the auth value itself 🔥 for the MN -> HAC direction it's built like this:
auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets)
And for the MN <- HAC direction it's this:
auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets)
Quick note: in the above, "MN" is 2 ASCII characters without null termination, and "HAC" is 3 ASCII characters without null termination. Tiny detail, big energy 💅
About shared-key 🔑 in MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If the EAP-method is key-deriving and creates a shared Master Session Key (MSK) as a side effect of Authentication, then the shared-key MUST be the MSK in all MHAuth-Done messages. This MSK MUST NOT be used for any other purpose, bestie, so don't go reusing it 🙈 In case the EAP method does not generate an MSK, 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, which 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 [RFC5929] 🌸
6. Mobile Node to Home Agent Communication 🦋
6.1. General
okay so this subsection covers the packet formats for all the traffic going between the MN and the HA ✨ that includes binding management messages (like BU and BA messages), reverse-tunneled and encrypted user data, and reverse-tunneled plaintext user data. This specification defines one generic packet format, where everything is encapsulated inside UDP. For the detailed pictures, check out Sections 6.3 and 6.4 🧚
The Mobile IPv6 service port number is where the HA expects to receive UDP packets. The same port number gets used for both binding management messages and user data packets, and the reason for multiplexing data and control over the same port is the possibility of Network Address and Port Translators sitting 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 it MUST use the Mobile IPv6 service port number as the UDP destination port. The Mobile IPv6 service port is dynamically assigned to the MN during the bootstrapping phase (i.e., the mip6-port parameter) or, if the bootstrapping parameter is absent, the IANA reserved port (mipv6tls) MUST be used 👑
The encapsulating UDP header is immediately followed by a 4-bit Packet Type (PType) field. This field defines whether the packet contains an encrypted mobility management message, an encrypted user data packet, or a plaintext user data packet 💜
The Packet Type field is followed by a 28-bit SPI value, which identifies the correct SA for 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, so they MUST NOT be sent with an SPI value of 0 (zero). Lowkey strict but that's the point 😭
There is always only one SPI per MN-HA mobility session, and the same SPI gets used for all types of protected packets, no matter the direction ✨
The SPI value is followed by a 32-bit Sequence Number value. It's used to identify retransmissions of protected messages (integrity protected, or both integrity protected and encrypted, see Figures 7 and 8) 🔥 Each endpoint in the security association keeps 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, and that's totally normal 💅 In the case where data protection is not used (see Figure 9), the Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD initiate a re-establishment of the SA before any of the Sequence Number cycle, so it doesn't get caught off guard 🙈
Finally, the Sequence Number field is followed by the data portion, and its content is identified by the Packet Type. The data portion may be protected 🌈
6.2. PType and Security Parameter Index 💖
The PType is a 4-bit field that indicates the Packet Type (PType) of the UDP encapsulated packet. The PType is followed by a 28-bit SPI value. The PType and the SPI fields are treated as one 32-bit field during the integrity protection calculation, so they're basically a unit now 🫶
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Parameter Index with Packet TypeA SPI value of 0 (zero) indicates a plaintext packet. If the packet is integrity protected or both integrity protected and encrypted, the SPI value MUST be different from 0. When the SPI value is set to 0, then the PType MUST also be 0. Zero means plaintext, and that's a whole vibe 🧁
6.3. Binding Management Message Formats 🎀
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 7 🔐
All packets that are specific to the Mobile IPv6 protocol, contain a Mobility Header (as defined in Section 6.1.1. of RFC 6275), and are used between the MN and the HA shall use the packet format shown in Figure 7. (This means that some Mobile IPv6 mobility management messages, such as the Home Test Init (HoTI) message, are treated as data packets and use the encapsulation described in Section 6.4 and shown in Figures 8 and 9.) 🧚
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) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UDP-Encapsulated Binding Management Message FormatThe PType value 8 (eight) identifies that the UDP-encapsulated packet contains a Mobility Header (defined by RFC 6275) 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 the 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 Sections 2.4 to 2.8 of [RFC4303], unless otherwise stated in this document. For an 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 7) use the current CoA of the MN and the HA address ⭐
6.4. Reverse-Tunneled User Data Packet Formats ✨
okay so there are two kinds of reverse-tunneled user data packets zooming between the MN and the HA 🦋: the ones that get integrity protected and/or encrypted, and the ones sent in the clear 🙈. The MN or the HA picks which one to do based on the mip6-sas value in the SA. If the mip6-sas is set to 1, the originator MUST NOT send any user data packets in the clear, and the receiver MUST silently discard any packet with the PType set to 0 (unprotected). It is RECOMMENDED that confidentiality and integrity protection of user data traffic be applied 🔐. The reverse-tunneled IPv4 or IPv6 user data packets get encapsulated as is inside the 'Payload Data' shown in Figures 8 and 9 💜.
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) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: UDP-Encapsulated Protected User Data Packet Format
The PType value 1 (one) tells you the UDP-encapsulated packet holds 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 an SPI value of 0 (zero) that means 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 8) use the current CoA of the MN and the HA address 🌸. The ESP-protected inner IP header, which is not shown in Figure 8, 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) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: UDP-Encapsulated Non-Protected User Data Packet Format
The PType value 0 (zero) tells you the UDP-encapsulated packet holds 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 9) use the current CoA of the MN and the HA address 💅. The plaintext inner IP header uses the home address of the MN and the CN address 🫶.
7. Route Optimization 🦋
Mobile IPv6 route optimization as described in [RFC6275] is not affected by this specification 🙌. Route optimization is only possible between an IPv6 MN and CN 👑. UDP encapsulation of signaling and data traffic is only between the MN and HA 🌈. The return routability signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are treated as data packets, and encapsulation, when needed, is per the description in Section 6.4 of this specification 💜. The data packets between an MN and CN that have successfully completed the return routability test and created the appropriate entries in their binding cache are not UDP encapsulated using the packet formats defined in this specification but follow the [RFC6275] specification ✨.
8. IANA Considerations 📋
8.1. New Registry: Packet Type
IANA has created a new registry under the [RFC6275] Mobile IPv6 parameters registry for the Packet Type as described in Section 6.1 🧁.
Description | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8Following the allocation policies from [RFC5226], new values for the Packet Type AVP MUST be assigned based on the "RFC Required" policy. 🎀
8.2. Status Codes
A new Status Code (to be used in BA messages) is reserved for the cases where the HA wants to tell the MN that it needs to re-establish the SA information with the HAC 🔄. The following value is reserved in the [RFC6275] Status Codes registry:
REINIT_SA_WITH_HAC 1768.3. Port Numbers
A new port number (mipv6tls) for UDP packets is reserved from the existing PORT NUMBERS registry 🔢.
mipv6tls 78729. Security Considerations 🛡️
This is the part where we get SERIOUS, bestie 😭🔥 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 👀:
- Discovery of the HAC
- Authentication and MN-HA SA establishment executed between the MN and the HAC (PSK- or EAP-based) through a TLS tunnel
- Protection of MN-HA communication
- AAA interworking
9.1. Discovery of the HAC
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 💖.
9.2. Authentication and Key Exchange Executed between the MN and the HAC ✨
Okay bestie, this part is about how the MN and the HAC prove who they are and swap SA details, all inside TLS 🔐. The TLS procedures themselves stay exactly the same, but channel binding gets layered on top 🎀.
Authentication: Server-side certificate-based authentication MUST be performed using TLS version 1.2 [RFC5246]. The MN MUST verify the HAC's TLS server certificate, using either the subjectAltName extension [RFC5280] dNSName identities as described in [RFC6125] or subjectAltName iPAddress identities. For iPAddress identities, the MN MUST check the IP address of the TLS connection against those iPAddress identities, and it SHOULD reject the connection if none of them match 🙅♀️. For dNSName identities, the rules and guidelines in [RFC6125] apply, with these extra considerations:
- Support for the DNS-ID identifier type (the dNSName identity in the subjectAltName extension) is REQUIRED in both the HAC and the MN TLS implementations 💅.
- DNS names in the HAC server certificates MUST NOT contain the wildcard character "*" 🚫.
- The CN-ID MUST NOT be used for authentication within the rules described in [RFC6125] 💀.
- The MN MUST set its "reference identifier" to the DNS name of the HAC 🎯.
Client-side authentication depends on the deployment, so it isn't mandated 🤷♀️. Also, TLS-PSK [RFC4279] can't be used alongside the methods in Sections 5.8 and 5.9 of this document, because of the limits of the channel binding type used 🙃.
Through the protected TLS tunnel, there's an extra authentication exchange that gives client-side or mutual authentication, swaps SA parameters, and can carry optional configuration data for protecting MN-HA traffic afterwards ✨. This extra exchange can be PSK-based (Section 5.8) or EAP-based (Section 5.9). Both are always run inside the protected TLS tunnel and MUST NOT be used as standalone protocols 🚫🔒.
The simple PSK-based exchange gives mutual authentication and follows the GPSK exchange used by EAP-GPSK [RFC5433]. It has similar properties, although some GPSK features, like exchanging a protected container, aren't supported 🧚.
The EAP-based exchange just defines message containers for carrying EAP packets between the MN and the HAC 📦. In principle, any EAP method works. Still, it's strongly recommended to use only EAP methods that provide mutual authentication and derive keys including an MSK in compliance with [RFC3748] 👑.
Both exchanges use channel binding with the TLS tunnel. The channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be used 🔗.
Dictionary Attacks: Every message in the authentication exchanges defined here is protected by TLS 🛡️. Even so, any implementation SHOULD assume the authentication exchange has the same properties as GPSK [RFC5433] when the PSK-based method per Section 5.8 is used, and the same properties as the underlying EAP method when the EAP-based exchange per Section 5.9 is used 👀.
Replay Protection: The underlying TLS protection already guards against replays 🔁.
Key Derivation and Key Strength: For TLS, the TLS-specific considerations apply unchanged 🧠. For the authentication exchanges in this document, there's no separate key derivation step, because the MN-HA keys are generated by the HAC and handed to the MN over the secure TLS connection 🗝️.
Key Control: This version of the specification doesn't provide joint key control for MN-HA keys 🙈.
Lifetime: The TLS-protected authentication exchange between the MN and the HAC only exists to bootstrap keys and other parameters for MN-HA security 🌱. The SAs holding those keys have an associated lifetime ⏳. TLS Session Resumption without Server-Side State, described in [RFC5077], lets the MN cut the latency of future exchanges toward the HA without the HA having to keep any state itself 🚀.
Denial-of-Service (DoS) Resistance: The DoS resistance SHOULD be considered the same as for common TLS operation, since TLS is used unchanged 🛡️. For the PSK-based exchange, no additional factors are known. For the EAP-based exchange, any DoS considerations specific to the chosen EAP method are expected to apply and need to be taken into account ⚠️.
Session Independence: Each TLS protocol run is independent from any previous exchange, based on the security properties of the TLS handshake protocol 🦋. That said, several PSK- or EAP-based authentication exchanges can happen over the same TLS connection 🔁.
Fragmentation: TLS runs on top of TCP, so no fragmentation-specific considerations apply to the MN-HAC authentication exchanges 📏.
Channel Binding: Both the PSK and the EAP-based exchanges use channel binding with the TLS tunnel. The channel binding type 'TLS-server-endpoint' per [RFC5929] MUST be used 🔗✨.
Fast Reconnect: This protocol provides session resumption as part of TLS, and optionally supports [RFC5077] 🏃♀️. No fast reconnect is supported for the PSK-based exchange. For the EAP-based exchange, fast reconnect depends on the EAP method used 🤞.
Identity Protection: Thanks to the TLS tunnel, passive user identity protection is provided 🙈. Still, an attacker acting as a man-in-the-middle in the TLS connection would be able to see the MN identity value sent in MHAuth-Init messages 👁️.
Protected Ciphersuite Negotiation: This protocol provides ciphersuite negotiation based on TLS 🔐.
Confidentiality: Payloads exchanged between the MN and the HAC are protected by the TLS Record Layer 🔒. TLS ciphersuites with confidentiality and integrity protection MUST be negotiated and used in order to exchange security-sensitive material inside the TLS connection 💎.
Cryptographic Binding: This protocol, as specified in this document, provides no cryptographic bindings 🙅♀️.
Perfect Forward Secrecy: Perfect forward secrecy is provided with appropriate TLS ciphersuites 🌈.
Key confirmation: Key confirmation of the keys established with TLS is provided by the TLS Record Layer once those keys are used to protect the subsequent TLS exchange 🫶.
9.3. Protection of MN and HA Communication 🧚
Authentication: Data origin authentication is provided for communication between the MN and the HA 📨. How strong that authentication is depends on the selected ciphersuite 💪. Entity authentication is offered by the MN to HAC protocol exchange 🙋♀️.
Dictionary Attacks: Dictionary attacks don't apply to MN-HA communication, because the keying material is randomly created by the HAC, and its length depends on the chosen cryptographic algorithms 🎲.
Replay Protection: Replay protection for MN-HA communication is based on sequence numbers and follows the design of IPsec ESP 🔢.
Key Derivation and Key Strength: The strength of the keying material for MN-HA communication is selected based on the negotiated ciphersuite (from the MN-HAC exchange) and the key created by the HAC 💪. The randomness requirements for security in [RFC4086] apply to the key generation done by the HAC 🎰.
Key Control: The keying material made during the MN-HAC exchange for protecting MN-HA communication is created by the HA, so no joint key control is provided for it 🙅♀️.
Key Naming: For MN-HA communication, security associations are indexed using the SPI, and also by direction (inbound or outbound) 🏷️.
Lifetime: The lifetime of MN-HA security associations is based on the value in the mip6-sa-validity-end header field exchanged during the MN-HAC exchange ⏰. The HAC controls the SA lifetime 👑.
DoS Resistance: MN-HA communication doesn't involve heavy cryptographic operations, like public key computations, so there are no DoS concerns here 😌.
Session Independence: Sessions are independent of each other when new keys are created via the MN-HAC protocol ✨. Each new MN-HAC protocol run produces fresh, unique keying material for protecting MN-HA communication 🌸.
Fragmentation: No extra fragmentation support is provided beyond what the network layer offers 📦.
Channel Binding: Channel binding doesn't apply to MN-HA communication 🙈.
Fast Reconnect: Fast reconnect doesn't apply to MN-HA communication 🙅♀️.
Identity Protection: User identities SHOULD NOT be exchanged between the MN and the HA 🙊. If binding management messages do contain the user identity, those messages SHOULD be confidentiality protected 🔐.
Protected Ciphersuite Negotiation: The MN-HAC protocol provides protected ciphersuite negotiation through a secure TLS connection 🎀.
Confidentiality: Payloads exchanged between the MN and the HAC (for Mobile IPv6 signaling and optionally for data traffic) are protected using algorithms negotiated during the MN-HAC exchange 🔒.
Cryptographic Binding: This protocol, as specified in this document, provides no cryptographic bindings 🙅♀️.
Perfect Forward Secrecy: Perfect forward secrecy is provided when the MN bootstraps new keying material with the MN-HAC protocol, assuming a proper TLS ciphersuite is used 🌈.
Key Confirmation: Key confirmation of the MN-HA keying material conveyed from the HAC to the MN happens when the first packets are exchanged between the MN and the HA, in both directions, since two different keys are used 🫶.
9.4. AAA Interworking 🏢
AAA backend infrastructure interworking isn't defined in this document, so it's out of scope 🙅♀️.
10. Acknowledgements 🫶
The authors would like to thank Pasi Eronen, Domagoj Premec, Julien Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and Christian Bauer for their comments 💜.
11. References 📚
11.1. Normative References 💅
Okay bestie, these are the must-reads 📚 If you're implementing anything from this doc, you need these, no cap 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[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.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.11.2. Informative References 🌸
These ones are the background tea ☕ Super useful for context, but you don't strictly need them to get the core ideas, iykyk 🦋
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[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.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, February 2009.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.Authors' Addresses 🎀
Meet the squad who wrote this thing 🫶 Here's how to reach them 💌
Jouni Korhonen (editor)
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
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
Dirk Kroeselberg
Siemens
Otto-Hahn-Ring 6
Munich 81739
Germany
EMail: dirk.kroeselberg@siemens.com📦 where this page comes from
- ietf: rfc6618 2012-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms