RFC 5419
Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
Okay bestie, RFC 5419 is here and it is SO giving 🎀
- Title: Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
- Series: Network Working Group, Request for Comments 5419 🦋
- Authors: B. Patil (Nokia) and G. Dommety (Cisco) 💖
- Category: Informational 🌸
- Date: January 2009 📅
- Obsoletes / Updates: the title block doesn't list anything here 🧚
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🫶
Copyright Notice 💅
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. 📜
Abstract 🔮
Okay so Mobile IPv6 defines a set of signaling messages that let the mobile node (MN) authenticate and register with its home agent (HA). Normally, those authentication messages are protected by an IPsec security association (SA) set up between the MN and HA. 🔐
The MIP6 working group came up with a way to secure the Binding Update (BU) and Binding Acknowledgement (BAck) messages with an authentication option. It's similar to the one in Mobile IPv4, and it rides inside the signaling messages exchanged between the MN and HA to set up a binding. This document explains why that authentication option is needed for Mobile IPv6 deployment in certain environments. 🌈
Table of Contents 🧚
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Background ......................................................3
4. Applicability Statement .........................................3
5. Justification for the Use of the Authentication Option ..........5
5.1. Motivation for Use of the Authentication Option in
CDMA2000 ...................................................5
5.2. Additional Arguments for the Use of the
Authentication Option ......................................6
6. Application of Mobile IPv6 in CDMA Networks .....................9
6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ......9
6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks .....11
6.2.1. Overview of the Mobility Operation in
IPv6-Based CDMA2000 Networks .......................11
6.2.2. Authentication and Security Details ................12
7. Limitations of the Authentication Protocol Option ..............14
8. Security Considerations ........................................16
9. Conclusion .....................................................16
10. Acknowledgements ..............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................181. Introduction 🌸
Mobile IPv6 leans on the IPsec Security Association between the Mobile Node (MN) and the Home Agent (HA) to authenticate the MN to its HA before a binding cache can be created at the HA. 🔐 Sometimes, though, you need an alternate mechanism that doesn't depend on that IPsec SA existing between the MN and HA, and that's what's outlined in [RFC4285]. ✨
This document is meant to capture, for archival purposes, the reasoning behind needing the authentication protocol [RFC4285]. Just to be clear, the alternate solution doesn't mean the IPsec-based solution is going to be deprecated. It simply means that in certain deployment scenarios there's a need to support MIPv6 without an IPsec SA between the MN and HA. So the alternate solution sits in addition to the IPsec-based mechanism specified in the base RFCs, i.e., [RFC3775], [RFC3776], and [RFC4877]. 💅
It's been noted that some of the challenges of deploying MIPv6 in certain networks came from depending on the Internet Key Exchange (IKE), which didn't integrate well with an Authentication, Authorization, and Accounting (AAA) backend infrastructure. IKEv2 solves this problem. 🙈 However, when the need for the authentication protocol was being discussed, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture" [RFC4877] was still a work in progress, so an alternative solution was needed. 🦋
Some of the arguments for specifying the authentication protocol have been made redundant by the specification of Mobile IPv6 operation with IKEv2 [RFC4877]. 🍓 However, some of the arguments discussed in this document still apply and still justify using the authentication protocol in certain deployment environments. 👑
2. Conventions Used in This Document 💜
Here's the key word situation: 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 RFC 2119 [RFC2119]. 🎀
3. Background 🧚
Mobile IPv6 signaling involves several messages. These include:
- The Binding Update/Binding Acknowledgment between the mobile node and the home agent.
- The route optimization signaling messages, which include the HoTI-HoT (Home Test Init/Home Test), CoTI-CoT (Care-of Test Init/Care-of Test), and BU-BAck messages between the MN and CN. HoTI and HoT signaling messages are routed through the MN's HA.
- Mobile prefix solicitation and advertisements between the MN and HA.
- Home agent discovery by MNs.
The signaling messages between the MN and HA are secured using the IPsec SA that's established between these entities. The exception to this is the messages involved in the home agent discovery process. [RFC4877] specifies the establishment of the IPsec SA using IKEv2. ✨
4. Applicability Statement 🌈
The authentication option specified in "Authentication Protocol for MIPv6" [RFC4285] gives us a solution for MIPv6 deployment in environments where an operator may not require IPsec-based security for the signaling. There are lots of reasons an operator might choose to deploy MIPv6 without mandating IPsec for signaling between the MN and HA. Some of these are, for example:
- Operators deploying MIPv6 in cellular networks may consider IPsec and IKEv2 as adding overhead to the limited bandwidth over the air interface. The overhead here is in terms of the bytes that IPsec and IKEv2 introduce to the signaling. 📶
- Operators may consider the number of messages between the MN and HA that are required to establish the IPsec SA as too many. The number of transactions chews into the capacity of limited bandwidth air interfaces when MIPv6 is used in such environments. It also adds latency to the establishment of the binding. 😭
- In many deployments, authentication credentials already exist in a AAA server. These credentials are used for authenticating a user and authorizing network access. The same credentials and security parameters cannot be reused for MIPv6 security as well, if IKEv1 is used. 🔑
- Dynamic assignment of home agents is needed in certain deployments to minimize the latency of the backhaul. This is done by allocating an HA in a visited network, for example. Requiring IPsec SAs with home agents that are dynamically assigned is an overhead, especially when the HA is in a visited network. 🏠
- In certain deployments, signaling messages between the MN and HA may travel over secure link layers. The lower layers provide ciphering and security for the messages, so the need for IPsec to do the same for MIPv6 messages doesn't exist. 🔒
One example of networks with these characteristics is Code Division Multiple Access (CDMA) networks, as defined in the 3GPP2 [3GPP2 X.S0011-002-D] specification. 📡 Mobile WiMAX (Worldwide Interoperability for Microwave Access), which is based on IEEE 802.16e, also specifies MIPv6 in its network architecture, with the default security for signaling being the authentication protocol [RFC4285]. The WiMAX network architecture specifications are available at [WiMAX-NWG]. 🌍
5. Justification for the Use of the Authentication Option 💖
The following two sections explain why the authentication option-based registration process for Mobile IPv6 is needed. Section 5.1 covers the key arguments for using the authentication option. Section 5.2 goes deeper with further explanation and additional motivations for it. 🦋
5.1. Motivation for Use of the Authentication Option in CDMA2000 Wireless Networks ✨
okay so CDMA2000 networks that are running today use Mobile IPv4 for IP mobility 📡, and operators have picked up a ton of real-world experience deploying and running them 💪. 3GPP2 has specified Mobile IPv6 operation in [3GPP2 X.S0011-002-D] 🎀. Here are the deployment constraints existing CDMA networks have to deal with when they roll out IPv6 mobility service 💅:
- Operators want to reuse their MIPv4 deployment and operational experience, so MIPv6 ends up with a similar deployment and operating model 🌸.
- Operators are going to run two parallel networks: one offering IPv4 mobility with MIPv4, and another providing IPv6 mobility with MIPv6 🦋.
- The same backend subscriber profile database, security keys, etc. are supposed to be used for both MIPv4 and MIPv6 service. BUT, from a security standpoint, reusing the same keys with multiple algorithms/protocols is a bad idea 💀.
- The same user configuration information, meaning the identity and keys tied to a user, will be used for IP mobility service in IPv4 and/or IPv6 networks 🧚. The only security association that's preconfigured is a shared secret between the mobile node and the home AAA server. This is different from an earlier version of the Mobile IPv6 model, which needed an IPsec SA between the MN and HA 🙈. When this was written, the IKEv2-based solution for establishing an IPsec SA [RFC4877] wasn't available yet. Still, IKEv2 does enable integration with an AAA backend 🔥.
- When the authentication protocol was being specified, Mobile IPv6 didn't support dynamic assignment of home agent and home address 😭. The MIP6 working group's work on bootstrapping Mobile IPv6, as specified in [RFC5026] and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT], fixes that gap ✨. The mechanism in "Authentication Protocol for Mobile IPv6" [RFC4285] can handle authentication even with dynamic assignments, and it's pretty similar to what current MIPv4 deployments do 👑.
So yeah, MIPv6 as it was specified back then just didn't meet a lot of the deployment requirements 😤. "Authentication Protocol for MIPv6" [RFC4285] together with "MN Identifier Option for MIPv6" [RFC4283] are what make it possible to deploy Mobile IPv6 in a way that's similar to today's CDMA2000 networks 🫶. This authentication model is very similar to the one the MIP4 WG adopted, and [3GPP2 X.S0011-002-D] explains it in detail 📚.
The earlier MIPv6 deployment model needed an IPsec SA that was either configured manually or set up using IKE, and it just doesn't line up with how 3GPP2 or WiMAX networks are deployed 🥲. Good news though: RFC 4877 came out, enabling IPsec SA setup using IKEv2, and it can also plug into the backend AAA infrastructure that handles MN authentication in 3GPP2 and WiMAX networks 🎉.
5.2. Additional Arguments for the Use of the Authentication Option
Using IPsec to do Registration with a home agent isn't always the best move 🙅♀️. Yes, IPsec is seen as a built-in part of the IPv6 stack, but from a deployment point of view it's still a LOT of overhead to use it as the security mechanism for signaling between the MN and HA 😩. We learned this the hard way from deploying Mobile IPv4, and MIPv4 doesn't rely on IPsec to secure its Registration signaling messages at all 🌈.
Mobile IPv6 can only be deployed at a large scale if the protocol is flexible enough to adapt to different scenarios 🦄. The scenario in question is deployment in CDMA2000 or WiMAX networks. CDMA2000 networks are running in lots of countries right now, and WiMAX deployments in many countries started in 2008 ⭐. The CDMA2000 packet data network architecture [3GPP2 X.S0011-002-D] includes a MIPv4 foreign agent/home agent and a RADIUS-based AAA infrastructure for Authentication, Authorization, and Accounting. That AAA infrastructure gives you authentication capability for Mobile IPv4 🔐.
Usually, the mobile node shares a security association with the AAA-Home entity 💜. This is the preferred way to do things instead of having a shared secret between the MN and HA, because the AAA-Home entity is a central place for provisioning and managing shared secrets for a huge number of mobiles (we're talking millions) 🤯. This setup also makes dynamic home address and dynamic home agent assignment way easier 🍓. Mobile IPv6 needs a similar approach for these networks, and there's no practical way to use IPsec directly with the AAA infrastructure without IKEv2 or some other mechanism that sets up the IPsec SA between the MN and HA 🧚♀️.
Mobile IPv6 as specified in [RFC3775] and [RFC3776] is built around a very specific deployment model 🙃. It assumes the mobile node has a static home IPv6 address and a designated home agent. That isn't practical in most of the deployment scenarios being considered 💀. An IPsec SA is expected to be created through manual keying or dynamically through IKE or IKEv2, and those assumptions don't fit well with the deployment model envisioned for CDMA2000 or WiMAX networks 😵. BUT these limitations have been overcome thanks to the bootstrapping specifications in [RFC5026] and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT] 🎀.
CDMA2000 and WiMAX networks would rather hand out home addresses to MNs dynamically 🌸. The perk is that the HA can be assigned on a link close to the MN's point of attachment 📍. Route optimization cancels out some of that benefit, since it isn't always guaranteed that the MN and correspondent node (CN) will use or support route optimization 🤷♀️. Sometimes operators also prefer not to allow route optimization, for reasons like accounting aggregation or enforcing service contracts 📊. In those cases, an HA close to the MN's point of attachment cuts down on the latency and other issues of forward and reverse tunneling of packets between the MN and HA 🚀.
CDMA2000 networks that are running today have huge numbers of subscribers authenticated through the AAA infrastructure 👑. Mobile IPv6 deployment should make use of that existing AAA infrastructure 💖. The security model these networks need is an SA between the MN and AAA-Home entity 🔑. That's the primary security association used for authenticating and authorizing users to access MIPv6 service 🫶. This SA is then used to set up session keys between the MN and the dynamically assigned HA, which authenticate the Binding Updates and Binding Acknowledgements exchanged between them 💫. Setting up an IPsec SA between the MN and HA via AAA infrastructure wasn't specified for Mobile IPv6 back when the authentication protocol was being specified 😭. RFC 3776 explains how IKE is used to set up the SA between the MN and HA ✨. [RFC4877] came out later, so the problem of dynamically setting up an IPsec SA between the MN and HA is no longer a thing 🎉. CDMA2000 operators would like to assign home addresses to the MN dynamically, ideally through the AAA infrastructure, since that's where subscriber profile and capability information lives 🧠. That wasn't possible before the bootstrapping mechanism in [RFC5026] was specified 🙌.
A big chunk of MNs in CDMA2000 networks don't have IKE capability 🥺. Because of that, using RFC 3776 to set up the MN-HA IPsec SA isn't an option for them 🚫. It's also worth noting that IKE needs several transactions before it can set up the IPsec SA 🔄. [RFC4877] describes setting up an IPsec SA between the MN and HA using IKEv2. Not every MN in a deployment is going to support IKEv2, so an alternative mechanism gives the flexibility that's needed 🦋.
CDMA2000 operators are extremely careful about how many messages get sent and received over the air interface for signaling 📶. All that overhead from sending and receiving lots of signaling messages over the air has a direct hit on the operator's overall capacity and cost 💸. Optimizing the number of messages needed to use a service like Mobile IPv6 matters a LOT to them 😤. So IKE for Mobile IPv6 deployment is considered suboptimal in certain network architectures and deployment scenarios, from the message overhead perspective 🙄.
Another downside of using IKE to set up the IPsec SA between the MN and HA is that IKE doesn't integrate very well with the RADIUS-based AAA backend 😬. Operators rely on the AAA infrastructure to provision subscribers and define profiles, keys, etc. in the AAA-Home, so there's no getting around AAA in CDMA2000 networks 💅. IKEv2 does solve this problem 💯. But timing-wise, the IKEv2 specs for "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture" [RFC4877] and their implementations didn't arrive in time for operators who were relying on 3GPP2 specifications 😭. With IKEv2 specified and RFC 4877 published, integration with AAA backends is no longer an issue 🎀.
In summary, the Mobile IPv6 deployment model that required an IPsec SA between the MN and HA, as specified in RFCs 3775 and 3776, was too rigid 🧱. It didn't meet the needs of operators building networks based on the CDMA2000 [3GPP2 X.S0011-002-D] specifications 🙃. To fix that shortcoming, the authentication protocol [RFC4285] was specified 🌈.
6. Application of Mobile IPv6 in CDMA Networks
Sections 6.1 and 6.2 describe the IPv4- and IPv6-based mobility architectures in CDMA networks, respectively 🦋. For further details on the description below, check out Section 5, "MIP6 Operation", in the 3GPP2 specification [3GPP2 X.S0011-002-D] 📚✨.
6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ✨
okay so first up is the Mobile IPv4 setup 🎀 here's the big picture of the key network elements that make IP mobility work with MIPv4:
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAAH| |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /FA | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+Figure 1: CDMA2000 Packet Data Network Architecture with Mobile IPv4
The CDMA mobility architecture based on MIPv4 is giving tightly integrated 🧚 mobility is wired right into the AAA infrastructure. The Mobile Node is configured with an NAI (Network Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key that lives between the MN and the home AAA server, so it's just between the two of them 💜
Below is the access link setup procedure, bestie, so let's go step by step:
(1) Bring up the PPP on the MN/PDSN (access router link). PPP authentication is skipped. Mobile IP authentication is performed via the FA (Foreign Agent).
(2) The PDSN (Packet Data Serving Node) sends a Mobile IP challenge to the MN on the PPP link (RFC 3012).
(3) The MN sends a MIP Registration Request (RRQ), which includes the user's NAI, challenge, and MN-AAA extension that has a challenge response, and an MN-HA extension, which is generated based on the MN-HA key.
(4) The PDSN extracts the MIP NAI, challenge, and the response to the challenge, from the MIP MN-AAA extension, and sends an Access Request to the F-AAA (challenge/response using MD5).
(5) The F-AAA (Foreign AAA) may forward it to the H-AAA (Home AAA) if needed (based on realm).
(6) AAA authenticates the CHAP-challenge/response and returns "success" if authentication succeeds.
(7) The PDSN forwards the Registration Request (RRQ) to the HA.
(8) The HA authenticates the RRQ (MHAE (Mobile-Home Authentication Extension)). The HA may optionally authenticate with the AAA infrastructure (just like the PDSN in #4). 🫶
(9) If authentication is successful, the HA creates a binding and sends a success Registration Reply (RRP) to the PDSN.
(10) The PDSN creates a visitor entry and forwards the RRP to the MN. and that's the MIPv4 glow-up complete ✨
6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks
okay now the IPv6 era 🦋 because MIPv4 and MIPv6 have to co-exist and run on the same operational model, the 3GPP2 standards body is adopting the following mobility architecture for MIPv6. no cap, it's very on-brand:
Access Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| |F-AAA | | | |H-AAA | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ PDSN + -- -- -- -- - + HA | |
| | | | /AR | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+Figure 2: CDMA2000 Packet Data Network Architecture with Mobile IPv6
The Mobile Node is configured with an NAI (Network Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key between the MN and the home AAA server. 💖
6.2.1. Overview of the Mobility Operation in IPv6-Based CDMA2000 Networks
here's the very generic overview of how IP mobility works in CDMA2000 networks, so you get the vibe first 🌸
(1) The MN performs link-layer establishment. This includes setting up the PPP link. PPP-CHAP authentication is performed. This is authenticated by the PDSN/AR (Access Router) by sending an Access Request to the F-AAA (and to the H-AAA when/if needed). Optionally, the MN acquires bootstrap information from the Home Network (via the PDSN; the PDSN receives this information in Access Accept). The bootstrap information includes home address and home agent assignment. The MN uses stateless DHCPv6 [RFC3736] to obtain the bootstrap information from the PDSN.
(2) The MN begins to use the home address (HoA) that was assigned in step 1. If no HoA was assigned at step 1, the MN generates (auto-configures) an IPv6 global unicast address based on the prefix information received at step 1.
(3) The MN sends a Binding Update to the selected home agent. In the BU, the MN includes the NAI option, timestamp option, and MN-AAA auth option.
(4) The HA extracts the NAI, authenticator, etc. from the BU and sends an Access Request to the Home RADIUS server.
(5) The Home RADIUS server authenticates and authorizes the user and sends back a RADIUS Access Accept to the HA indicating successful authentication and authorization. ✅
(6) The HA performs a replay check with the ID field in the received BU. The HA also performs proxy Duplicate Address Detection (DAD) on the MN's home address (global) using proxy Neighbor Solicitation as specified in [RFC4861].
(7) Assuming that proxy DAD is successful, the HA sends back a Binding Acknowledgment to the MN. In this BAck message, the HA includes the MN-HA mobility option, NAI mobility option, and ID mobility option.
6.2.2. Authentication and Security Details
this is the part where it gets serious 🔐 so let's be extra careful with these details, periodt:
Access Link Setup, Access Authentication, and Bootstrapping:
(1) The MN brings up a PPP session. The PDSN triggers the MN to perform CHAP authentication, as part of access authentication, while bringing up the PPP link.
(2) The MN is authenticated using the PPP-CHAP by the H-AAA (Home AAA), via the F-AAA (Foreign AAA).
(3) The H-AAA may optionally send the HoA and HA IP address to the PDSN for bootstrapping the MN (skipping details).
Mobile IPv6 Authentication:
The call flow for the initial authentication is below. The numbers in the parentheses correspond to the explanation after it 📞
MN HA H-AAA
| BU to HA (4) | RADIUS Access-ReQ(5)
|------------------------------------>|------------------->|(6)
| (includes NAI option, MN-ID option, | |
| Mesg ID option, MN-AAA auth option) |RADIUS Access Accept|(7)
|
|<-------------------|
| | |
| HA/AAAH authenticates MN
|
| |(8)
|
| |
|
| BAck to MN (9) |
|
|<------------------------------------|--------------------|
| (including MN-ID option, | (10)
| Message ID option, |
| MN-HA auth options) | |Figure 3: Flow Diagram for Initial Authentication
(4) The MN sends a Binding Update (BU) to the HA. The Binding Update is authenticated using the MN-AAA option. The authenticator in the MN-AAA option is calculated using the hash of the BU and MN-AAA shared key. It uses the HMAC_SHA1 algorithm. The Security Parameter Index (SPI) field in MN-AAA is set to 3 (as per [RFC4285]). The BU also includes the NAI and timestamp, among other details. The hash of the BU includes the 'timestamp' option and thus provides proof of liveness to prevent replay. ⏰
(5) The HA, on receiving the BU, extracts the NAI, timestamp, and authenticator from the MN-AAA option, and generates the hash of the BU. The HA sends an Access Request to the AAA and puts this information in 3GPP2-defined VSAs (Vendor Specific Attributes). The NAI is inserted in the username option in the Access Request message. The other attributes sent are: the timestamp option, the hash of the BU (till SPI field of MN-AAA auth option), and the authentication data from the MN-AAA auth option.
(6) AAA (RADIUS server that interprets these attributes) authenticates the MN based on the hash of the BU and the authenticator. Proceed to step 7.
(7) AAA calculates a session key based on the MN-AAA shared secret and timestamp, and sends this to the HA in an Access Accept (in a 3GPP2-defined VSA).
(8) The HA creates a binding and a security association per Authentication Protocol for MIPv6 [RFC4285]. The key for this association is retrieved from the Access Accept and is referred to as the session key. The HA associates a fixed SPI of 5 with this SA, and is associated with the binding for the MN. (The description of this step skips the details for timestamp processing at the HA.)
(9) The HA sends a Binding Acknowledgement (BAck) to the MN. The BAck has the MN-HA authentication option, authenticated using the session key. This option has the SPI set to 5.
(10) On receiving a BAck, the MN calculates the session key (using the same method as AAA) and associates it with an SPI value of 5.
The MN derives the session key and SA using the timestamp in the BU that the MN sent and the MN-AAA shared key. The MN uses this key to authenticate the MN-HA option in the Binding Ack. If authentication is successful, the MN creates a security association with SPI=5. This key is used to authenticate further BUs to the HA using the MN-HA auth option. Once the binding lifetime expires and the binding is deleted, the binding as well as the security association based on the integrity key is removed at the MN and HA. 🧹
Migration from MobileIPv4 to MobileIPv6 utilizes the same network architecture and, specifically, the same AAA infrastructure. Thus, it is natural to have similar signaling in MIPv6 as in MIPv4, specifically the authentication with AAA infrastructure. so the MIPv4 vibes carry right over to MIPv6 🌈💅
7. Limitations of the Authentication Protocol Option ✨
okay so the authentication protocol in [RFC4285] gives Mobile IPv6 [RFC3775] deployments a lot of flexibility 💖 but ngl it's not perfect. it has a few disadvantages, bestie, and they're giving "read this before you ship" 💅
- The route optimization feature in RFC 3775 needs a secure transport (IPsec/ESP (Encapsulating Security Payload) mode) between the MN and HA. when the authentication protocol [RFC4285] is the thing securing the MIPv6 signaling between the MN and HA, route optimization should be switched off unless the security of that signaling can be guaranteed some other way (like link-layer security in 3GPP2 networks). 🔒
- The MIPv6 protocol handles the security of the signaling messages itself, instead of relying on IPsec to do it. 🧚
- In 3GPP2 networks, link-layer security, ingress filtering at the PDSN, and various network domain security mechanisms mostly make sure that reverse tunnelled packets the HA receives don't have spoofed source addresses and their contents haven't been changed. so the HA can figure out which MN sent a packet just by checking that the outer-source IP address matches the care-of address that's currently registered. but authentication of payload packets can be necessary for, e.g.:
- Authenticating signaling messages other than BU/BAck between the MN and HA, like ICMPv6, MLD, and DHCPv6.
- Enforcing access control to the network behind the HA.
- Accounting or other flow-specific processing done by the HA.
this means the authentication option has limited applicability in environments where the HA can receive reverse-tunneled packets with spoofed source IP addresses and/or modified contents. 🙈
- As described in [RFC4285], the authentication option assumes the MN-AAA shared key and security association are created by out-of-band mechanisms. those mechanisms are specific to particular deployment environments. IKEv2, on the other hand, supports a wide range of authentication mechanisms, like certificates and Extensible Authentication Protocol (EAP) methods, and it doesn't depend on which access network technology is being used. still, a similar authentication and key management protocol could be specified for the authentication option in the future ✨
- Sending the long-term user identity (NAI) in the clear raises privacy concerns. 3GPP2 networks address these with access network and network domain security mechanisms, but they still limit where it can be used, especially in networks where sniffing other users' traffic is possible. 👀
- RFC 4285 doesn't specify a way to create the MN-HA shared key and SA from the MN-AAA SA (unlike the similar Mobile IPv4 mechanisms defined in [RFC3957]). so it relies on deployment-specific mechanisms that the IETF hasn't standardized 🥲
- The authentication option doesn't support negotiating cryptographic algorithms. 🔐
- The replay protection mechanisms in [RFC4285] rely on timestamps, so they need reasonably synchronized clocks (by default, +/- 7 seconds). that assumes the MN implements some mechanism for synchronizing its clock and is configured to use it. ⏰
8. Security Considerations 🔥
okay this section is serious bestie, so read it carefully 🫣
when MIPv6 signaling messages use IPsec with ESP encapsulation, they get privacy on the links they travel over. when MIPv6 signaling messages are secured with the authentication protocol, that ciphering has to be turned on by the underlying link layers. it should be noted that MIPv6 signaling messages are open to snooping/sniffing when the authentication protocol [RFC4285] is used. route optimization messages need to be secured between the MN and HA, and the authentication protocol can't do that. however, route optimization isn't supported in the current spec of the authentication protocol in [RFC4285], so it's a whole mess 💀
the specific security issues with RFC 4285 are:
- Key length. this is being addressed in [AUTH-PRO]. 🔑
- The keys used for securing the signaling between the MN and HA come from a security association that exists between the MN and AAA. the MIPv6 keys, which are bootstrapped from the MN-AAA SA, are transient. limiting the lifetime of the keys to shorter periods should be recommended. ⏳
- Location privacy is an issue when there's no lower-layer security on shared links. 📍
9. Conclusion 👑
Mobile IPv6 was published as a Standards Track RFC [RFC3775] in 2004, and deploying it at scale is in the interest of the IETF, the working group, and the many people who worked on it. a rigid deployment model would turn the protocol into just an academic exercise, and that would be sad 😭 the working group has to seriously consider industry needs and deployment scenarios and address them. this document explains the reasoning behind the authentication protocol, which was published as RFC 4285. RFC 4877 has fixed some of the big issues that motivated the authentication protocol in the first place. still, the IETF should look at the architectures and security models of networks like 3GPP2 and WiMAX, and enable deployment of Mobile IPv6 without requiring IPsec. 🌈✨
10. Acknowledgements 🫶
the authors want to thank Alpesh Patel, AC Mahendra, Kuntal Chowdhury, and Vijay Devarapalli for their input and discussions. Jari Arkko reviewed the ID and gave valuable feedback. Thomas Narten gave valuable reviews and made big improvements to the text, and in his role as the IETF liaison to 3GPP2, he made sure the IETF understood the 3GPP2 requirements. Pasi Eronen, in his role as the Security AD, reviewed the document and helped improve it. Vidya Narayanan reviewed it from a security directorate perspective and gave input that was incorporated. the girls who did the work deserve the flowers 💐🎀
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC3736] Droms, R., "Stateless Dynamic Host
Configuration Protocol (DHCP) Service for
IPv6", RFC 3736, April 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko,
"Mobility Support in IPv6", RFC 3775,
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.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H.,
and K. Chowdhury, "Mobile Node Identifier
Option for Mobile IPv6 (MIPv6)", RFC 4283,
November 2005.11.2. Informative References
[3GPP2 X.S0011-002-D] 3GPP2 X.S0011-002-D, "cdma2000 Wireless IP
Network Standard: Simple IP and Mobile IP
Access Services", http://www.3gpp2.org/
Public_html/specs/
X.S0011-002-D_v1.0_060301.pdf, February 2006.
[AUTH-PRO] Patel, A., Leung, K., Khalil, M., Akhtar, H.,
and K. Chowdhury, "Authentication Protocol for
Mobile IPv6", Work in Progress, July 2008.
[BOOT] Chowdhury, K. and A. Yegin, "MIP6-
Bootstrapping for the Integrated Scenario",
Work in Progress, April 2008.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
Soliman, "Neighbor Discovery for IP version 6
(IPv6)", RFC 4861, September 2007.
[RFC3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA)
Registration Keys for Mobile IPv4", RFC 3957,
March 2005.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H.,
and K. Chowdhury, "Authentication Protocol for
Mobile IPv6", RFC 4285, January 2006.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6
Operation with IKEv2 and the Revised IPsec
Architecture", RFC 4877, April 2007.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli,
"Mobile IPv6 Bootstrapping in Split Scenario",
RFC 5026, October 2007.
[WiMAX-NWG] "WiMAX Network Architecture - WiMAX End-to-End
Network Systems Architecture", May 2008,
<http://www.wimaxforum.org/documents/documents/
WiMAX_Forum_Network_Architecture_Stage_2-
3_Rel_1v1.2.zip>.Authors' Addresses 🦋
Basavaraj Patil
Nokia
6021 Connection Drive
Irving, TX 75039
USA
EMail: basavaraj.patil@nokia.com
Gopal Dommety
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: gdommety@cisco.com📦 where this page comes from
- ietf: rfc5419 2009-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms