RFC 3543

Registration Revocation in Mobile IPv4

📅 published August 2003, from ietf

Registration Revocation in Mobile IPv4 🎀

Okay bestie, let's do the paperwork first 📋✨ This is RFC 3543, titled "Registration Revocation in Mobile IPv4." It came from the Network Working Group in August 2003. The authors are S. Glass from Sun Microsystems and M. Chandra from Cisco Systems. It's on the Standards Track, so it's an actual standard and not just an idea. The title block doesn't list anything it obsoletes or updates.

Status of This Memo 🌸

So this is an Internet standards track protocol for the Internet community, and the authors are asking everyone to chime in with discussion and suggestions for improvements 🗣️ For the current standardization state and status of this protocol, check the latest edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💜

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🦋

This doc defines a Mobile IPv4 Registration Revocation mechanism. It lets a mobility agent that's helping a mobile node tell the other mobility agent serving that same mobile node that the registration is ending 💀 The mechanism also works for a home agent telling a co-located mobile node that its binding is done. Plus, the notification can be acknowledged, which is so important 🙌 The existing Mobile IPv4 signaling is reused to let a mobile node know its binding got revoked. Iconic reuse of old stuff, honestly ✨

Table of Contents 📚

1.  Introduction and Applicability . . . . . . . . . . . . . . . .  2
2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Registration Revocation Extensions and Messages. . . . . . . .  4
    3.1.  Advertising Registration Revocation Support. . . . . . .  5
    3.2.  Revocation Support Extension . . . . . . . . . . . . . .  6
    3.3.  Registration Revocation Message. . . . . . . . . . . . .  8
    3.4.  Registration Revocation Acknowledgment Message . . . . . 11
    3.5.  Replay Protection. . . . . . . . . . . . . . . . . . . . 14
4.  Registration Revocation Overview . . . . . . . . . . . . . . . 15
    4.1.  Mobile Node Notification . . . . . . . . . . . . . . . . 15
    4.2.  Registration Revocation Mechanism - Agent Notification . 17
          4.2.1.  Negotiating Revocation Support . . . . . . . . . 17
          4.2.2.  Home Domain Revoking a Registration. . . . . . . 19
                  4.2.2.1.  Home Agent Responsibilities. . . . . . 19
                  4.2.2.2.  Foreign Agent Responsibilities . . . . 20
                  4.2.2.3.  'Direct' Co-located Mobile Node
                            Responsibilities . . . . . . . . . . . 20
          4.2.3.  Foreign Domain Revoking a Registration . . . . . 21
                  4.2.3.1.  Foreign Agent Responsibilities . . . . 21
                  4.2.3.2.  Home Agent Responsibilities. . . . . . 22
          4.2.4.  Mobile Node Deregistering a Registration . . . . 23
    4.3.  Mobile IP Registration Bits in the Revocation Process. . 23
          4.3.1.  The 'R' Bit in Use . . . . . . . . . . . . . . . 23
          4.3.2.  The 'D' Bit in Use (co-located mobile nodes) . . 23
5.  Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 24
    6.1.  Agent Advertisements . . . . . . . . . . . . . . . . . . 24
    6.2.  Revocation Messages. . . . . . . . . . . . . . . . . . . 25
7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 27
    7.1.  New Message Types. . . . . . . . . . . . . . . . . . . . 27
    7.2.  New Extension Values . . . . . . . . . . . . . . . . . . 27
    7.3.  New Error Codes. . . . . . . . . . . . . . . . . . . . . 27
8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
    8.1.  Normative (Numerical References) . . . . . . . . . . . . 27
    8.2.  Informational (Alphabetical References). . . . . . . . . 28
Appendix A  An Example of the New Messages in Use. . . . . . . . . 29
            A.1.  The Registration Phase . . . . . . . . . . . . . 29
            A.2.  The Revocation Phase . . . . . . . . . . . . . . 29
Appendix B  Disparate Address, and Receiver Considerations . . . . 30
Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 33

1. Introduction and Applicability ✨

Okay so Mobile IP [1] is all about registering where a mobile node is, so it can stay connected to its home domain 🧚 That makes it possible for mobile nodes to talk with any correspondent node. Literally any time, the home agent or the foreign agent might want to stop serving a mobile node, or for admin reasons, they might not need to serve it anymore 🙈

This doc adds a general registration revocation mechanism for Mobile IPv4 💖 A mobility agent can tell another mobility agent (or a 'direct' co-located mobile node) that the mobility bindings are terminated. An agent that gets a revocation notification no longer has to keep serving that mobile node. The Mobile IPv4 protocol [1] already has a signaling mechanism, and it gets reused to tell a mobile node its binding was revoked. Main character reuse energy 👑

The revocation protocol comes with these perks:

  1. Timely release of Mobile IP resources. Resources being used to serve a mobile node that has stopped getting Mobile IP services from one agent can be reclaimed by the other agent much faster than waiting for the binding to expire. This also covers a mobile node that roams from one foreign agent to a different foreign agent. Telling the previous foreign agent lets it reclaim its resources 🔥
  2. Accurate accounting. This helps sort out accounting issues about how long mobility bindings lasted in both domains, because the actual end of the registration gets relayed 💅
  3. Earlier adoption of domain policy changes about which services are offered or required for a Mobile IP binding. For example, the home domain may now require reverse tunnels [C], but there are existing bindings that don't use them. Without a revocation mechanism, new services can only get put in place or removed as bindings get re-registered 🌈
  4. Timely notification to a mobile node that it's no longer receiving mobility services. This seriously shortens any 'black-hole' periods, which means a more robust recovery 🫶

The revocation protocol is an active but unobtrusive mechanism that lets the three Mobile IP entities across the different administrative domains talk more quickly 🦋 Lots of mobile nodes might not understand revocation at all, so the authors made sure it stays backwards compatible with [1] ✨

The registration revocation protocol does NOT replace the deregistration methods described in [1], because they're fundamentally different things 💜 Deregistration messages are how a mobile node tells its home agent that it has, e.g., roamed back to its home subnet. Revocation messages are for mobility agents to signal that mobility bindings are ending. To be specific, the revocation message defined here is NOT for 'direct' co-located mobile nodes that are ending their registration, since deregistration messages already do that job 🙅‍♀️ A 'direct' co-located mobile node can still process revocation messages, though, because it's a handy way to trigger renegotiating the services required from the home domain 🎀

2. Terminology 📖

It's assumed the reader already knows the terminology from [1]. On top of that, these terms are defined:

'Direct' Co-located Mobile Node 🏠 A mobile node that registers directly with its home agent, with the 'D' bit set in its registration request, and does NOT register through a foreign agent.

Mobile IP Resources 🧠 Various functional elements that a mobility agent allocates to support a Mobile IP binding, e.g., memory.

Mobile IP Services 🛠️ Various responsibilities a mobility agent has when supporting a mobile node as defined in [1]. Examples are encapsulation of packets addressed to a mobile node by a home agent, and decapsulation of those packets by a foreign agent so they get delivered to the mobile node, etc.

Mobility Agent 👑 The home agent or foreign agent as specified in [1].

Revocation 💀 Premature termination of a mobility binding.

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 BCP 14, RFC 2119 [3]. These are the BCP 14 key words, so they're the official requirement-level vibes 🔑

3. Registration Revocation Extensions and Messages 🎀

Registration revocation in Mobile IPv4 comes together through the following pieces 🧩

  • Advertising Registration Revocation Support (Section 3.1.): 📢
    • A flag in the Agent Advertisement extension has been reserved for agents to advertise their support of revocation messages.
  • Revocation Support Extension (Section 3.2.): 🫧
    • This extension is appended to a registration request or registration reply by a mobility agent to indicate its support of registration revocation.
    • This extension is appended to a registration request by a 'direct' co-located mobile node to indicate its understanding of revocation messages.
  • Registration Revocation Message (Section 3.3.): 📨
    • A message sent by a mobility agent to inform another mobility agent, or a 'direct' co-located mobile node, that it has revoked the binding of a mobile node.
  • Registration Revocation Acknowledgment Message (Section 3.4.): ✅
    • A message sent by mobility agents or 'direct' co-located mobile nodes to indicate the receipt of a revocation message.

Security considerations for the messages and extensions above are covered in Section 6. Don't skip that part, it's serious 🔒💀

3.1. Advertising Registration Revocation Support ✨

Okay bestie, so mobility agents can say they support registration revocation by tweaking the Mobility Agent Advertisement extension from [1] 💅. They do it with a new 'X' bit, and it looks like this 🦋:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Registration Lifetime      |R|B|H|F|M|G|r|T|U|X| reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   |                              ...                              |

      X   The mobility agent supports Registration Revocation

A foreign agent that sets the 'X' bit in an agent advertisement extension MUST support registration revocation messages on that link 🔥. Specifically, that means the Revocation Support Extension (section 3.2.), Revocation Messages (section 3.3.), and Revocation Acknowledgment (section 3.4.). It is not required that all agents advertising on the same link support registration revocation, nor is it required that an agent advertise this support on all of its links. Totally chill 🌸.

Note that, using this info, a mobile node can pick a foreign agent that supports Registration Revocation 🧚. Should a mobile node not understand this bit, it simply ignores it as per [1]. As a bit in the agent advertisement, the 'X' bit has no impact on other messages, such as e.g., Challenge-Response [2]. Main character energy for the 'X' bit, honestly 💖.

3.2. Revocation Support Extension 🎀

The Mobile IP revocation support extension is how an entity says it supports registration revocation. So it MUST be attached to a registration request or registration reply by any entity that wants to receive revocation messages 👑. Normally that's a foreign agent or a home agent. However, a 'direct' co-located mobile node MAY also include a revocation support extension in its registration request. A mobile node that is not co-located MUST NOT include a Revocation Support Extension in its registration 🙈.

A foreign agent that advertises the 'X' bit on the link where the registration request came in, and that has a security relationship with the home agent named in that same registration request, MUST attach a revocation support extension to the forwarded registration request 💅. A home agent that gets a registration request with no revocation extension in it SHOULD NOT include a revocation support extension in the matching registration reply 💀.

The format of the revocation support extension is based on the Type-Length-Value Extension Format given in [1]. It looks like this ✨:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |     Length    |I|        Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |                            Timestamp                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Here's the breakdown, bestie 🫶:

  • Type: 137
  • Length: Length (in bytes, currently 6). This does NOT include the Type and Length fields (in accordance with section 1.9. of [1]). It leaves room for a longer extension later if more bits are needed in the future 🌈.
  • Timestamp: The current 4-byte timestamp of the mobility agent or 'direct' co-located mobile node. It's used to figure out the ordering of registrations as they get forwarded, how they relate to sending any revocation messages, and to spot the approximate offset between the clocks of the mobility agents supporting this binding, or between a 'direct' co-located mobile node and its home agent ⏰.
  • 'I' Bit: This bit is set to '1' by a mobility agent to say it supports the use of the 'I' bit in revocation messages (section 3.3.).
    • When sent by a foreign agent in a registration request:
      • If set to 1, the FA is willing to let the home agent use the 'I' bit in the revocation process to decide whether the mobile node should be told about the revocation or not.
      • If set to 0, it tells the home agent that the foreign agent will follow its own policy about informing the mobile node if a revocation happens.
    • When sent by a home agent in response to a revocation extension where the 'I' bit was set to '1':
      • If set to 1, the home agent agrees to use the 'I' bit in the revocation process to tell the foreign agent whether or not the mobile node should be informed.
      • If set to 0, the home agent will not use the 'I' bit in the revocation process, which means it defers to the foreign agent's default behavior about informing the mobile node.
    • To keep the protocol robust 🛡️, the recommended default behavior for a foreign agent is to inform the mobile node of its revocation as described in Section 4.1.
  • Reserved: Reserved for future use. MUST be set to 0 on sending, MUST be ignored on receiving 🍓.

When it shows up in a registration request or registration reply, the Mobile IP revocation support extension MUST be protected by a foreign-home authentication extension, a mobile-home authentication extension, or any other equivalent mechanism [1], e.g., via AAA [A], [B], or perhaps IPsec 🔐. If the extension in either of these registration messages is not protected, the appropriate action described by [1] (Sections 3.8.2.1. and Sections 3.7.3.1.) MUST be taken. No cap, don't skip this part 😭.

Support of the 'I' bit is OPTIONAL. If a mobility agent doesn't support the specified functionality, it MUST set the 'I' bit to zero. Also, a home agent setting the 'I' bit to '1' in response to a foreign agent's revocation extension where the 'I' bit was set to '0' is undefined, and SHOULD NOT be done 🙅‍♀️.

'I' bit support is negotiated when both agents have set the 'I' bit to '1' in their revocation support extensions 🤝.

It's really important to note that this extension is skippable 🦋. (That means if the receiving mobility agent doesn't understand this extension, it MUST skip it and keep processing the rest of the registration request.) Iconic behavior, periodt 💜.

3.3. Registration Revocation Messages ✨

okay so a revocation message is what a mobility agent sends to another mobility agent (or to a 'direct' co-located mobile node 🫶) to say "hey, I'm cancelling this mobile node's binding." it's giving breakup text but make it protocol 💅

IP Fields:

  • Source Address
    • If the home agent is issuing the registration revocation, this is the address registered with the care-of address as that of the home agent (that is, the address identified as the home address of this binding). 🏠
    • If the foreign agent is issuing the registration revocation, this is the address registered with the home agent as the care-of address. 🌸
  • Destination Address
    • If the home agent is issuing the registration revocation, this is the source address of the last approved registration request for this binding. Put another way, it's the destination address of the last registration reply indicating success for this binding. 📬
    • If the foreign agent is issuing the registration revocation, this is the address registered as that of the home agent by the mobile node whose registration is being revoked. 🦋

UDP Fields:

  • Source Port: variable
  • Destination Port: 434 🎀

The UDP header is followed by the Mobile IP fields shown below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Reserved    |A|I|          Reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Domain Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Foreign Domain Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Revocation Identifier                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |   Authenticator...
   +-+-+-+-+-+-+-+-+-+-+-+-+-
  • Type: 7 🔥
  • Reserved: MUST be sent as 0, ignored when received. 🫧
  • A: Agent bit ('direction' bit). This one is giving main character energy 👑 It identifies the role of the agent sending the revocation, which is the 'direction' of the revocation message. This is useful for detecting reflection attacks, particularly when symmetric keying is being used.
    • Set to '0' if the revoking agent is servicing this binding as a foreign agent.
    • Set to '1' if the revoking agent is servicing this binding as a home agent.
  • I: Inform bit. ⭐ This bit MUST NOT be set to '1' unless 'I' bit support was negotiated in the revocation extension messages passed in the registration process, otherwise the results can be unpredictable. 💀
    • When sent by the home agent to a foreign agent:
      • Set to '0' to request that the mobile node SHOULD NOT be informed of the revocation, or because the use of the 'I' bit was not agreed upon.
      • Set to '1' to request that the mobile node be informed of the revocation.
    • When sending a revocation message to a 'direct' co-located mobile node, this bit is essentially irrelevant, but SHOULD be set to '1'. 🧚
    • When sent by the foreign agent:
      • Set to '0' to indicate that the foreign agent is using foreign domain policy as to whether or not the mobile node should be informed of the revocation, or because 'I' bit support was not agreed upon.
      • Set to '1' to ask the home agent if the mobile node should be informed of the revocation.
  • Reserved: MUST be sent as 0, ignored when received. 🌈
  • Home Address: The home IP address of the mobile node whose registration is being revoked. 🏡
  • Foreign Domain Address: The relevant IP address in the foreign domain that identifies which binding is being revoked. This is one of the following: (i) the foreign agent's IP address, or (ii) the co-located care-of address. 🌍
  • Home Domain Address: The IP address of the home agent that identifies which binding is being revoked. 🏠
  • Revocation Identifier: Protects against replay attacks. 🛡️ The revoking agent MUST insert its current 4-byte timestamp running off the same clock as it is using to fill in the timestamp in its revocation extensions. See section 3.5.

A registration revocation message MUST be protected by either a valid authenticator as specified in [1], namely a home-foreign authenticator if the communication is between home and foreign agents, or a mobile-home authenticator if the communication is being sent from a home agent to a 'direct' co-located mobile node. It can also be protected by another security mechanism that is at least as secure and agreed upon by the home and foreign domains, e.g., IPsec. 🔐 If any agent, or 'direct' co-located mobile node, receives a registration revocation message that does not contain a valid authenticator and is not adequately protected, the revocation message MUST be ignored and silently discarded. 🗑️ bestie, no cap, that's a hard no.

A revocation message MUST NOT be sent for any registration that has expired. It MAY only be sent prior to the expiration of a mobile node's registration. Note, however, that due to the nature of datagram delivery, this does not guarantee these messages will arrive before the natural expiration of any binding. ⏰

An agent MUST NOT send more than one revocation message or registration message per second for the same binding. Note that this updates [1] by including revocation messages in the rate limit specified in [1], i.e., that an agent MUST NOT send more than one registration message per second for the same binding. 🚦

An example of the use of revocation messages is given in Appendix A. 📖

3.4. Registration Revocation Acknowledgment Message 🦋

A revocation acknowledgment message is sent by mobility agents or 'direct' co-located mobile nodes to indicate the successful receipt of a revocation message. It's the "got it, bestie" reply 🫶

IP fields:

  • Source Address: Copied from the destination address of the received registration revocation message for which this registration revocation acknowledgment message is being generated.
  • Destination Address: Copied from the source address of the received registration revocation message for which this registration revocation acknowledgment message is being generated.

UDP fields:

  • Source Port: 434 (copied from the destination port of the revocation message). 🎀
  • Destination Port: Copied from the source port of the revocation message.

The UDP header is followed by the Mobile IP fields shown below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Reserved  |I|         Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Revocation Identifier                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-
   | Authenticator...
   +-+-+-+-+-+-+-+-+-+-+-+-+-
  • Type: 15 ✨
  • Reserved: MUST be sent as 0, ignored when received. 🫧
  • I: Inform bit. 💅 The 'I' bit MUST NOT be set to '1' in the revocation acknowledgment messages unless it was set to '1' in the revocation message. If an agent receives a revocation acknowledgment message in which the 'I' bit is set to '1', but the revocation message being acknowledged had the 'I' bit set to '0', the 'I' bit in the revocation acknowledgment message MUST be ignored. 🙈
    • When sent by the home agent:
      • Set to '1' by the home agent to request the foreign agent inform the mobile node of the revocation.
      • Set to '0' by the home agent to request the foreign agent not inform the mobile node of the revocation.
    • When sent by a foreign agent:
      • Set to '1' to indicate to the home agent that the mobile node was informed.
      • Set to '0' to indicate to the home agent that the foreign agent used local policy to determine whether or not the mobile node should be informed. For purposes of protocol robustness, it is highly recommended that such a default be set for the foreign agent to inform the mobile node of the revocation. 🌸
  • Reserved: MUST be sent as 0, ignored when received. 🌈
  • Home Address: The home address copied from the revocation message for which this acknowledgment is being sent. 🏡
  • Revocation Identifier: Copied from the Revocation Identifier of the revocation message for which this acknowledgment is being sent. See Section 3.5. 🛡️

A registration revocation acknowledgment message MUST be sent in response to a valid and authenticated registration revocation message. 🫶

A registration acknowledgment message MUST be protected by either a valid authenticator as specified in [1], namely a home-foreign authenticator if the communication is between home and foreign agents, or a mobile-home authenticator if the communication is between home agent and 'direct' co-located mobile node. It can also be protected by another security mechanism that is at least as secure and agreed upon by the home and foreign domains, e.g., IPsec. 🔐

An example of the use of Revocation Acknowledgment Messages is given in Appendix A. 📖

3.5. Replay Protection ✨

okay so registration revocation messages are literally built to kick a mobile node (or a whole bunch of them at once) off service 💀, which means replay protection is crucial. otherwise you get denial of service attacks from "malicious repeaters" (the ones who stash datagrams and replay them later) or "malicious reflectors" (the ones who bounce packets straight back at their original source). both are a form of "active" attack 🙈 See Section 6. for a discussion of these security considerations.

All Revocation Messages and Revocation Acknowledgment Messages MUST be authenticated, as well as replay-protected 🔐. The order in which they are done is up to implementation, so do whatever works for your setup 💅.

Replay protection is handled with a simple timestamp mechanism. It uses a single 32-bit identifier field in the registration revocation message, together with the home address field, to match any revocation acknowledgment messages up with their revocation messages. Here's how it goes:

  • The revoking agent sets the 'A' bit to its agent-type, and sets the Revocation Identifier field in the registration revocation message to a valid 32-bit timestamp from the same clock it is using to set the timestamp field of its revocation extensions included in registration messages.
  • Upon receipt of an authenticated revocation message, the receiving agent (or 'direct' co-located mobile node) MUST check the value of the 'A' bit and the Revocation Identifier, to make sure this revocation message is not a replay of an old revocation message received from the same agent. The receiving agent MUST also check that the message is not a reflection of a revocation message it sent in relation to the identified binding. If the 'A' bit and Identifier field imply this packet is a replay, the revocation message MUST be silently discarded 👀.
  • When building a revocation acknowledgment message, the acknowledging agent (or 'direct' co-located mobile node) copies the values of the Home Address and Revocation Identifier fields from the revocation message into the Home Address and the Revocation Identifier of the revocation acknowledgment message. This is so the revoking agent can match this revocation acknowledgment to its corresponding revocation message 🎀.
  • Upon receiving a valid revocation acknowledgment, the revoking agent MUST check the Home Address and Identifier fields to make sure they match those fields from a corresponding revocation message it sent to the acknowledging agent. If not, this revocation acknowledgment message MUST be silently discarded.

Note that since the Identifier in an incoming revocation message is a 32-bit timestamp, it is possible for an agent to check the validity of the Identifier fields without having to remember all identifiers sent by that corresponding agent. big brain move 🧠✨

Note: as it is possible for a mobile node to register at different times with different home agents, and at different times with different foreign agents, it is crucial that it not be required that the Identifier fields be unique in messages from different agents, as there is no guarantee that clocks on different agents will be synchronized. For example, if a mobile node has simultaneous bindings with multiple foreign agents, and if revocation messages are received by more than one such foreign agent "simultaneously", it is possible the revocation message from one of these foreign agents may contain Identifier fields that happen to match those of any or all the other foreign agents. This MUST NOT result in any of these revocation messages being ignored 🚨.

4. Registration Revocation Overview 🦋

Registration Revocation is made of two distinct pieces: a signaling mechanism between tunnel endpoints, and a signaling mechanism between foreign agent and mobile node 🌸. A 'direct' co-located mobile node MAY implement revocation extensions and revocation acknowledgment, so it can receive and respond to revocation messages from its home agent. however, a 'direct' co-located mobile node MUST NOT send a revocation message, since de-registration messages defined in [1] are sufficient for this purpose 🙅‍♀️.

For further discussion on security issues related to registration revocation, refer to Section 6. 🔐

4.1. Mobile Node Notification 💌

A mechanism which gives a foreign agent a way to actively notify a mobile node that its binding has been reset already exists in [1], though it has been overlooked for this purpose 👀.

Let's do a quick refresher on the sequence number in agent advertisements from [1], so it's crystal clear how the foreign agent 'implies' to the mobile node that its binding is no longer active 🧚.

When a foreign agent begins sending agent advertisements, it starts with a sequence number of 0, and [monotonically] increments the sequence number with each subsequent agent advertisement. So a mobile node can tell a foreign agent that has simply run out of sequence number space apart from one that has been reset, the agent sets the sequence number to 256 instead of rolling to 0 when it goes past its maximum value [1]. This way, a mobile node would have to miss 256 advertisements in a row at that time to mistake a reset for a roll-over 😳. Moreover, the lifetimes contained within an agent advertisement should be set in such a way that when a mobile node believes it has missed 3 beacons, the entry for this foreign agent should time out, and if the mobile node is registered there, it should send an agent solicitation [1]. If, however, an agent is somehow reset, it will begin advertising with a sequence number of 0, and the mobile node can presume this foreign agent has lost its binding. The mobile node SHOULD re-register to make sure it is still obtaining Mobile IP services through this foreign agent 🔁.

Leveraging this mechanism, a foreign agent may consciously notify all mobile nodes currently bound to it that it has "reset" all of their bindings, even if the agent itself has not been reset, by simply [re]setting the sequence number of the next agent advertisement to 0 💅. Moreover, a foreign agent may inform all mobile nodes currently bound to it that they should re-register with a different foreign agent, by simultaneously setting the 'B' bit in the advertisement to 1. This indicates this foreign agent is busy and is not accepting new registrations [1]. In these situations, any mobile node in compliance with [1] will presume this foreign agent has lost its binding, and must re-register if they wish to re-establish Mobile IP functionality with their home subnet 🏠.

To indicate to any registered mobile node that its binding no longer exists, the foreign agent with which the mobile node is registered may unicast an agent advertisement with the sequence number set to 0 to the mobile node [1], [D]. Moreover, if such a foreign agent wishes to indicate to the mobile node that its binding has been revoked, and that the mobile node should not attempt to renew its registration with it, the foreign agent MAY also set the 'B' bit to 1 in these agent advertisements. This indicates it is busy, and is not accepting new registrations [1]. All mobile nodes compliant with [1] will understand that this means the agent is busy, and MAY either immediately attempt to re-register with another agent in their foreign agent cache, or MAY solicit for additional agents. In the latter case, a foreign agent can optionally remember the mobile node's binding was revoked, and respond to the solicit in the same way, namely with the 'B' bit set to 1 🫶. It should be noted, though, that since the foreign agent is likely to not be setting the 'B' bit to 1 in its broadcasted agent advertisements (sent to the entire link), the revoked mobile node, upon hearing this agent's multicast agent advertisement without the 'B' bit set, may attempt to [re]register with it. If this happens, depending on foreign domain policy, the foreign agent can simply deny the mobile node with an appropriate error code (e.g., "administratively prohibited"). At this time, a mobile node can use foreign agent fallback to attempt to register with a different foreign agent, as described in [1] 🦋.

Mobile nodes which understand the revocation mechanism described by this document may understand that a unicast agent advertisement with the sequence number reset to 0 could indicate a revocation. They may attempt to re-register with the same foreign agent, register with a different foreign agent, or co-locate 🌈.

Agent Advertisements unicast to a mobile node MUST be sent as described in [1], in addition to any methods currently in use on the link to make them secure or authenticatable, to protect from denial-of-service attacks 🛡️.

4.2. Registration Revocation Mechanism - Agent Notification 📣

A foreign agent that is currently supporting registration revocation on a link MUST set the 'X' bit in its Agent Advertisement Extensions being sent on that link. This allows mobile nodes requiring Registration Revocation services to register with those foreign agents advertising its support 💖.

4.2.1. Negotiation of Revocation Support 🤝

okay so think of registration like a little handshake 🫶. If the foreign agent wants to take part in revocation messages with the home domain, it MUST already have a security association with the home agent named in the registration request, and it MUST tack a revocation support extension (defined in Section 3.2.) onto that request. If the registration reply from this home agent doesn't include a revocation support extension, the foreign agent SHOULD assume the home agent doesn't understand registration revocation, or just isn't up for it 🙃. If that's a dealbreaker, the foreign agent MAY deny the registration with e.g., "Administratively Prohibited" 💅. Also, when a security association exists, as specified in [1], the registration request and the registration reply MUST still contain home-foreign authenticators. No skipping that part, bestie 🔐.

If a home agent wants to be able to swap revocation messages with the foreign domain, it MUST have a security association with the foreign agent that relayed the registration request, and it MUST append a revocation support extension to the registration reply 📬. If the foreign agent's registration request didn't have a revocation support extension, the home agent SHOULD assume the foreign agent doesn't understand registration revocation, or isn't willing to join in for this specific binding 🤷‍♀️. If that's not okay with the home agent, it MAY deny the registration with e.g., "Administratively Prohibited". The home agent MAY also include a revocation support extension in the registration reply ✨.

Now for a 'direct' co-located mobile node that wants to hear about a released binding from its home agent 📣. It MUST insert a revocation support extension into the registration request. If the home agent is cool with that, it MUST include a revocation support extension in its registration reply 🙌. If it's not cool with that, the home agent MAY deny the registration, or it MAY simply not include a revocation support extension in the reply, which quietly tells the mobile node it won't be part of revocation for this binding 👀. A home agent that gets a registration request from a 'direct' co-located mobile node without a revocation support extension MAY deny the registration with e.g., "Administratively Prohibited", and it also MAY or MAY NOT include a revocation support extension in the registration reply. It's a choice, babe 💅.

Quick reminder: a non-colocated mobile node MUST NOT insert a revocation support extension into its registration request 🚫. If a foreign agent gets one of those anyway, it MUST silently discard it, and it MAY log it as a protocol error 🙈.

The 'I' bit in the revocation extension tells everyone whether the decision to inform the mobile node that its binding is terminated gets left up to the home agent 🎀. This is offered by the foreign agent and accepted by the home agent. So when the foreign agent sends a revocation extension on a registration request with the 'I' bit set to 1, it's basically saying the home agent MAY leave the decision to inform this mobile node that its registration is terminated up to the home agent. (The term "MAY" is used here because domain policy can change during the lifetime of any registration, and the spec knows it 🧠.) The home agent can say yes by setting the 'I' bit to 1, or say no by setting the 'I' bit to 0, in the revocation extension in the registration reply 💜.

Revocation support counts as negotiated for a binding once both sides have included a revocation support extension during a successful registration exchange 🎉. Iconic.

4.2.2. Home Domain Revoking/Releasing a Registration 🏠

This section breaks down who does what, depending on what got negotiated in the revocation support extensions, when the home domain is the one revoking a registration 👑.

4.2.2.1. Home Agent Responsibilities 📮

When a home agent is revoking a mobile node's binding and revocation support has been negotiated, the home agent MUST notify the foreign domain address that it's terminating the tunnel entry point, by sending a revocation message 📨. Heads up that the foreign domain address can be either the foreign agent care-of address, or the co-located care-of address of a 'direct' co-located mobile node 🧚.

As a home agent, it MUST set the 'A' bit to '1', which tells everyone this packet is coming from the home agent servicing this binding 🙌.

When a revocation message is going to a foreign agent, and the 'I' bit was negotiated during registration, the home agent MUST set the 'I' bit to 1 if it wants the foreign agent to inform the mobile node about the revocation 📣. On the flip side, if the home agent does NOT want the mobile node notified, it MUST set the 'I' bit to 0. Also, the home agent could set the 'I' bit to '0' because it knows the mobile node has registered with a different foreign agent, so the foreign agent doesn't need to bother trying to notify anyone 🫠.

The home agent MUST set the Identifier field as defined in Section 3.5., and MUST include a valid authenticator as specified in Section 3.3. Two musts, no cap 🔐.

If the home agent doesn't get a revocation acknowledgment message within a reasonable amount of time, it MUST retransmit the revocation message 🔁. How long it waits before retransmitting, and how many times it retransmits, is limited by these rules:

  • every time the home agent is about to retransmit the revocation message, it MUST update the value of the timestamp in the revocation identifier with a current value from the same clock used to generate the timestamps in the revocation extensions sent to this foreign agent. This also necessarily means updating any fields derived using the revocation identifier (e.g., a home-foreign authenticator) ⏰.
  • the home agent MUST NOT send more than one revocation per second for a particular binding 🚦.
  • the time between retransmissions SHOULD fall-back in analogy with the registration guidelines in [1], namely exponential backoff, and 📉.
  • the home agent MUST NOT retransmit revocation messages beyond the normal life of the binding identified by the revocation message 🛑.

4.2.2.2. Foreign Agent Responsibilities 🛡️

When a foreign agent gets a registration revocation message, it MUST check the validity of the authenticator, the 'A' bit, and the identifier field against replay, as defined by Section 3.5. It MUST also figure out which binding the home agent is releasing, using the info in the revocation message: the mobile node address, the foreign domain address, the home domain address, the timestamp in the revocation message, and the timestamp in the last accepted registration message 🕵️‍♀️. Revocations are only valid for existing registrations, so the timestamp of a registration MUST precede the revocation message. (Both of those timestamps were set by the same home agent, so they should line up 💕.) Once it finds the binding, the foreign agent MUST revoke it, and MUST respond with a revocation acknowledgment sent to the source address of the revocation message 💥. If the 'I' bit was negotiated, the foreign agent MUST check the value of the 'I' bit in the revocation message and act accordingly 🎯.

If the foreign agent is notifying the mobile node using the methods in Section 4.1., it MUST set the 'I' bit to '1' in the revocation acknowledgment going to the home agent. If it is NOT notifying the mobile node, it MUST set the 'I' bit to '0' 🌸.

The foreign agent may discontinue all Mobile IP services for the former binding at this point, and free up any resources that were being used for it 🧹.

Then the foreign agent MUST generate a revocation acknowledgment. It sets the Home Address and Identifier field in that acknowledgment as described by Section 3.5., and protects it with a valid authenticator as specified in Section 3.3. Full closure, babe 🔒.

4.2.2.3. 'Direct' co-located mobile node Responsibilities 📱

When a 'direct' co-located mobile node gets a revocation message, it MUST validate the authenticator, and check the home address and identifier in the revocation message for replay 🔍. If the packet passes authentication and the identifier shows this revocation is new, the mobile node MUST verify that the information in the revocation message identifies the home agent it has a current binding with. It also MUST verify that this binding correctly identifies this mobile node and any foreign domain address it's currently using 🧐. If the mobile node can identify such a binding, it SHOULD first generate a revocation acknowledgment message, which MUST be sent to the IP source address of the revocation message 💌. After that, the mobile node may terminate any reverse tunnel encapsulation [C] it's using to this home agent, consider its binding revoked, and free up any other resources tied to the former binding 🫧.

4.2.3. Foreign Domain Revoking/Releasing a Registration 🌍

This section lays out the responsibilities of each party, depending on what got negotiated in the revocation support extensions, when the foreign domain is the one revoking a registration 🦋. Note that revocation support for a co-located mobile node registering via a foreign agent (because the 'R' bit was set in the agent's advertisement) is NOT supported. Check out Section 4.3.1. for the details 👀.

4.2.3.1. Foreign Agent Responsibilities 💅

okay so bestie, this is where the foreign agent gets to make its moves 🫶 If the use of the 'I' bit was negotiated, AND the foreign domain policy of informing the mobile node hasn't changed since the last successful registration exchange, the foreign agent MUST NOT inform any mobile node of its revocation at this time. Instead, it MUST set the 'I' bit to '1' in the revocation message 🦋 which basically asks the home agent to use the 'I' bit in the revocation acknowledgment to say whether the effected mobile nodes should get notified. If the foreign domain's policy was to not notify the mobile node, or it changed since the most recent successful registration, and the foreign agent can no longer use the 'I' bit, then the foreign agent MUST set the 'I' bit to '0' and follow the foreign domain's policies about notifying the mobile node 🌸

Note that the 'A' bit MUST be set to '0' to indicate that the revocation message is coming from the foreign agent servicing this binding. This is the "it's me, the agent handling your binding" signal 💜

Before transmitting the revocation message, the foreign agent MUST set the revocation identifier as described by section 3.5., and MUST include an authenticator as described by section 3.3. Main character setup, no skipping steps ✨

If the foreign agent does not receive a revocation acknowledgment message within a reasonable amount of time, it MUST retransmit the revocation message. How long the foreign agent waits before retransmitting, and how many times the message gets retransmitted, is only limited by the following specifications 🍓

  • every time the foreign agent is about to retransmit the revocation message, it MUST update the value of the timestamp in the revocation identifier with a current value from the same clock used to generate the timestamps in the revocation extensions sent to this home agent. Note that this also necessarily means updating any fields derived using the revocation identifier (e.g., a home-foreign authenticator). Fresh timestamp every single time, periodt 💅
  • MUST NOT send more than one revocation per second for a particular binding,
  • SHOULD set its retransmissions to fall-back in analogy with the registration guidelines in [1], namely exponential backoff, and
  • MUST NOT retransmit revocation messages beyond the normal life of the binding identified by the revocation message.

4.2.3.2. Home Agent Responsibilities 🏠

okay now it's the home agent's turn to show up 🎀 Upon receiving a registration revocation message, the home agent MUST check the 'A' bit, and identifier field, as well as the authenticator. If the packet is acceptable, the home agent MUST locate the binding identified by the foreign agent as being released, using the information in the revocation message: namely the addresses identified by the home address, the foreign domain address and the home domain address fields. As revocations are only valid for existing registrations, the timestamp of a registration MUST precede the revocation message (note that both of those timestamps were set by the same foreign agent). Since this binding is no longer active, the home agent can free up any resources associated with the former binding and discontinue all Mobile IP services for it. Bye binding 👋

Upon processing a valid registration revocation message, the home agent MUST send a revocation acknowledgment to the IP source address of the registration revocation message.

If use of the 'I' bit was negotiated, and the 'I' bit is set to '1' in the revocation message, the home agent should decide if it wants the mobile node informed of the revocation of this binding. If it does want the mobile node informed, it MUST set the 'I' bit in the revocation acknowledgment message to '1'. If it does not want the mobile node informed, it MUST set the 'I' bit to '0' 🧚

The home agent MUST set the Home Address and Revocation Identifier fields as described by Section 3.5., and protect the revocation acknowledgment message with a valid authenticator as specified in Section 3.3. Everything gets locked down 🔐

4.2.4. Mobile Node Deregistering a Registration 🦋

so when the mobile node is the one who wants out, the vibe changes 🌈 The cases where a mobile node is registered with its home agent, whether it's registered directly with its home agent (a 'direct' co-located mobile node) or registered via a foreign agent, and wishes to terminate its own binding, the mobile node MUST NOT send a revocation message. Instead, it SHOULD simply deregister the appropriate care-of address with its home agent as described by [1]. It's giving "handle your own breakup" energy 💅

4.3. Mobile IP Registration Bits in the Revocation Process ✨

Several of the bits used in the registration process need special consideration when using the revocation mechanism. These bits need a little extra attention, bestie 🫶

4.3.1. The 'R' Bit in Use 🎀

If the foreign agent wishes to be able to revoke a mobile node's registration, it MUST set the 'R' bit in its agent advertisements. (A foreign agent advertising the 'R' bit requests every mobile node, even one that is co-located (and whose registration would otherwise by-pass the foreign agent), to register with the foreign agent.) However, in this case, the foreign agent SHOULD deny a registration request as "Administratively Prohibited" from a mobile node that is registering in a co-located fashion. The reason being that the foreign agent will not be able to revoke the binding of a co-located mobile node, due to reasons outlined in Section 4.3.2 🙈

How the foreign agent and/or foreign domain enforce the 'R' bit is beyond the scope of this document.

4.3.2. The 'D' Bit in Use 🍓

A mobile node registering directly with its home agent in a co-located fashion, with the 'D' bit set in its registration request, is supported in registration revocation. However, support for a co-located mobile node (with the 'D' bit set in its registration request) registering via a foreign agent is not supported, for the following reasons 💀

Registration requests where the 'D' bit is set, and which are relayed through a foreign agent (e.g., due to the advertising of the 'R' bit), should theoretically contain the foreign agent address as the source address of the registration request when received by the home agent. A home agent may conclude that the source address of this registration request is not the same as the co-located care-of address contained in the registration request, and is therefore likely to be the address of the foreign agent. However, since there is no way to guarantee that this IP source address is in fact an address of the foreign agent servicing the mobile node, accepting a revocation message from this IP source address may lead to a denial-of-service attack by a man-in-the-middle on the mobile node. Yikes 😭

Moreover, there is currently no method for the foreign agent servicing the mobile node to identify itself to the home agent during the Mobile IP registration phase. Even if a foreign agent could identify itself, the co-located mobile node would also need to authorize that this foreign agent is indeed the agent that is providing it the Mobile IP services. This is to thwart a denial-of-service attack on the mobile node by a foreign agent that has a security association with the home agent, and is on the path between the co-located mobile node and the home agent. So many layers of trust to check, iykyk 🔐

5. Error Codes 🌸

As the intent of a registration revocation message is not a request to discontinue services, but is a notification that Mobile IP services are discontinued, there are no new error codes. No new error codes, no drama 💖

6. Security Considerations 🚨

There are two potential vulnerabilities: one in the agent advertisement mechanism, and one related to unauthorized revocation messages. Security is about to be a whole thing, so pay attention 👑

6.1. Agent Advertisements 📡

Although the mechanisms defined by this document do not introduce this problem, it has been recognized that agent advertisements as defined in [1] subject mobile nodes to a denial-of-service potential. This is because the agent advertisement as defined in [1] may be spoofed by other machines residing on the link. This makes it possible for such nodes to trick the mobile node into believing its registration has been revoked, either by unicasting an advertisement with a reset sequence number to the link-local address of the mobile node, or by broadcasting it to the subnet, thereby tricking all mobile nodes registered with a particular foreign agent into believing all their registrations have been lost. Not the vibe 😱

There has been some work in this working group and others (e.g., IPsec) to secure such router advertisements, though at the time of this publication, no solutions have become common practice. To help circumvent possible denial of service issues here, bringing their potential for disruption to a minimum, mobile node implementors should ensure that any agent advertisement which doesn't conform to a strict adherence to [1], specifically those whose TTL is not 1, or which do not emanate from the same link-address (when present) as other agent advertisements supposedly from the same agent, or even that of the last successful registration reply, be silently discarded. Filter out the fakes, babe 🧚‍♀️

6.2. Revocation Messages 🔐

okay so, registration revocation literally ends the Mobile IP services being given to the mobile node, so it is crucial that all security and replay protection gets verified before a mobility agent believes the other agent has revoked a binding 😭. Messages sent link-local (like between the mobile node and the foreign agent) MAY also be secured with the methods in [1], namely the mobile-foreign authenticators, but those have no direct relation to registration revocation 💅.

RFC 3344 [1] defines a security mechanism that MUST be used between home agents and mobile nodes, and MAY used between home agents and foreign agents, namely authenticators. All foreign and home agents MUST support protection of revocation messages via the foreign-home authenticators defined in [1]. They MAY implement other mechanisms of equal or greater strength, and if such mechanisms are known to be available to both parties, they MAY be used instead ✨.

Revocation messages are at least as secure as registration messages passed between home and foreign agents that contain home-foreign authenticators as defined in [1]. So literally no new security threats come from the revocation mechanism, other than the ones already in [1] about the shared secret used to generate the home-foreign authenticators getting compromised 🫶.

That said, there are two kinds of active attacks that use messages captured "in flight" by a man-in-the-middle between the home and foreign agents: "malicious repeaters" and "malicious reflectors" 🙈.

In a "malicious repeater" attack, a man-in-the-middle captures a revocation message, then replays it to the same IP destination address at a later time. Presuming the authenticator of the original packet was deemed valid, the home-foreign authenticator of the replayed packet will (again) pass authentication if there's no replay protection. Also, since datagrams are not guaranteed to arrive unduplicated, a replay may occur by "design" 💀.

In a "malicious reflector" attack, a man-in-the-middle captures a revocation message, then returns it to its originator at a later time. If the security association between the home and foreign domains uses a (single) shared secret that only protects the contents of the UDP portion of the packet (such as home-foreign authenticators as defined by [1]), and there's no replay protection, the sender of the packet will also believe the revocation message is authentic 😭.

The replay protection mechanism used by the revocation messages defined by this document is designed to protect against both of these active attacks 🛡️. As a benefit, by using a 32-bit timestamp, it can be more quickly determined whether revocation messages are replays, though the reader is advised to use caution with this approach. An agent that receives an authenticated revocation message can compare the Identifier field to that of a previously received revocation message. If the timestamp in the new message was generated after the timestamp in the last revocation message received, it can immediately be determined as not being a replay ✨.

Note however that since datagrams are not guaranteed to arrive in order, it should not be presumed that, because the values in an Identifier field are timestamps, they will necessarily be increasing with each successive revocation message received 🌀. Should an implementor decide to base their replay detection mechanism on increasing timestamps (and therefore increasing Identifier values), a suitable time window should be defined in which revocation messages can be received. At worst, ignoring a revocation message should result in the retransmission of another revocation message, this time with a timestamp later than the last one received 🦋.

Note that any registration request or reply can be replayed 👀. With the exchanging of time-stamps by agents in revocation extensions, an agent should have a belief that such messages have been delivered in a timely manner. For purposes of registration revocation, the timeliness of a registration packet is simply based on the granularity of each registration. Since [1] provides a replay mechanism for the home agent to use, the home agent has a way to tell if the registration request being presented to it is new. The foreign agent, however, has no such mechanism in place with the mobile node 😤.

Foreign agents are advised to continue to consider registrations 'outstanding' until the associated registration reply is returned from the home agent, before using the information in any of its visitor entries. Even so, this leaves the foreign agent open to a potential denial of service attack, in which registration requests and replies are replayed by multiple nodes. When this happens, the foreign agent could be lead to believe such registrations are active, but with old information. That can have adverse effects on them, and on the ability of that agent to successfully use the procedures outlined in this document 🥺. Sufficient protection against this scenario is offered by the challenge-response mechanism [2], by which a foreign agent generates a live challenge to a mobile node, for the purposes of making sure (among other things) that the registration request is not a replay 🔥.

7. IANA Considerations ✨

This document defines an additional set of messages between the home and foreign agent, specific to the services being provided to the same mobile node, or sub-set of mobile nodes. To ensure correct interoperation based on this specification, IANA has reserved values in the Mobile IP number space for two new message types, and a single new extension 🎀.

7.1. New Message Types

The following message types are introduced by this specification:

  • Registration Revocation: A new Mobile IP control message, using UDP port 434, type 7. This value has been taken from the same number space as Mobile IP Registration Request (Type = 1) and Mobile IP Registration Reply (Type = 3) 🌸.
  • Registration Revocation Acknowledgment: A new Mobile IP control message, using UDP port 434, type 15. This value has been taken from the same number space as Mobile IP Registration Request (Type = 1) and Mobile IP Registration Reply (Type = 3) 💜.

7.2. New Extension Values

The following extensions are introduced by this specification:

  • Revocation Support Extension: A new Mobile IP Extension, appended to a Registration Request or Registration Reply. The value assigned is 137. This extension is derived from the Extension number space. It MUST be in the 'skippable' (128 - 255) range as defined in RFC 3344 🧚.

7.3. New Error Codes

There are no new Mobile IP error codes introduced by this document 🍓.

8. References 📚

8.1. Normative References (Numerical)

  • [1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [2] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
  • [3] Bradner, S., "Key Words for us in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informational References (Alphabetical)

  • [A] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
  • [B] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., Shiino, H., Walsh, P., Zorn, G., Dommety, G., Perkins, C., Patil, B., Mitton, D., Manning, S., Beadles, M., Chen, X., Sivalingham, S., Hameed, A., Munson, M., Jacobs, S., Lim, B., Hirschman, B., Hsu, R., Koo, H., Lipford, M., Campbell, E., Xu, Y., Baba, S. and E. Jaques, "Criteria for Evaluating AAA Protocols for Network Access", RFC 2989, November 2000.
  • [C] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
  • [D] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
  • [E] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.

Appendix A: An Example of the Revocation Messages in Use ✨

For clarity, the following example is meant to illustrate the use of the new messages in the registration phase and the revocation phase. In this example, a foreign agent and home agent will negotiate revocation during the registration phase. During the revocation phase, the foreign agent will revoke the binding of a mobile node 🦋.

A.1. The Registration Phase

Consider a foreign agent that supports registration revocation and has a security association with a home agent to which it is forwarding a registration request. The foreign agent will include the revocation support extension after the mobile-home authenticator. Assume that the foreign agent supports the use of the 'I' bit and is willing to let the home agent decide if the mobile node should be informed of the revocation of its registration. Thus, the foreign agent will set the 'I' bit to '1'. The foreign agent will append a foreign-home authenticator to the registration request 💖.

Upon receiving the registration request containing a revocation extension, the home agent will include a revocation support extension in the registration reply. Since the foreign agent set the 'I' bit to '1' in its revocation extension, and the home agent supports the use of the 'I' bit, the home agent will set the 'I' bit in its registration extension to '1'. Additionally, the home agent will append a home-foreign authenticator to the registration request 🌈.

Upon receiving the authenticated registration reply, the foreign agent will check the revocation support extension and note that the home agent wants to decide if the mobile node should be notified in the event this registration is revoked, i.e., since the home agent set the 'I' bit in the return revocation extension 👑.

A.2. The Revocation Phase 🦋

Okay so the foreign agent revokes a mobile node's binding and makes a revocation message for the mobile node's home agent 💌. Since the 'I' bit was negotiated in the revocation extensions, and the foreign agent is still willing to let the home agent decide whether this mobile node gets told about the revocation, it sets the 'I' bit to 1 in the revocation message. It also makes sure the 'A' bit is set to 0 ✨.

The foreign agent also puts the address of the mobile node whose registration it wants to revoke in the home address field 🎀. It puts the address the mobile node registered as its care-of address in the foreign domain field, and the address registered as the home agent in the home domain address field. Then it sets the Revocation Identifier to the current 32-bit timestamp and appends the foreign-home authenticator 🔐. Main character energy for real 👑.

When the home agent gets that revocation message, it uses the address in the foreign domain field to find the security association and authenticate the message 🛡️. After authentication, it checks that the 'A' bit and Identifier show this revocation isn't a replay 🙈. Then it uses the mobile node home address, foreign domain address, and home domain address to find the mobile node whose registration is being revoked 🔍.

Once the home agent has processed a valid registration revocation message, it generates a revocation acknowledgment message 🫶. Since the 'I' bit was set to 1 in the revocation message, and the home agent wants the identified mobile node to be informed of the revocation, it sets the 'I' bit in the revocation acknowledgment to 1 too 💜. It copies the home address and the Revocation Identifier field into the revocation acknowledgement 🌸. The home agent protects the revocation acknowledgment with a home-foreign authenticator 🔒.

Last step: when the foreign agent gets a valid revocation acknowledgment (where the authenticator and Identifier fields are acceptable), it checks the state of the 'I' bit 🔥. Since the 'I' bit is set to 1, the foreign agent notifies the mobile node of the revocation 📣. Iconic, honestly 💅.

Appendix B: Disparate Address, and Receiver Considerations 🌈

Okay, so the registration revocation message comes from a source address that is topologically routable from the interface that receives the datagram. That means the agents, by definition, are topologically connected 🧠 (if this weren't true, the initial registration mechanism would have failed 💀). If either agent is the ultimate hop from this topologically connected region to one or more disparate address spaces, no problems are foreseen ✨. For the mobile node to have successfully registered with its home agent, it MUST have provided to the network (foreign agent) it's currently attached to a routable address of its home agent 🏠. Flip it around, and the care-of address the mobile node is using must also be topologically significant to the home agent, or the registration reply couldn't have been received and the tunnel couldn't have been started 🚇. So by definition, the home agent address and the care-of address must each be significant, and either address must form a unique pair in the context of this mobile node to both agents 🦋.

Another way to think about it: the tunnel endpoints are connected in some way, so each one is unique as far as the other end is concerned 💖. The address at the other end of the tunnel, combined with the mobile node's address, must therefore form a unique pair that the agent receiving the registration revocation message can identify 🔑.

Here's an example 🎀. Picture a mobile node whose home address lives in disparate address space A, behind its home agent. In the diagram below, [*] marks an interface of the entity it appears in 👀.

   MN[a]-----[c]FA[b]=====((()))=====[b]HA[a]-----[a]CN

       Address      Some topologically      Address
       Space C      connected network       Space A

We presume a binding for MN exists, which means there's a tunnel between FA[b] and HA[b] 🌉. Then, since the address assigned to MN[a] MUST be unique in address space A, the pair {FA[b],MN[a]} is guaranteed to be unique in the binding table of HA, and the pair {HA[b],MN[a]} is guaranteed to be unique in the foreign agent's visitor list 📋.

So a home agent that receives a registration revocation message and foreign-home authenticator for MN[a] from FA[b] can figure out the unique mobile node address being deregistered 🧚. Going the other way, a foreign agent that receives a registration revocation message and home-foreign authenticator for MN[a] from HA[b] can determine the exact mobile node address being deregistered 🎯. That's why, if a foreign agent receives a registration revocation message with the home domain field set to the zero address, it MUST be silently discarded 🚫. This keeps things from getting confusing when there are overlapping private addresses 🌀. When multiple mobile nodes are registered via the same care-of address and happen to use the same (disparate/private) home address, the home agent address in the home domain field is the only way a foreign agent can tell those mobile nodes apart 🫶.

Acknowledgments 🌸

The authors want to thank Rajesh Bhalla, Kent Leung, and Alpesh Patel for their contributions to the concepts in draft-subbarao-mobileip-resource-00.txt, "Releasing Resources in Mobile IP" 🙌. The revocation support extension and the acknowledgment mechanism in this document came from that draft 💜.

The authors would also like to thank Pete McCann for his discussions on replay mechanisms and security concerns ✨. They also thank Ahmad Muhanna for pointing out a problem with the initial replay mechanism, which eventually led to the addition of a time stamp to the Revocation Extension ⏰.

The authors would also like to acknowledge Henrik Levkowetz for his detailed review of the document 📝, and Michael Thomas for his review of the replay mechanism described here 🦋.

Authors' Addresses 💌

   Steven M. Glass
   Solaris Network Technologies
   Sun Microsystems
   1 Network Drive
   Burlington, MA.  01801

   Phone: +1.781.442.0000
   Fax:   +1.781.442.1706
   EMail: steven.glass@sun.com


   Madhavi W. Chandra
   IOS Technologies Division
   Cisco Systems
   7025 Kit Creek Road
   Research Triangle Park, NC 27709

   Phone: +1.919.392.8387
   EMail: mchandra@cisco.com

Copyright (C) The Internet Society (2003). All Rights Reserved. ©️ vibes locked in 💜

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English 🌍.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees ♾️.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 🙃.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from