Registration Revocation in Mobile IPv4
Extracted elements (25)
Mobile node notification of binding revocation leverages the existing agent advertisement sequence number mechanism from RFC 3344: a foreign agent can reset the sequence number to 0 in a unicast advertisement to signal that the binding is no longer active, without introducing new protocol machinery for the mobile node.
Registration revocation does not replace Mobile IP deregistration because the purposes are fundamentally different: deregistration is used by the mobile node to inform its home agent that it has roamed home, while revocation is used between mobility agents to signal termination of bindings.
Revocation of co-located mobile nodes registering through a foreign agent (with the 'D' bit set and relayed by the foreign agent) is not supported because there is no reliable way to verify the source IP of the registration request is the foreign agent, opening a DoS attack vector via man-in-the-middle.
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. A foreign agent wishing to revoke bindings MUST set the 'R' bit but SHOULD deny co-located registrations as 'Administratively Prohibited'.
The Revocation Support Extension is in the skippable range (Type 128–255). If a receiving mobility agent does not understand this extension, it MUST skip it and continue processing the registration request, ensuring backwards compatibility with RFC 3344 agents.
A foreign agent supporting registration revocation on a link MUST set the 'X' bit in its Agent Advertisement Extensions on that link. To participate in revocation, the foreign agent MUST have an existing security association with the home agent identified in the registration request.
A foreign agent that sets the 'X' bit in an agent advertisement extension MUST support registration revocation messages on that link, including the Revocation Support Extension, Revocation Messages, and Revocation Acknowledgment.
A mobile node (whether directly co-located or registered via a foreign agent) MUST NOT send a revocation message to terminate its own registration; it SHOULD instead use the standard deregistration mechanism defined in RFC 3344.
A registration revocation acknowledgment message MUST be sent in response to a valid and authenticated registration revocation message. The acknowledgment MUST be protected by a valid authenticator (home-foreign or mobile-home) or an equivalent agreed-upon mechanism.
A registration revocation message MUST be protected by a valid home-foreign authenticator (for home-foreign agent communication) or a mobile-home authenticator (for home agent to co-located mobile node). If not adequately protected, the revocation message MUST be ignored and silently discarded.
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. An agent MUST NOT send more than one revocation message or registration message per second for the same binding.
The Revocation Support Extension MUST be attached to a registration request or reply by any entity that wants to receive revocation messages. A non-co-located mobile node MUST NOT include a Revocation Support Extension in its registration.
The Revocation Support Extension MUST be protected by a foreign-home authentication extension, a mobile-home authentication extension, or an equivalent mechanism. If not protected, the action described in RFC 3344 Sections 3.8.2.1 and 3.7.3.1 MUST be taken.
Upon receipt of an authenticated revocation message, the receiving agent MUST check the 'A' bit and Revocation Identifier for replay. It MUST also check that the message is not a reflection of a revocation it sent. If the packet is a replay, the revocation message MUST be silently discarded.
Upon receiving a valid revocation message from the home agent, the foreign agent MUST verify the authenticator, 'A' bit, and Identifier; MUST identify and revoke the binding; and MUST respond with a revocation acknowledgment. The timestamp of the accepted registration MUST precede the revocation message.
When a home agent revokes a binding, it MUST notify the foreign domain address, set the 'A' bit to '1', update the Revocation Identifier timestamp on each retransmission, MUST NOT send more than one revocation per second, SHOULD use exponential backoff, and MUST NOT retransmit beyond the binding's normal lifetime.
The Revocation Identifier is a 4-byte timestamp in both the revocation message and acknowledgment, used for replay protection. The revoking agent sets it from the same clock used for revocation extension timestamps; the acknowledging agent copies it verbatim to correlate the acknowledgment.
The 'X' bit is added to the Mobility Agent Advertisement Extension to indicate an agent's support for Registration Revocation. A foreign agent setting this bit advertises support for revocation messages on that link, allowing mobile nodes to select foreign agents with revocation support.
IANA assigned Extension Type 137 for the Revocation Support Extension, placed in the skippable range (128–255) as defined in RFC 3344, appended to Registration Request or Registration Reply messages.
IANA assigned two new Mobile IP message types using UDP port 434: Type 7 for Registration Revocation and Type 15 for Registration Revocation Acknowledgment, both drawn from the same number space as Registration Request (Type 1) and Registration Reply (Type 3).
Agent advertisements as defined in RFC 3344 are subject to spoofing by on-link nodes, enabling denial-of-service attacks: a spoofed unicast advertisement with a reset sequence number can trick a mobile node into believing its registration has been revoked. Implementations should silently discard advertisements with TTL != 1 or inconsistent link-layer source addresses.
Revocation messages are vulnerable to 'malicious repeater' attacks (capturing and replaying a message to the same destination) and 'malicious reflector' attacks (returning a message to its originator). Both attacks are mitigated by the 32-bit timestamp Revocation Identifier combined with the 'A' bit direction check and mandatory authentication.
The Registration Revocation Acknowledgment Message (Type 15, UDP source port 434) contains a 1-bit 'I' flag, a 4-byte Home Address (copied from the revocation message), and a 4-byte Revocation Identifier (copied from the revocation message) for matching to the original revocation.
The Registration Revocation Message (Type 7, UDP destination port 434) contains an 'A' bit (direction/agent-type), an 'I' bit (Inform), a 4-byte Home Address, 4-byte Home Domain Address, 4-byte Foreign Domain Address, and a 4-byte Revocation Identifier (timestamp).
The Revocation Support Extension (Type 137, Length 6) contains a 1-bit 'I' flag and a 4-byte Timestamp field. The Timestamp identifies registration ordering, approximate clock offset between agents, and supports replay detection for revocation messages.