Summary

  • RFC 5419 records an operator case for authenticating Mobile IPv6 Binding Updates through an existing home AAA relationship, but its example does not make the AAA-to-Home-Agent key path a general IETF contract.
  • The document itself distinguishes an illustrated RADIUS exchange from a missing standard mechanism for creating an MN–HA key and security association from the MN–AAA association.
  • RFC 4877 later gave MIPv6 an IKEv2/IPsec route that RFC 5419 says addressed some earlier objections; the 2009 rationale is not evidence of present-day deployment.

A binding update carries a request, not the whole trust relationship

Mobile IPv6 lets a node keep its home address while it is attached elsewhere. It tells a Home Agent where it can currently be reached with a Binding Update (BU); the HA records that binding and can tunnel traffic toward the care-of address. The protocol’s base security model protects MN–HA signaling with an IPsec security association. That model is clear about the endpoints. The operational question is how those endpoints acquire compatible credentials when the operator’s subscriber authority sits elsewhere.

In January 2009, RFC 5419 captured the reasoning behind RFC 4285’s alternative mobility-message authentication option. It is an Informational document, written for archival purposes, and expressly says the alternative does not deprecate IPsec. Its examples are rooted in CDMA2000 and WiMAX architectures as their authors described them at the time. They wanted an existing home AAA system to authenticate subscribers, reuse subscriber profiles, and support dynamic assignment of a home address or HA. Those are historical design requirements, not measurements of today’s networks. (RFC 5419, §§1, 5)

RFC 4285 defines two relevant options. The MN–AAA option lets the mobile node authenticate a BU using its shared mobility security association with the home AAA entity. The matching Binding Acknowledgement cannot simply echo that same option: it must use the MN–HA option. RFC 4285 says the HA relies on authentication by an external home AAA server over an authenticated channel, while leaving the details of that HA–AAA interaction outside the document’s scope. The request’s authentication and the HA’s ability to verify a return message therefore depend on related but distinct security state. (RFC 4285, §5.2)

What the RADIUS example does—and cannot prove

RFC 5419 makes the handoff concrete. In its CDMA2000 example, the HA forwards authentication material to a RADIUS server. AAA validates the BU, computes a session key from the MN–AAA shared secret and timestamp, then returns that key to the HA in an Access-Accept using a 3GPP2-defined vendor-specific attribute. The HA associates the key with an MN–HA security association—its example uses SPI 5—and sends a Binding Acknowledgement authenticated with that association. The mobile node computes the corresponding key and can then authenticate later BUs. (RFC 5419, §6.2)

That sequence is valuable because it exposes a control boundary. Subscriber authentication begins with a credential shared between MN and AAA. HA signaling needs a key usable between MN and HA. The example shows how one specified network profile can move keying material between those roles; the attribute it names is defined by 3GPP2, not a universal RADIUS attribute supplied by RFC 4285.

The document then states the limitation directly: RFC 4285 does not specify a mechanism for creating the MN–HA shared key and security association from the MN–AAA association. It relies on deployment-specific mechanisms not standardized by the IETF. RFC 5419 contrasts this with RFC 3957, whose Mobile IPv4 procedure defines a key-generation nonce and derivation steps. This is not a claim that RFC 4285 cannot work. It is a statement about where the interoperability contract stops. A diagram can show a key arriving at an HA; it cannot, by itself, make the derivation, identity binding, key scope, or delivery procedure portable across implementations. (RFC 5419, §7; RFC 3957, §5)

The distinction also keeps the criticism in proportion. RFC 4285’s authentication option is not automatically a broken security design, and a deployment-specific profile may define the missing details. But where those details are local, an operator must know which components agree on them: the mobile node, AAA service, RADIUS attributes, HA, and the process that associates a subscriber with a dynamically selected HA. The standard message format alone cannot certify that whole chain.

The argument changed while it was being archived

RFC 5419’s rationale is unusually candid about its own date. RFC 4877, published in 2007, specified MIPv6 operation with IKEv2 and the revised IPsec architecture. RFC 5419 says IKEv2 improves integration with the AAA backend and that some earlier reasons for RFC 4285 had become redundant. It also notes that RFC 5026 and related work addressed dynamic home-agent and home-address bootstrapping. That chronology matters: a reader should not quote the 2009 document as though it were an undated verdict on the only available architecture. (RFC 4877; RFC 5026; RFC 5419, §§1, 5, 9)

The remaining case in RFC 5419 was narrower. It reported that some devices in the motivating environments might not support IKEv2, that additional exchanges could matter on a constrained radio interface, and that operators wanted to keep subscriber identity and service assignment within their AAA model. Those are statements made by the 2009 authors about the deployments they were discussing. They do not tell us how many devices support a protocol now, whether those networks remain in service, or which option an operator should choose today.

Nor is the authentication-option path free of tradeoffs. RFC 5419 lists limits that include route optimization needing other protection, no algorithm negotiation in the option, reliance on synchronized timestamps for replay protection, and privacy concerns when a long-term Network Access Identifier is visible. The document also says the MN–AAA association itself is established out of band. These points do not invalidate the approach; they define conditions a deployment profile must address. (RFC 5419, §7)

Read the paper trail at the right level

There are three different kinds of evidence here. RFC 4285 specifies option formats and processing requirements. RFC 5419 preserves the design rationale and gives a historically situated RADIUS example. RFC 3957 offers a concrete Mobile IPv4 key-derivation comparison, while RFC 4877 describes an IKEv2/IPsec alternative. None of those documents proves which implementation shipped in a particular network or which profile is running now.

That boundary matters to architecture reviews. An operator considering the RFC 4285 path should ask where the shared secret originates, how the session key is tied to the subscriber and selected HA, what RADIUS attribute carries it, how both ends agree on lifetime and replay state, and what happens when authorization succeeds but the HA cannot install the expected association. If those answers live in a vendor profile, the profile is part of the security design and must be versioned, tested and migrated as such.

If IKEv2 supplies the needed association, its device support and AAA integration must be demonstrated for the actual fleet rather than inferred from RFC publication.

The lasting lesson in RFC 5419 is not that one authentication option won. It is that a central subscriber decision and a per-HA cryptographic relationship are separate pieces of infrastructure. An operator can connect them with a standard exchange, an explicitly profiled extension, or a different key-management protocol. What the operator cannot safely do is treat the word “authenticated” as evidence that the key reached the right endpoint.

Sources