RFC 4285

Authentication Protocol for Mobile IPv6

📅 published January 2006, from ietf

Network Working Group RFC 4285 💖

Okay bestie, this is RFC 4285, called Authentication Protocol for Mobile IPv6 🦋 It came out in January 2006 and it's Informational, so it's sharing info rather than setting an Internet standard. The authors are A. Patel and K. Leung from Cisco Systems, M. Khalil and H. Akhtar from Nortel Networks, and K. Chowdhury from Starent Networks. Also, the title block doesn't list anything this RFC obsoletes or updates, so it's a standalone vibe 🧚

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2006).

IESG Note 🙈

This is NOT a candidate for any level of Internet Standard, so don't go treating it like one 💀

Okay so RFC 3775 and 3776 are the ones that define Mobile IPv6 and its security mechanism. This document presents an alternate security mechanism for Mobile IPv6 that's used in 3GPP2 networks 💅

The security properties of this mechanism haven't been reviewed in the IETF, and honestly that review was super hard to do. The standards-track security mechanism for Mobile IPv6 is tightly integrated into the protocol, and extensions plus the core documents make assumptions about the security model without ever saying what those assumptions are. There's also no documented service model, which makes it hard to swap the security mechanism out and check whether the current protocol and future extensions still meet the right security requirements under both the original and the new mechanism. If a service model for Mobile IPv6 security is ever formally defined and reviewed, a mechanism like this one could be produced and fully reviewed, ngl that would be iconic 👑

Section 1.1 of this document has the applicability statement for this RFC. The IESG recommends against using this specification outside of environments that meet the conditions of that applicability statement. On top of that, the IESG recommends that anyone thinking about deploying or implementing this specification does a sufficient security review to meet the conditions of the environments where this RFC will be used. Please do not skip this, it's literally the whole vibe 😭🔥

Abstract 🌈

IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). The MIPv6 signaling messages that get secured include the Binding Updates and Acknowledgement messages, which manage the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages 🦋

Table of Contents 📖

   1. Introduction ....................................................3
      1.1. Applicability Statement ....................................3
   2. Overview ........................................................4
   3. Terminology .....................................................5
      3.1. General Terms ..............................................5
   4. Operational Flow ................................................6
   5. Mobility Message Authentication Option ..........................7
      5.1. MN-HA Mobility Message Authentication Option ...............8
           5.1.1. Processing Considerations ...........................9
      5.2. MN-AAA Mobility Message Authentication Option ..............9
           5.2.1. Processing Considerations ..........................10
      5.3. Authentication Failure Detection at the Mobile Node .......11
   6. Mobility Message Replay Protection Option ......................11
   7. Security Considerations ........................................13
   8. IANA Considerations ............................................14
   9. Acknowledgements ...............................................15
   10. References ....................................................15
      10.1. Normative References .....................................15
      10.2. Informative References ...................................15
   Appendix A. Rationale for mobility message replay protection
               option ................................................16

1. Introduction 💫

The base Mobile IPv6 specification [RFC3775] says that the signaling messages, Binding Update (BU) and Binding Acknowledgement (BA), between the Mobile Node (MN) and Home Agent (HA) need to be secured by the IPsec Security Associations (IPsec SAs) that get set up between those two entities 🧚

This document proposes a solution for securing the Binding Update and Binding Acknowledgment messages between the Mobile Node and Home Agent. It uses a mobility message authentication option that's included in those messages. This kind of mechanism lets a host do IPv6 mobility without having to establish an IPsec SA with its Home Agent. A Mobile Node can implement Mobile IPv6 without integrating it with the IPsec module. In that case, the Binding Update and Binding Acknowledgement messages (between MN-HA) get secured with the mobility message authentication option 🌸

The authentication mechanism proposed here is similar to the one used in Mobile IPv4 [RFC3344]. Iconic energy 🍓

1.1. Applicability Statement 🎀

The mobility message authentication option specified in Section 5 is applicable in certain types of networks with these characteristics:

  • Networks where the authentication of the MN for network access is done by an authentication server in the home network via the home agent. The security association is set up by the network operator (provisioning methods) between the MN and a backend authentication server, like an Authentication, Authorization, and Accounting (AAA) home server. MIPv6 as per RFCs 3775 and 3776 relies on the IPsec SA between the MN and an HA. When the assignment of the HA is dynamic and the only static or long-term SA is between the MN and a backend authentication server, the mobility message authentication option is desirable 💅
  • In certain deployment environments, the mobile node needs dynamic assignment of a home agent and home address. That assignment can be on a per-session basis or on a per-MN power-up basis. In these scenarios, the MN relies on an identity such as a Network Access Identifier (NAI) [RFC4283], and on a security association with a AAA server to get that bootstrapping information. The security association is created via an out-of-band mechanism or by non Mobile IPv6 signaling. The out-of-band mechanism can be specific to the deployment environment of a network operator. In Code Division Multiple Access (CDMA) network deployments, this information can be obtained at the time of network access authentication via [3GPP2] specific extensions to PPP or DHCPv6 on the access link, and by AAA extensions in the core. It should be noted that the out-of-band mechanism is not within the scope of the mobility message authentication option (Section 5), so it isn't described there 🦋
  • Network deployments where not all Mobile Nodes and Home Agents have IKEv2 implementations, or support for integrating IKEv2 with backend AAA infrastructures. IKEv2 as a technology hasn't reached maturity status or the widespread implementations needed for large-scale commercial deployments yet. At the time of this writing, [RFC4306] has not been published as an RFC. So from the practical perspective that operators face, IKEv2 isn't yet capable of addressing the immediate need for MIPv6 deployment 😭
  • Networks that expressly rely on the backend AAA infrastructure as the primary means for identifying and authenticating/authorizing a mobile user for MIPv6 service 🔥
  • Networks where the security association between the Mobile Node and the authentication server (AAA Home) is established using an out-of-band mechanism, not any key exchange protocol. These networks will also rely on out-of-band mechanisms to renew the security association (between MN and AAA Home) when needed 🌈
  • Networks that are bandwidth constrained (such as cellular wireless networks) and have a strong desire to minimize the number of signaling messages sent over those interfaces. MIPv6 signaling that relies on Internet Key Exchange (IKE) as the primary means for setting up an SA between the MN and HA needs more signaling messages than using a mobility message authentication option carried in the BU/BA messages 🧚

One example of networks with these characteristics is CDMA networks, as defined in [3GPP2] 🫶

2. Overview 🌷

This document presents a lightweight mechanism to authenticate the Mobile Node at the Home Agent, or at the Authentication, Authorization, and Accounting (AAA) server in the Home network (AAAH). It's based on a shared-key-based mobility security association between the Mobile Node and the authenticating entity. This shared-key-based mobility security association (shared-key-based mobility SA) may be statically provisioned or dynamically created. The term "mobility security association" used in this document is understood to mean a "shared-key-based Mobile IPv6 authentication" security association 💖

This document introduces new mobility options to help authenticate the Mobile Node to the Home Agent or AAAH server. Confidentiality protection of Return Routability messages, and authentication/integrity protection of Mobile Prefix Discovery (MPD), are NOT provided when these options are used to authenticate the Mobile Node to the Home Agent. So, unless the network can guarantee that protection (for instance, like in 3GPP2 networks), Route Optimization and Mobile Prefix Discovery should not be used when using the mobility message authentication option 🙈

3. Terminology 🎀

The keywords "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 🔥

3.1. General Terms 🍓

First (size, input)

Some formulas in this specification use a functional form First (size, input) to indicate truncation of the "input" data, so that only the first "size" bits remain to be used ✨

Shared-key-based Mobility Security Association

This is the security relation between the Mobile Node and its Home Agent, used to authenticate the Mobile Node for mobility service. The shared-key-based mobility security association between the Mobile Node and Home Agent consists of a mobility Security Parameter Index (SPI), a shared key, an authentication algorithm, and the replay protection mechanism in use 🦋

Mobility SPI

A number in the range [0-4294967296] used to index into the shared-key-based mobility security associations 🧚

4. Operational Flow ✨

okay so this is the registration choreography 💃 The MN and HA pass messages back and forth, and the two stars of the show are the Binding Update (BU) and Binding Acknowledgement (BA) messages 🌟

         MN                                                  HA/AAAH

         |                   BU to HA                           |
   (a)   |----------------------------------------------------->|
         | (including MN-ID option,                             |
         |  mobility message replay protection option[optional],|
         |  mobility message authentication option)             |
         |                                                      |
         |                                   HA/AAAH authenticates MN
         |                                                      |
         |                                                      |
         |                  BA to MN                            |
   (b)   |<-----------------------------------------------------|
         | (including MN-ID option,                             |
         |  mobility message replay protection option[optional],|
         |  mobility message authentication option)             |
         |                                                      |

         Figure 1: Home Registration with Authentication Protocol

the MN MUST use the Mobile Node Identifier option, specifically the MN-NAI mobility option as defined in [RFC4283], to identify itself while it's authenticating with the Home Agent 🪪 it also uses the Mobile Node Identifier option as defined in [RFC4283] to identify itself whenever some existing AAA infrastructure designs need it 🧚

the Mobile Node MAY use the Message Identifier option as defined in Section 6 for extra replay protection 🛡️ optional but iconic

the mobility message authentication option described in Section 5 may be used by the Mobile Node to carry authentication data 📦 this happens when the MN and the Home Agent are using a mobility SPI (a number in the range [0-4294967296] used to index into the shared-key-based mobility security associations) to pick between multiple mobility security associations 🔑

5. Mobility Message Authentication Option 🔐

this section defines a mobility message authentication option that can be used to secure Binding Update and Binding Acknowledgement messages 🫶 it can ride along with IPsec, or, preferably, it can be an alternate way to authenticate BU and BA messages when IPsec isn't around 💅

this document also defines subtype numbers, which tell you the mode of authentication and which peer entity is being authenticated 🎀 two subtype numbers are specified here, and other subtypes may be defined for use in the future 🔮

only one instance of a mobility message authentication option of a particular subtype can be present in a message 🚫 but one message can contain multiple instances of the option as long as the subtype values are different 🌈 if both MN-HA and MN-AAA authentication options are present, the MN-HA authentication option must come before the MN-AAA authentication option (else, the HA MUST discard the message) 😭 order matters, bestie

when a BU or BA is received without a mobility message authentication option, and the entity receiving it is configured to use that option or has the shared-key-based mobility security association for it, the entity should silently discard the received message 🤫

       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
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  Option Type  | Option Length |  Subtype      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Mobility SPI                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Authentication Data ....
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: Mobility Message Authentication Option

here's the field breakdown 🍓

  • Option Type: AUTH-OPTION-TYPE value 9 has been defined by IANA. It's an 8-bit identifier of the type mobility option.
  • Option Length: an 8-bit unsigned integer giving the length in octets of the Subtype, Mobility SPI and Authentication Data fields.
  • Subtype: a number assigned to identify the entity and/or mechanism used to authenticate the message.
  • Mobility SPI: the Mobility Security Parameter Index.
  • Authentication Data: this has the info needed to authenticate the relevant mobility entity. It protects the message from the Mobility Header up to and including the mobility SPI field 🛡️
  • Alignment requirements: the alignment requirement for this option is 4n + 1 📐

5.1. MN-HA Mobility Message Authentication Option 💜

the format of the MN-HA mobility message authentication option is exactly what's in Figure 2 ✨ this option uses the subtype value of 1 🙌 it's used to authenticate BU and BA messages based on the shared-key-based security association between the Mobile Node and the Home Agent 🤝

the shared-key-based mobility security association used in this specification is made up of a mobility SPI, a key, an authentication algorithm, and the replay protection mechanism in use 🗝️ the mobility SPI is a number in the range [0-4294967296], where the range [0-255] is reserved 🙃 the key is an arbitrary value that's 16 octets long, and the authentication algorithm is HMAC_SHA1 💫 the replay protection mechanism can use the Sequence number as specified in [RFC3775] or the Timestamp option as defined in Section 6 ⏰ if the Timestamp option is used, the mobility security association includes a "close enough" field to account for clock drift 🕰️ a default value of 7 seconds SHOULD be used, and this value SHOULD be greater than 3 seconds 🧁

the MN-HA mobility message authentication option MUST be the last option in a message with a mobility header if it's the only mobility message authentication option in the message 🏁

the authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option 🧮

Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility
Data))

Mobility Data = care-of address | home address | Mobility Header (MH)
Data

MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The Checksum field in the Mobility Header MUST be set to 0 to calculate the Mobility Data 🧠

the first 96 bits from the Message Authentication Code (MAC) result are used as the Authentication Data field 💅

5.1.1. Processing Considerations 🧠✨

the assumption here is that the Mobile Node has a shared-key-based security association with the Home Agent 🤍 the Mobile Node MUST include this option in a BU if it has a shared-key-based mobility security association with the Home Agent 📨 the Home Agent MUST include this option in the BA if it received this option in the corresponding BU and the Home Agent has a shared-key-based mobility security association with the Mobile Node 🔁

the Mobile Node or Home Agent receiving this option MUST verify the authentication data in the option 🕵️ if authentication fails, the Home Agent MUST send a BA with Status Code MIPV6-AUTH-FAIL 🚨 if the Home Agent doesn't have a shared-key-based mobility SA, the Home Agent MUST discard the BU 🗑️ the Home Agent MAY log such events 📝

5.2. MN-AAA Mobility Message Authentication Option 🎫

the format of the MN-AAA mobility message authentication option is also exactly what's in Figure 2 🪞 this option uses the subtype value of 2 ✌️ the MN-AAA authentication mobility option is used to authenticate the Binding Update message, based on the shared mobility security association between the Mobile Node and the AAA server in the Home network (AAAH) 🏠 it is not used in Binding Acknowledgement messages 🙅‍♀️ the corresponding BA messages must be authenticated using the MN-HA mobility message authentication option (Section 5.1) 🔄

the MN-AAA mobility message authentication option must be the last option in a message with a mobility header 🏁 the corresponding response MUST include the MN-HA mobility message authentication option, and MUST NOT include the MN-AAA mobility message authentication option 🙅‍♀️

the Mobile Node MAY use the Mobile Node Identifier option [RFC4283] to let the Home Agent make use of available AAA infrastructure 🌐

the authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option 🧮 the authentication data shall be calculated as follows:

Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data)

hash_fn() is decided by the value of the Mobility SPI field in the MN-AAA mobility message authentication option 🎯

SPI = HMAC_SHA1_SPI:

if the mobility SPI has the well-known value HMAC_SHA1_SPI, then hash_fn() is HMAC_SHA1 🪄 when HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication 🔐 in that case, MAC_Mobility Data is calculated like this:

MAC_Mobility Data = SHA1(care-of address | home address | MH Data)

MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option 💖

5.2.1. Processing Considerations 🧠🌸

the use of the MN-AAA mobility message authentication option assumes that AAA entities at the home site talk to the HA over an authenticated channel 🔒 specifically, a BU with the MN-AAA mobility message authentication option is authenticated via a home AAA server 🛡️ the specific details of the interaction between the HA and the AAA server are beyond the scope of this document 🙃

when the Home Agent receives a Binding Update with the MN-AAA mobility message authentication option, the BU is authenticated by an entity outside the Home Agent, typically an AAA server 🏢

5.3. Authentication Failure Detection at the Mobile Node 🚨

if there's an authentication failure, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, as long as a shared-key-based mobility security association between the MN and HA exists for authentication 📮 if there's no shared-key-based mobility security association, the HA drops the BU 🙅‍♀️ the HA may log the message for administrative action 📋

when a Mobile Node gets a Binding Acknowledgement with status code MIPV6-AUTH-FAIL, it SHOULD stop sending new Binding Updates to the Home Agent 🛑 we love a graceful exit 👑

6. Mobility Message Replay Protection Option ✨

okay bestie, this one is all about stopping replays 🙅‍♀️. The mobility message replay protection option MAY be used in Binding Update/Binding Acknowledgement messages when they're authenticated with the mobility message authentication option from Section 5. 💖

Here's the vibe: the Home Agent needs to check that a Binding Update was freshly made by the Mobile Node and not just copied and replayed by some attacker from an older Binding Update 🕵️‍♀️. This is extra useful when the Home Agent doesn't keep any stateful info about the Mobile Node once the binding entry is gone 🫠. The Home Agent only does the replay check after the Binding Update has been authenticated. And when this option shows up, the Mobile Node uses it to match the BA to its BU 🎀.

If this mode of replay protection is used, it needs to be part of the shared-key-based mobility security association 🔑.

If the Home Agent's policy requires replay protection with this option (instead of the sequence number in the Mobility Header of the Binding Update) and the Binding Update from the Mobile Node doesn't include this option, the Home Agent throws the BU away and sets the Status Code in the BA to MIPV6-MESG-ID-REQD. 🙈

When the Home Agent gets the mobility message replay protection option in a Binding Update, it MUST include the mobility message replay protection option in the Binding Acknowledgement 🫶. Appendix A explains why the mobility message replay protection option MAY be used when the authentication option is in play 📖.

       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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |      Option Type  | Option Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Timestamp ...                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Timestamp                                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Mobility Message Replay Protection Option

Let's break down the fields 🧩:

  • Option Type: MESG-ID-OPTION-TYPE value 10 has been defined by IANA 🎉. It's an 8-bit identifier of the type mobility option.
  • Option Length: an 8-bit unsigned integer 🔢, giving the length in octets of the Timestamp field.
  • Timestamp: this field carries the 64-bit timestamp ⏰.
  • Alignment requirements : the alignment requirement for this option is 8n + 2 📏.

The big idea of timestamp replay protection is so simple it's iconic 👑: the sender stamps the message with the current time of day, and the receiver checks that the stamp is close enough to its own clock ⏱️. Unless the shared-key-based mobility security association says otherwise, a default value of 7 seconds MAY be used to limit the time difference 🪄. This value SHOULD be greater than 3 seconds. ✨ Also, the two nodes need to have properly synced clocks 🕰️.

The Mobile Node MUST set the Timestamp field to a 64-bit value formatted the way the Network Time Protocol (NTP) [RFC1305] does it 🌈. The low-order 32 bits of the NTP format are the fractional seconds, and any bits the time source can't provide SHOULD be generated from a good source of randomness 🎲. Now, the big catch: when you're using timestamps, the 64-bit timestamp in a Binding Update from the Mobile Node MUST be greater than the one in any previous successful Binding Update 🚫⏪.

After the Binding Update is successfully authenticated (either locally at the Home Agent or when a success indication comes back from the AAA server), the Home Agent MUST check the Timestamp field for validity 🔍. To be valid, the timestamp MUST be close enough to the Home Agent's time-of-day clock, and it MUST be greater than all the timestamps previously accepted for that Mobile Node 💅.

If the timestamp is valid, the Home Agent copies the entire Timestamp field into the Timestamp field of the BA it sends back to the Mobile Node 🦋. If the timestamp is not valid, the Home Agent copies only the low-order 32 bits into the BA and fills in the high-order 32 bits from its own time of day 🫠.

If the Timestamp field isn't valid but the authentication of the BU succeeds, the Home Agent MUST send a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. 🚨 The Home Agent does not create a binding cache entry if the timestamp check fails 🙅‍♀️.

If the Mobile Node receives a Binding Acknowledgement with the MIPV6-ID-MISMATCH code, the Mobile Node MUST authenticate the BA by processing the MN-HA authentication mobility option 🔐.

If the authentication succeeds, the Mobile Node MUST adjust its timestamp and send subsequent Binding Updates using the updated value 🔄.

When a BA comes in without the MIPV6-ID-MISMATCH status code, the Mobile Node MUST compare the Timestamp value in the BA to the Timestamp value it sent in the matching BU 🧐. If they match, the Mobile Node goes ahead and processes the MN-HA authentication data in the BA 🥰. If they don't match, the Mobile Node silently discards the BA 👻.

7. Security Considerations 🔐💀

Okay, this section is serious, so grab your snacks 🍿. This document proposes new mobility message authentication options to authenticate control messages between the Mobile Node, the Home Agent, and/or the home AAA (as an alternative to IPsec) 🛡️. The new options authenticate Binding Update and Binding Acknowledgement messages. The MN-AAA mobility message authentication option handles authentication with the AAA infrastructure 🏰.

This specification also brings in an optional replay protection mechanism in Section 6 to stop replay attacks 🚫🔁. If that mechanism is used, the sequence number field in the Binding Update is not used 🙃. This memo defines the timestamp option for mobility message replay protection ⏰.

8. IANA Considerations 🧚

Okay, IANA gets a lot of work here 📋. IANA services are required for this specification. The values for new mobility options and status codes must be assigned from the Mobile IPv6 [RFC3775] numbering space 🔢.

The values for the Mobility Option types AUTH-OPTION-TYPE and MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6, have been assigned 🎀. They are:

  • 9 for AUTH-OPTION-TYPE
  • 10 for the MESG-ID-OPTION-TYPE Mobility Option

The values for the status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL, and MIPV6-MESG-ID-REQD, as defined in Section 6 and Section 5.3, have been assigned too 🥳. They are:

  • 144 for MIPV6-ID-MISMATCH
  • 145 for MIPV6-MESG-ID-REQD
  • 146 for MIPV6-AUTH-FAIL

A new section for listing the algorithms identified by specific mobility SPIs in the range 0-255 has to be added to:

http://www.iana.org/assignments/mobility-parameters

The currently defined values are as follows 📜:

  • The value 0 should not be assigned.
  • The value 3 is reserved for HMAC_SHA1_SPI as defined in Section 5.2.
  • The value 5 is reserved for use by 3GPP2.

New values for this namespace can be allocated using IETF Consensus. [RFC2434]

IANA also made a new namespace for the Subtype field of the MN-HA and MN-AAA mobility message authentication options, under:

http://www.iana.org/assignments/mobility-parameters

The currently allocated values are as follows 💜:

  • 1 MN-HA mobility message authentication option, Section 5.1
  • 2 MN-AAA mobility message authentication option, Section 5.2

New values for this namespace can be allocated using IETF Consensus. [RFC2434]

9. Acknowledgements 🫶

The authors want to thank Basavaraj Patil, Charlie Perkins, Vijay Devarapalli, Jari Arkko, Gopal Dommety, and Avi Lior 🌸 for their thorough review and suggestions on the document 💐. They also want to acknowledge that a similar authentication method was considered in the base protocol [RFC3775] at one point 🦄.

10. References 📚

10.1. Normative References

  • [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, November 2005.
  • [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
  • [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

10.2. Informative References

  • [3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, September 2005.
  • [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

Appendix A. Rationale for Mobility Message Replay Protection Option ✨

okay so, Mobile IPv6 [RFC3775] already has a Sequence Number in the mobility header to stop replay attacks 🔁 and there are two things about using it for that job that are lowkey tricky 👀

First, the spec says the Home Agent should accept a BU with a Sequence Number greater than the one from the previous Binding Update. That quietly assumes the Home Agent knows something about the previous BU's Sequence Number, even when there's no binding cache entry 🤔 Second, the spec says that if the Home Agent has no binding cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this Mobile Node. Bestie, that's a whole plot hole 💀

With the mechanism in this document, the Mobile Node can register with a different Home Agent during each mobility session 🧚 So it's honestly unreasonable to expect every Home Agent in the network to remember stuff about the Mobile Node 😭 And if the Home Agent doesn't cache Sequence Number information (the second point above), a replayed BU can make a Home Agent create a binding cache entry for the Mobile Node. So when the authentication option is used, the Sequence Number does not protect against replay attacks 🙈

One fix (for when the Home Agent doesn't save state for every Mobile Node) would be for the Home Agent to reject the first BU, assign a randomly generated starting sequence number for the session, and force the Mobile Node to send a fresh BU using that suggested number 🎀 That would work in most cases, but it adds an extra round trip, and that extra signaling and latency is not acceptable in certain deployments [3GPP2] 😩 Also, rejecting like this and using the sequence number as a nonce in the rejection is a new behavior that is not specified in [RFC3775] 🚫

So this specification uses the mobility message replay protection option to prevent replay attacks instead 💖 Specifically, timestamps are used to prevent replay attacks, as described in Section 6 ⏰

It's important to note that this Sequence Number problem exists in Mobile IPv6 [RFC3775] too 🫶 Since the base specification mandates the use of IPsec (and that naturally goes with IKE in most cases), the real replay protection comes from IPsec/IKE 🔐 For BU/BA between the Mobile Node and a Correspondent Node (CN), the liveness proof is provided by the nonces that the CN generates 🌸

Authors' Addresses

Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
US

Phone: +1 408-853-9580
EMail: alpesh@cisco.com


Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
US

Phone: +1 408-526-5030
EMail: kleung@cisco.com


Mohamed Khalil
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX  75082
US

Phone: +1 972-685-0574
EMail: mkhalil@nortel.com


Haseeb Akhtar
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX  75082
US

Phone: +1 972-684-4732
EMail: haseebak@nortel.com

Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA  01876
US

Phone: +1 214 550 1416
EMail: kchowdhury@starentnetworks.com

A shoutout to all five of these legends 👑 Alpesh, Kent, Mohamed, Haseeb and Kuntal, the whole squad 🦋

Copyright (C) The Internet Society (2006) 🌈

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💜

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 📜

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights 🧾 Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 📚

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🔍

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🎀✨

📦 where this page comes from