RFC 4004
Diameter Mobile IPv4 Application
RFC 4004: Diameter Mobile IPv4 Application 🎀
Okay bestie, this one is RFC 4004, and it's all about Diameter Mobile IPv4 Application 💖 It came out of the Network Working Group in August 2005 and is a Standards Track document. The authors are P. Calhoun (Cisco Systems, Inc.), T. Johansson (Bytemobile Inc), C. Perkins (Nokia Research Center), T. Hiller (Ed.), and P. McCann (Lucent Technologies). The header doesn't list anything it obsoletes or updates, so there's no drama there ✨
Status of This Memo
Okay so this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🗣️ If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🌸
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
So this document describes a Diameter application that lets a Diameter server authenticate, authorize, and collect accounting info for Mobile IPv4 services given to a mobile node 🔐 Paired with the Inter-Realm capability of the base protocol, it means mobile nodes can get service from foreign service providers. Totally iconic 🦋 Diameter Accounting messages are what the foreign and home agents use to send usage info over to the Diameter servers 📊
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Entities and Relationships. . . . . . . . . . . . . . . . 4
1.2. Mobility Security Associations. . . . . . . . . . . . . . 4
1.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Structure of the Document . . . . . . . . . . . . . . . . 7
2. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Scenarios and Message Flows . . . . . . . . . . . . . . . . . . 7
3.1. Inter-Realm Mobile IPv4 . . . . . . . . . . . . . . . . . 8
3.2. Allocation of Home Agent in Foreign Network . . . . . . .13
3.3. Co-located Mobile Node. . . . . . . . . . . . . . . . . .16
3.4. Key Distribution. . . . . . . . . . . . . . . . . . . . .18
4. Diameter Protocol Considerations. . . . . . . . . . . . . . . .20
4.1. Diameter Session Management . . . . . . . . . . . . . . .20
5. Command-Code Values . . . . . . . . . . . . . . . . . . . . . .23
5.1. AA-Mobile-Node-Request. . . . . . . . . . . . . . . . . .23
5.2. AA-Mobile-Node-Answer . . . . . . . . . . . . . . . . . .25
5.3. Home-Agent-MIP-Request. . . . . . . . . . . . . . . . . .26
5.4. Home-Agent-MIP-Answer . . . . . . . . . . . . . . . . . .27
6. Result-Code AVP Values. . . . . . . . . . . . . . . . . . . . .27
6.1. Transient Failures. . . . . . . . . . . . . . . . . . . .28
6.2. Permanent Failures. . . . . . . . . . . . . . . . . . . .28
7. Mandatory AVPs. . . . . . . . . . . . . . . . . . . . . . . . .28
7.1. MIP-Reg-Request AVP . . . . . . . . . . . . . . . . . . .29
7.2. MIP-Reg-Reply AVP . . . . . . . . . . . . . . . . . . . .29
7.3. MIP-Mobile-Node-Address AVP . . . . . . . . . . . . . . .30
7.4. MIP-Home-Agent-Address AVP. . . . . . . . . . . . . . . .30
7.5. MIP-Feature-Vector AVP. . . . . . . . . . . . . . . . . .30
7.6. MIP-MN-AAA-Auth AVP . . . . . . . . . . . . . . . . . . .32
7.7. MIP-FA-Challenge AVP. . . . . . . . . . . . . . . . . . .33
7.8. MIP-Filter-Rule AVP . . . . . . . . . . . . . . . . . . .33
7.9. MIP-Candidate-Home-Agent-Host . . . . . . . . . . . . . .33
7.10. MIP-Originating-Foreign-AAA AVP . . . . . . . . . . . . .33
7.11. MIP-Home-Agent-Host AVP . . . . . . . . . . . . . . . . .33
8. Key Distribution . . . . . . . . . . . . . . . . . . . . . . .34
8.1. Authorization Lifetime vs. MIP Key Lifetime. . . . . . . .34
8.2. Nonce vs. Session Key. . . . . . . . . . . . . . . . . . .35
8.3. Distributing the Mobile-Home Session Key . . . . . . . . .35
8.4. Distributing the Mobile-Foreign Session Key. . . . . . . .36
8.5. Distributing the Foreign-Home Session Key. . . . . . . . .37
9. Key Distribution AVPs . . . . . . . . . . . . . . . . . . . . .38
9.1. MIP-FA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.2. MIP-FA-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .39
9.3. MIP-HA-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.4. MIP-HA-to-MN-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.5. MIP-MN-to-FA-MSA AVP. . . . . . . . . . . . . . . . . . .40
9.6. MIP-MN-to-HA-MSA AVP. . . . . . . . . . . . . . . . . . .41
9.7. MIP-Session-Key AVP . . . . . . . . . . . . . . . . . . .41
9.8. MIP-Algorithm-Type AVP. . . . . . . . . . . . . . . . . .41
9.9. MIP-Replay-Mode AVP . . . . . . . . . . . . . . . . . . .42
9.10. MIP-FA-to-MN-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.11. MIP-FA-to-HA-SPI AVP. . . . . . . . . . . . . . . . . . .42
9.12. MIP-Nonce AVP. . . . . . . . . . . . . . . . . . .. . . .42
9.13. MIP-MSA-Lifetime AVP . . . . . . . . . . . . . .. . . .42
9.14. MIP-HA-to-FA-SPI AVP . . . . . . . . . . . . . .. . . .43
10. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . . . .43
10.1. Accounting-Input-Octets AVP . . . . . . . . . . . . . . .43
10.2. Accounting-Output-Octets AVP. . . . . . . . . . . . . . .43
10.3. Acct-Session-Time AVP . . . . . . . . . . . . . . . . . .43
10.4. Accounting-Input-Packets AVP. . . . . . . . . . . . . . .43
10.5. Accounting-Output-Packets AVP . . . . . . . . . . . . . .43
10.6. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . .44
11. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . .44
11.1. Mobile IP Command AVP Table . . . . . . . . . . . . . . .44
11.2. Accounting AVP Table. . . . . . . . . . . . . . . . . . .46
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .46
12.1. Command Codes . . . . . . . . . . . . . . . . . . . . . .46
12.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . .46
12.3. Result-Code AVP Values. . . . . . . . . . . . . . . . . .46
12.4. MIP-Feature-Vector AVP Values . . . . . . . . . . . . . .47
12.5. MIP-Algorithm-Type AVP Values . . . . . . . . . . . . . .47
12.6. MIP-Replay-Mode AVP Values. . . . . . . . . . . . . . . .47
12.7. Application Identifier . . . . . . . . . . . . . . . . .47
13. Security Considerations . . . . . . . . . . . . . . . . . . . .47
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . .49
14.1. Normative References. . . . . . . . . . . . . . . . . . .49
14.2. Informative References. . . . . . . . . . . . . . . . . .50
15. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .51
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .51
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .531. Introduction ✨
Okay so Mobile IPv4 [MOBILEIP] lets a Mobile Node (MN) switch its point of attachment to the Internet while keeping its fixed home address 🧳 Packets aimed at that home address get grabbed by a Home Agent (HA), wrapped up in a tunnel, and forwarded to the MN wherever it's currently hanging out 🚇
Optionally, a Foreign Agent (FA) can be set up at that point of attachment. It can be the tunnel endpoint and can also handle access control for the visited network link. Here's the tea: the FA has to authenticate each MN that might attach to it, whether the MN is from the same administrative domain or a different one 🙅♀️ It also has to verify that the MN is authorized to attach and use resources in the foreign domain. And the FA must pass info to the home administrative domain about the resources the MN used while it was in the foreign domain 📊 Iconic accountability energy 💅
The Authentication, Authorization, and Accounting (AAA) requirements for Mobile IPv4 are explained in detail in other documents [MIPREQ, CDMA2000]. This document is the Diameter application that meets those requirements 🎯 It's not applicable to the Mobile IPv6 protocol, so don't try it there 🙈
Message formats (e.g., as in section 5.1) are written as lists of Attribute-Value Pairs (AVPs) using the syntax from RFC 2234 [ABNF]. That includes the "*" symbol, which means zero or more occurrences of an AVP 🧩
Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS] 📖
1.1. Entities and Relationships
Okay so the Diameter Mobile IPv4 Application supports the HA and FA in giving Mobile IPv4 service to MNs 🫶 Both the HA and FA act as Diameter clients. The MNs only interact with the HA and FA using Mobile IPv4, so they do not implement Diameter. Main character energy for the HA and FA, background vibes for the MNs 🎀
The FA, when present, is always assumed to exist in the visited administrative domain. The HA may be allocated to the MN statically or dynamically in the home administrative domain, or it may be allocated dynamically to the MN in a visited administrative domain 🌍 The home domain has a home AAA server (AAAH), and the visited domain has a foreign AAA server (AAAF). When the MN is "at home" (present on its home network), the AAAH and AAAF may be the same server 🏠✨
1.2. Mobility Security Associations
okay bestie, so the base Mobile IPv4 protocol [MOBILEIP] assumes there's a Mobility Security Association (MSA) between the MN and HA, called the MN-HA MSA 🔐. The MN-HA MSA authenticates the Mobile IP Registration Request that the MN sends to the HA, using a keyed hash-style algorithm 💅. Authenticating Registration Requests matters a LOT because they tell the HA where the MN's current Care-of-Address is, and that's where tunneled packets from the home network get sent 🦋
Without authentication, malicious attackers would be able to redirect packets to anywhere on the Internet. 💀
So what's inside an MSA? There are three things:
- a Security Parameters Index (SPI, a 32-bit number) that's used to refer to the MSA 🎀
- an algorithm that's used to compute keyed hashes over messages 🧮
- a shared secret key 🤫
To authenticate a message, the sender tacks on a Mobile IP Authentication Extension. It contains the SPI and the result of running the keyed hash over the entire previous contents of the message ✨. The recipient then looks up the MSA using the SPI, re-computes the keyed hash, and checks that the result matches the contents of the Authentication Extension it got. Super clean 😭
The base Mobile IPv4 protocol also supports an optional MSA between the MN and FA, the MN-FA MSA 🌸. If it's available, the FA uses it to authenticate each Registration Request passing through it on the way to the HA. It isn't critical to the base protocol, but it's useful when the FA needs to know a Registration Request is authentic, like when it's generating accounting records for a session 📊. The MN-FA MSA may also be useful in future work related to handoff optimization 🦋
Mobile IPv4 also supports an optional MSA between the FA and HA, called the FA-HA MSA 🍓. This one is useful for authenticating messages between the FA and HA, like when the HA wants to tell the FA that it has revoked a Mobile IP registration 🙅♀️
Configuring MSAs that involve FAs is way harder than setting up the one between the MN and HA 😩. That's because the MN and HA are often in the same administrative domain, and the MN keeps the same HA for long periods of time. The MN, on the other hand, is likely to meet lots of FAs over time and may often end up in foreign administrative domains 🌍
The base Mobile IPv4 protocol assumes that MNs are identified by their static home IP addresses and that all MSAs are statically preconfigured 🗿. The Diameter Mobile IPv4 application, together with extensions [MIPNAI, MIPCHAL, MIPKEYS, AAANAI] to the base Mobile IPv4 protocol, lets an MN get dynamically assigned a home address and/or home agent when it attaches to the Internet 🪄. This set of specs also supports dynamic configuration of the MN-HA, MN-FA, and FA-HA MSAs. That's a big deal for deployments where the MN can attach to a visited network without having any pre-established relationship with it 💜
Initially, the MN is assumed to have a long-term AAA security association only with the AAAH 🔑. This security association is indexed by the MN's NAI and, just like the MSAs, comprises an agreement on a SPI, an algorithm, and a shared secret key. When the MN enters a visited network, it requests service from some FA by sending a Mobile IPv4 Registration Request. The FA then contacts an AAAF in its own administrative domain to authenticate and authorize the request for service 🛂
The AAAF and AAAH may establish a Diameter session directly with each other, such as via a Diameter Redirect, or they may pass messages via a network of Diameter proxies 🌐. When the AAAF and AAAH route messages to each other through proxies instead of a direct connection, transitive trust is assumed 🫶. MNs can include their Network Access Identifier (NAI) in a Mobile IPv4 Registration Request [MIPNAI], and it serves in place of the home address to identify the MN 🪪. The NAI is used to route Diameter messages toward the correct AAAH. This use of the NAI is consistent with the roaming model defined by the ROAMOPS Working Group [EVALROAM, RFC2607] 🌈
The AAAH can authenticate the Registration Request using the MN-AAA security association [MIPCHAL] 🔍. If authentication succeeds, the AAAH generates and distributes MSAs to the MN, HA, and FA 🎉. For each of the MSA pairs that involve the MN (i.e., MN-HA/HA-MN MSAs and MN-FA/FA-MN MSAs), the AAAH generates a nonce and then hashes it together with the MN-AAA shared key to derive the session key for that MSA pair 🧁. The nonces are sent to the HA, which includes them in the Registration Reply, so the MN can derive the same keys [MIPKEYS] 🗝️. At the same time, the AAAH must distribute the MN-HA/HA-MN MSAs and the FA-HA/HA-FA MSAs to the HA, and must distribute the MN-FA/FA-MN MSAs and the FA-HA/HA-FA MSAs to the FA. These are sent in Diameter AVPs and must be independently secured by using IPSec or TLS between the AAAH and the FA and between the AAAH and the HA 🔒. See section 8 for more information on key derivation and distribution 👀
Here's a fun fact: MSAs in Mobile IP are unidirectional 🙃. For example, the MN-HA MSA (used to protect traffic from the MN to the HA) and the HA-MN MSA (used to protect traffic from the HA to the MN) can use different SPIs, algorithms, and shared secrets. This is true of the base Mobile IP protocol, even though common existing practice during manual configuration of MSAs sets all parameters to the same value in both directions. This document supports the use of different SPIs in each direction. However, it only supports the distribution of a single session key for each pair of MSAs between two nodes. The security implications of this are discussed in section 13 ⚠️. This document sometimes names only one of the two unidirectional MSAs when it's talking about the distribution of the single shared secret and the pair of SPIs for the pair of MSAs between two entities 💅
1.3. Handoff
In addition to supporting the derivation and transport of the MN-HA, MN-FA, and FA-HA MSAs, this application also supports MIPv4 handoff 🏃♀️. When an MN moves from one point of attachment to another, it can keep the same Mobile IPv4 session going by using its existing HA and home address 💖
The MN does this by sending a Mobile IPv4 Registration Request from its new point of attachment 📬. To keep a single set of accounting records for the entire session, handoffs included, the AAAH needs to be able to bind the new registration to the pre-existing session 🧾. To make sure the Mobile IPv4 Registration Request gets routed to the same AAAH, the MN SHOULD include the AAAH NAI [AAANAI] in such re-registrations 🗺️. Also, to help the AAAH route messages to the MN's existing HA, the mobile node SHOULD include the HA NAI [AAANAI] in such re-registrations 🧭. If the mobile node does not support the Mobile IPv4 AAA NAI extension [AAANAI], this functionality is not available 🥲
1.4. Structure of the Document
Here's the map of the rest of the doc 🗺️. Section 2 has the acronym definitions. Section 3 has some examples and message flows showing both the Mobile IPv4 and Diameter messages that happen when a mobile node attaches to the Internet 🎬. Section 4 defines how this application relates to the Diameter Base Protocol. Section 5 defines the new command codes. Section 6 defines the new result codes this application uses. Section 7 defines the set of mandatory Attribute-Value-Pairs (AVPs). Section 8 gives an overview of the key distribution capability, and Section 9 defines the key distribution AVPs. Section 10 defines the accounting AVPs, and section 11 contains a listing of all AVPs and where they occur in Diameter commands 📋. Finally, sections 12 and 13 cover IANA and security considerations, respectively 🫡
2. Acronyms
Here's the glossary, so you can keep up with all the letters 🔤💅
AAAH Authentication, Authorization, and Accounting Home
AAAF Authentication, Authorization, and Accounting Foreign
AMA AA-Mobile-Node-Answer
AMR AA-Mobile-Node-Request
ASR Abort-Session-Request
AVP Attribute Value Pair
CoA Care-of-Address
FA Foreign Agent
FQDN Fully Qualified Domain Name
HA Home Agent
HAA Home-Agent-MIP-Answer
HAR Home-Agent-MIP-Request
MN Mobile Node
MSA Mobility Security Association
NAI Network Access Identifier
RRQ Registration Request
SPI Security Parameters Index
STR Session-Termination-Request3. Scenarios and Message Flows
This section presents four scenarios that show off the Diameter Mobile IPv4 application, and it describes how key distribution works 🎀✨
In this document, the role of the "attendant" [MIPREQ] is performed by either the FA (when it's present in a visited network) or the HA (for co-located mobile nodes that aren't registering via an FA). These terms get used interchangeably in the scenarios that follow 🌷
3.1. Inter-Realm Mobile IPv4 🌍✨
okay so bestie, picture a mobile node 📱 asking a foreign agent for service with a Registration Request. the foreign agent makes an AA-Mobile-Node-Request (AMR) message, which carries the AVPs from section 7. it pulls out the Home Address, Home Agent, Mobile Node NAI, and other important fields from the registration messages so they can go in as Diameter AVPs. then the AMR gets sent to the local Diameter server, the AAA-Foreign (or AAAF) 💅
Visited Realm Home Realm
+-----------+ +-----------+
|example.net| AMR/AMA |example.org|
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +-----------+ communication +-----------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | mn@example.org
+--------+
Figure 1. Inter-realm Mobilityso when the AAAF gets that AMR, it follows the procedures in [DIAMBASE] to decide whether to handle it locally or pass it along to another Diameter server, the AAA-Home (or AAAH) 🏠 in Figure 1, the mobile node (mn@example.org) is asking a foreign provider (example.net) for service, and the request the AAAF receives gets forwarded to example.org's AAAH server. it's giving full relay race 🏃♀️💨
Figure 2 shows the message flows when the foreign agent calls on the AAA infrastructure to get a mobile node authenticated and authorized. the foreign agent doesn't have to bother AAA every single time a Registration Request comes in from the mobile. it only does that when the earlier authorization from the AAAH runs out 🙈 the expiration time gets sent over in the Authorization-Lifetime AVP inside the AA-Mobile-Node-Answer (AMA; see section 5.2) that comes back from the AAAH.
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
Reg-Req&MN-AAA ---->
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
HAR----------->
Session-Id = bar
<----------HAA
Session-Id = bar
<-----------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<-------Reg-Reply
Figure 2. Mobile IPv4/Diameter Message Exchangethe foreign agent (as in Figure 2) MAY provide a challenge 🔐, which gives it direct control over the replay protection in the Mobile IPv4 registration process, as described in [MIPCHAL]. the mobile node includes the Challenge and MN-AAA authentication extension so the AAAH can authorize it. if the authentication data in the MN-AAA extension is invalid, the AAAH sends back the response (AMA) with the Result-Code AVP set to DIAMETER_AUTHENTICATION_REJECTED. big nope 🚫
⚠️ the scenario above means the MN-FA and MN-HA keys are exposed to every Diameter agent along the Diameter route. if that's a concern for you, the cleaner move is to cut out the AAAF and the other Diameter agents, like in Figure 3 🫶
Redirect
FA AAAF Agent AAAH
AMR
---------------->
AMR
---------------->
AMA (Redirect)
<----------------
AMA (Redirect)
<----------------
Setup Security Association
<-------------------------------------------------->
AMR
-------------------------------------------------->
AMA (MN-FA key)
<---------------------------------------------------
Figure 3. Use of a Redirect Server with AMR/AMAin Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC]-based security association directly with the AAAH and runs the AMR/AMA exchange over it. that gives end-to-end security for secret keys that might need to be distributed 🔒✨
Figure 4 shows the AAAH and HA talking to each other with a redirect agent in the middle. when the AAAH and HA are on the same network, the AAAH probably already knows the HA's IP address, so the redirect server wouldn't really be needed. it's still drawn anyway for completeness. the redirect server will most likely show up when the HA is allocated in a foreign network (see section 3.2 for more on HA allocation in foreign networks) 🧚
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Figure 4. Use of a Redirect Server with HAR/HAAsame as Figure 2, the FA in Figure 3 still does the challenge and the mobile still sends the RRQ, etc. those steps just got dropped from Figure 3 to cut the clutter 🧹 the redirect server means the AAAF and any other Diameter agents never see the keys while they're being transported to the FA and HA. also, the message flows in Figures 3 and 4 only cover the initial authentication and key exchange. accounting messages still go through Diameter agents, not the direct connection, unless network policies say otherwise 📊
a mobile node that supports the AAA NAI extension [AAANAI], and has already been authenticated and authorized, MUST always include the assigned home agent in the HA Identity subtype of the AAA NAI extension, and the authorizing Home AAA server in the AAAH Identity subtype of the AAA NAI extension, when re-authenticating 🔁 so if the AMR the FA generates is for a session that was authorized before, it MUST include the Destination-Host AVP, with the identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent-Host AVP with the identity and realm of the assigned HA found in the HA-NAI. but if the mobile node doesn't support the AAA NAI extension, the FA may not have the identity of the AAAH or the identity and realm of the assigned HA. that means without AAA NAI support, the FA may not be able to guarantee the AMR goes to the same AAAH that previously authenticated and authorized the mobile node, because the FA may not know who that AAAH is 😬
if the mobile node was successfully authenticated, the AAAH then figures out which Home Agent to use for the session. first, it checks whether the MN asked for a particular HA by looking at the MIP-Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. the administrative domain that owns the HA can be figured out from the realm portion of the MIP-Home-Agent-Host AVP, or by checking the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP along with the value of the MIP-Originating-Foreign-AAA AVP. if the requested HA belongs to a permitted administrative domain, the AAAH SHOULD use the given HA for the session. otherwise, the AAAH sends back the response (AMA) with the Result-Code AVP set to either DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or DIAMETER_ERROR_HA_NOT_AVAILABLE 🙅♀️
if the MN hasn't asked for any particular HA, then an HA MUST be dynamically allocated 🎀 in this case the MIP-Feature-Vector will have the Home-Agent-Requested flag set. if the Home-Address-Allocatable-Only-in-Home-Realm flag is not set, and the Foreign-Home-Agent-Available flag is set, then the AAAH SHOULD let the foreign realm allocate the HA (see section 3.2), but it MAY allocate one itself in the home realm if local policy says so. if the Home-Address-Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST allocate an HA in the home realm on behalf of the MN. HA allocation can happen in a bunch of ways, including a load-balancing algorithm that keeps the load equal across all home agents ⚖️ the actual algorithm and the method for discovering the home agents are outside the scope of this specification, so that's a vibe for another day 🤷♀️
the AAAH then sends a Home-Agent-MIP-Request (HAR), which carries the Mobile IPv4 Registration Request message data encapsulated in the MIP-Reg-Request AVP, to the assigned or requested Home Agent. if the AAAH doesn't have a direct path to the HA, check Figure 4. the AAAH MAY allocate a home address for the mobile node, and the Home Agent MUST support home address allocation 💜 if the AAAH handles address allocation, it puts the home address in a MIP-Mobile-Node-Address AVP inside the HAR. no MIP-Mobile-Node-Address AVP means the Home Agent knows it has to do the home address allocation itself.
when the HAR arrives, the home agent processes the Diameter message first. then it processes the MIP-Reg-Request AVP and creates the Registration Reply, which gets encapsulated in the MIP-Reg-Reply AVP. while creating that Registration Reply, the Home Agent MUST include the HA NAI and the AAAH NAI, which get built from the Origin-Host AVP and Origin-Realm AVP of the HAR. if a home address is needed, the home agent MUST also assign one and include the address in both the Registration Reply and the MIP-Mobile-Node-Address AVP 🌸
when the HAA comes back, the AAAH creates the AA-Mobile-Node-Answer (AMA) message. it includes the same Acct-Multi-Session-Id that was in the HAA, plus the MIP-Home-Agent-Address and MIP-Mobile-Node-Address AVPs in the AMA message. check Figures 3 and 4 for how the redirect agent keeps the HAA and AMA messages secure in transit 🔐
and finally, see section 4.1 for how the Diameter Mobile IPv4 entities manage sessions and session identifiers 🦋
3.2. Allocation of Home Agent in Foreign Network 🏡
okay so the Diameter Mobile IPv4 app lets a home agent get allocated in a foreign network, as required in [MIPREQ, CDMA2000] 🌸 when a foreign agent spots a mobile node with a home agent address of 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag set to one 💅 and if the home agent address is 255.255.255.255, the FA MUST set Home-Address-Allocatable-Only-in-Home-Realm equal to one. if it's 0.0.0.0, the FA MUST set that same flag equal to zero. bestie, the flag is literally the whole personality of this moment ✨
when the AAAF gets an AMR with Home-Agent-Requested set to one and Home-Address-Allocatable-Only-in-Home-Realm set to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP. it's basically saying "hey AAAH, I'm willing and able to assign a Home Agent for this mobile node" 🦋 when it does that, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA AVP. the candidate AVP holds the identity (a DiameterIdentity, which is an FQDN) of the home agent that would be given to the mobile node, and the originating AVP holds the identity of the AAAF itself. then the AAAF sends the AMR on to the AAAH. the tea ☕ is that, as we talked about above, using Diameter agents between the FA and AAAH would expose the MN-FA key 😭 so if that's not okay with you, a redirect server approach SHOULD be used to send the AMR to the AAAH. that makes the FA send the AMR straight to the AAAH over a security association 🔐
if the mobile node supports the AAA NAI extension [AAANAI] and was already authorized by the AAAH, now has to be re-authenticated, and wants to keep its assigned home agent in the foreign network, the mobile node MUST include the HA NAI and the AAAH NAI in the registration request to the FA. once the FA gets that, it creates the AMR, including the MIP-Home-Agent-Address AVP and the Destination-Host AVP based on the AAAH NAI, and includes the MIP-Home-Agent-Host AVP based on the home agent NAI. if the AAAF authorizes the requested home agent, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP 🎀
now the other case: the mobile node has to be re-authenticated but does NOT support the AAA NAI extension. it sends a registration request without the AAA NAI and the HA NAI, even though it was previously authorized by the AAAH and wants to keep its home agent in the foreign network. the FA creates the AMR, including the MIP-Home-Agent-Address AVP. if the AAAF authorizes the requested home agent, and it knows that the agent is in its own domain, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP 🧚
when the AAAH receives an AMR, it first checks the authentication data from the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and decides whether to authorize the mobile node 🔍 if the AMR says the AAAF has offered to allocate a Home Agent (so Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP), OR the AMR says the AAAF has offered a previously allocated Home Agent (so Home-Agent-In-Foreign-Network is set in the MIP-Feature-Vector AVP), then the AAAH must decide whether its local policy would let the user have or keep a home agent in the foreign network. assuming the mobile node is allowed to do that, the AAAH works out the IP address of the HA from the HA's FQDN using DNS, or learns it from an MIP-Home-Agent-Address AVP in a redirect response to an HAR (that's when the redirect server adds this AVP to the HAA). then it sends an HAR message to the Home Agent, with the Destination-Host AVP set to the value found in the AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP. if DNS is used to find the HA IP address, it is assumed that the HA has a public address and can be resolved by DNS 🌈
security considerations might mean the HAR has to go directly from the AAAH to the HA with no Diameter agents in between 🫣 that requires a security association between the AAAH and HA to be set up, as in Figure 4. if no security association can be established, the AAAH MUST return an AMA with the Result-Code AVP set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.
if Diameter agents are being used (for example, if there's no redirect server), the AAAH sends the HAR to the originating AAAF. in this HAR, the Destination-Host AVP is set to the value found in the AMR's MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP from the AMR gets copied into the HAR 💖
so, the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message. when another AAAF gets the HAR, that new AAAF will send the HAR on to the HA 🦋
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Figure 5. Home Agent Allocated in Visited Realmwhen the AAAF gets an HAA from the Home Agent in the visited realm, it forwards the HAA to the AAAH in the home realm. the AMA is then built and sent to the AAAF and, finally, to the FA. if the Result-Code shows success, the HAA and AMA MUST include the MIP-Home-Agent-Address and MIP-Mobile-Node-Address AVPs ✨
if exposing keys to the Diameter Agents along the way is an unacceptable security risk, then the redirect approach shown in Figures 3 and 4 MUST be used instead 🔐
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<---Challenge----
Reg-Req (Response)->
-------------AMR----------->
------AMR---->
<-----HAR-----
<-----HAR------
------HAA----->
------HAA---->
<-----AMA-----
<------------AMA------------
<---Reg-Reply----
Figure 6. MIP/Diameter Exchange for HA Is Allocated in
Visited Realmif the mobile node moves to another foreign network, it MAY either ask to keep the same Home Agent within the old foreign network, or ask for a new one in the new foreign network 🧚 if the AAAH is willing to provide the requested service, the AAAH will have to provide services for both visited networks, e.g., key refresh 🫶
3.3. Co-located Mobile Node 🌸
if a mobile node registers with the Home Agent as a co-located mobile node, no foreign agent is involved 🙈 so when the Home Agent gets the Registration Request, an AMR message is sent to the local AAAH server, with the Co-Located-Mobile-Node bit set in the MIP-Feature-Vector AVP. the Home Agent also includes the Acct-Multi-Session-Id AVP (see sections 4.1.1 and 4.1.2) in the AMR sent to the AAAH, since the AAAH may find this piece of session-state or log entry information useful 📝
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 7. Co-located Mobile Nodeif the MN-HA-Key-Requested bit was set in the AMR message from the Home Agent, the home agent and mobile node's session keys would be present in the AMA message 🔑
Figure 8 shows a signaling diagram that indicates a secure way to set up the necessary security associations when using redirect servers 💅 the Proxy AAA represents any AAA server or servers that the HA may use, and this applies to the visited or home network 🌈
Local redirect
HA Proxy AAA Agent AAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
Figure 8. Use of Redirect Server for Co-located CoA and AMR/AMA3.4. Key Distribution 🔐
Okay bestie, so the big goal here is scaling wireless data access across different admin domains 🌍, which means we need to keep the number of pre-existing Mobility Security Associations (MSAs) as small as possible. Each Foreign Agent should not be required to have a pre-configured MSA with every Home Agent on the Internet 🙅♀️, and the mobile node should not be required to have a pre-configured MSA (as defined in [MOBILEIP]) with any specific foreign agent either. Plus, when the mobile node asks for a dynamically allocated home agent, it's pretty likely to get the address of one it has no available mobility security association with. Chaos, honestly 💀.
The Diameter Mobile IPv4 application fixes this with built-in key distribution 🗝️✨. After a Mobile Node is authenticated, the authorization phase includes generating session keys and nonces. Specifically, three session keys and two nonces get made 🔑:
K1: The MN-HA Session Key, which will be part of the MSA between the Mobile Node and the Home Agent. It's derived from a nonce generated by AAA. The mobile node gets that nonce in the Registration Reply and makes this key with the same formula AAA uses.K2: The MN-FA Key, which will be part of the MSA between the Mobile Node and the Foreign Agent. It's derived from a nonce generated by AAA. The mobile node gets that nonce in the Registration Reply and makes the MN-FA key with the same formula AAA uses.K3: The FA-HA Key, which will be part of the MSA between the Foreign Agent and the Home Agent.
The same session key is used in both directions between two entities. For example, the Mobile Node and the Foreign Agent use the same session key for the MN-FA and the FA-MN authentication extensions. We check out the security implications of this in section 13 👀. However, the SPIs may be different for the MN-FA and the FA-MN authentication extensions. The SPI for the MN-FA MSA is used on messages sent from the MN to the FA, and the SPI for the FA-MN MSA is used on messages sent from the FA to the MN.
All keys and nonces are generated by the AAAH, even if a Home Agent is dynamically allocated in the foreign network 🏠.
Figure 9 shows the MSAs used for Mobile-IPv4 message integrity, using the keys the DIAMETER server created 🎀.
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9. Mobility Security Associations after Session
Key and Nonce DistributionThe keys for the foreign and home agent get passed along to the mobility agents via the Diameter protocol. If exposing keys to the Diameter Agents along the way is an unacceptable security risk 🚨, then the keys MUST be protected either by IPSec or TLS security associations that exist directly between the HA and AAAH, or the FA and AAAF, as explained above. Not optional, bestie 🫶.
The keys destined for the mobile node MUST also be propagated via the Mobile IPv4 protocol, and therefore MUST follow the mechanisms described in [MIPKEYS] instead. In [MIPKEYS], the mobile node receives a nonce for each key it needs, and the mobile node will use the nonce and the long-term shared secret to create the keys (see section 8) 🧚.
Once the session keys have been established and propagated, the mobility devices can exchange registration information directly, as defined in [MOBILEIP], without needing the Diameter infrastructure. However, the session keys have a lifetime, and after that the Diameter infrastructure MUST be invoked again if new session keys and nonces are to be acquired ⏰.
4. Diameter Protocol Considerations 📜
This section details the relationship between the Diameter Mobile IPv4 application and the Diameter base protocol 💖.
This document specifies Diameter Application-ID 2. Diameter nodes conforming to this specification MAY advertise support by including the value of two (2) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [DIAMBASE]. The value of two (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA commands. The value of two (2) MUST be used as the Application-Id in all ACR/ACA commands, as this application defines new, mandatory AVPs for accounting. The value of zero (0) SHOULD be used as the Application-Id in all STR/STA and ASR/ASA commands, as these are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document 🌸.
Given the nature of Mobile IPv4, re-authentication can only be initiated by a mobile node, and the mobile node doesn't take part in the Diameter message exchanges. So Diameter server initiated re-auth doesn't apply to this application, and RAR/RAA commands MUST NOT be sent for Diameter Mobile IPv4 sessions 🙅♀️.
4.1. Diameter Session Management
The AAAH and AAAF MAY maintain session-state or MAY be session-stateless 🤷♀️. AAA redirect agents and AAA relay agents MUST NOT maintain session-state. The AAAH, AAAF, proxies and relays agents MUST maintain transaction state.
A mobile node's session is identified by its identity in the User-Name AVP, the MIP-Mobile-Node-Address, and the MIP-Home-Agent-Address AVPs. This is necessary so the session state machine, defined in the base protocol [DIAMBASE], can be used without modification for this application 🧩. Now, the MN may talk to more than one FA during its session, so it's important for the Diameter Mobile IPv4 application to tell apart the two pieces of the session (some state at the FA, some state at the HA) and to manage them independently 🎀. The following sub-sections give further details.
4.1.1. Session Identifiers
During creation of the AMR, the FA will choose a session identifier. During creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA. If the AAAH is session-stateful, it MUST send the same session identifier for all HARs initiated on behalf of a given mobile node's session. Otherwise, if the AAAH is session-stateless, it will manufacture a unique session-id for every HAR 🆔.
When the HA is first allocated, it MUST create and include an Acct-Multi-Session-Id AVP in the HAA returned to the AAAH. This identifier will be kept constant for the life of the Mobile IPv4 session, as detailed in the next subsection 💜.
4.1.2. Managing Sessions during Mobile IPv4 Handoffs
Given the nature of Mobile IPv4, a mobile node MAY receive service from many foreign agents over a period of time 🦋. However, the home realm should not view these handoffs as different sessions, as this could affect billing systems 💸. Furthermore, foreign agents usually don't talk to each other, which implies that AAA information cannot be exchanged between these entities.
A handoff registration request from a mobile node will cause the FA to send an AMR to its AAAF. The AMR will include a new session identifier and MAY be sent to a new AAAF (i.e., an AAAF different from the one used by the previous FA). However, the AMR shall be received by the AAAH to which the user is currently registered (possibly via the redirect mechanism depicted in Figure 3) 🗺️.
Because the AAAH may be session-stateless, the resulting HAR received by the HA needs to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node with a new session identifier, and the HA can guarantee that this request is to extend an existing service, then the HA MUST be able to modify its internal session state information to reflect the new session identifier 🔄.
For correlation to occur, accounting records must have some commonality across handoffs. Therefore, the home agent MUST send the same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Acct-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. This Acct-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Acct-Multi-Session-Id in the accounting messages, as depicted in Figure 10 📊.
4.1.3. Diameter Session Termination
A foreign and home agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks. For a Diameter Server to release any resources allocated to a specific mobile node, that server has to receive a Session-Termination-Request (STR) from a mobility agent. The mobility agents MUST issue the Session-Termination-Request (STR) if the Authorization Lifetime has expired and no subsequent MIP registration request has been received ⏳.
The AAAH SHOULD only deallocate all resources after the STR is received from the home agent. This makes sure that a mobile node that moves from one foreign agent to another (for example, during a handover) doesn't cause the Home Diameter Server to free all of the mobile node's resources 🫶. So an STR from a foreign agent frees the session from the foreign agent, but not the session state associated with the home agent (see Figure 10).
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 10. Session Termination and Session IdentifiersWhen deallocating all of the mobile node's resources, the home Diameter server (and the foreign Diameter server in the case of an HA allocated in a foreign network) MUST destroy all session keys that may still be valid 🗑️.
In the event that the AAAF wants to end a session, its Abort-Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA. Similarly, the AAAH SHOULD send its message to the Home Agent 📨.
5. Command-Code Values 🧾
This section defines Command-Code [DIAMBASE] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this specification 👑:
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.45.1. AA-Mobile-Node-Request 💌
okay so the AA-Mobile-Node-Request (AMR) is the message an attendant (aka the Foreign Agent, acting as a Diameter client) sends to an AAAF to ask for authentication and authorization of a mobile node 🫶. It's the one with Command-Code 260 and the 'R' bit set in Command Flags. The foreign agent (or the home agent, if the Mobile Node is co-located) pulls info from the Registration Request to build these AVPs for the AMR:
Home Address (MIP-Mobile-Node-Address AVP)
Home Agent Address (MIP-Home-Agent-Address AVP)
Mobile Node NAI (User-Name AVP [DIAMBASE])
MN-HA Key Request (MIP-Feature-Vector AVP)
MN-FA Key Request (MIP-Feature-Vector AVP)
MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)
Foreign Agent Challenge Extension (MIP-FA-Challenge AVP)
Home Agent NAI (MIP-Home-Agent-Host AVP)
Home AAA server NAI (Destination-Host AVP [DIAMBASE])
Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)Now the rules that keep things honest 👑. If the mobile node's home address is zero, the foreign or home agent MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the home agent address is zero or all ones, the MIP-Home-Agent-Address AVP MUST NOT be present in the AMR.
If a home agent is being used in a visited network, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP of the AMR, which signals that it's willing to assign a Home Agent in the visited realm 🌸.
If the mobile node's home address is all ones, the foreign or home agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.
And if the mobile node includes the home agent NAI and the home AAA server NAI [AAANAI], the foreign agent MUST include the MIP-Home-Agent-Host AVP and the Destination-Host AVP in the AMR 🔥.
Message Format ✨
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]5.2. AA-Mobile-Node-Answer 🎀
The AA-Mobile-Node-Answer (AMA) is the reply, and it's the one that comes back from the AAAH 💜. It has Command-Code 260 too, but this time the 'R' bit is cleared. The User-Name MAY be included in the AMA if it was in the AMR. The Result-Code AVP MAY contain one of the values defined in section 6, on top of the values from [DIAMBASE].
So an AMA with the Result-Code AVP set to DIAMETER_SUCCESS MUST include the MIP-Home-Agent-Address AVP and MUST include the MIP-Mobile-Node-Address AVP. It also includes the MIP-Reg-Reply AVP, but only if the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector AVP. The MIP-Home-Agent-Address AVP tells you which Home Agent got assigned to the mobile node, and the MIP-Mobile-Node-Address AVP tells you which home address was given out ✨.
The AMA MUST contain the MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the AMR and were present in the HAR. And the MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA AVPs MUST be present if the session keys were requested in the AMR and the Co-Located-Mobile-Node bit was set in the MIP-Feature-Vector AVP 🙈.
Message Format ✨
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]5.3. Home-Agent-MIP-Request 🦋
The AAA sends the Home-Agent-MIP-Request (HAR) to the Home Agent 🧚. It's Command-Code 262 with the 'R' bit set. If the Home Agent is going to be assigned in a foreign network, the AAAH issues the HAR and the AAAF forwards it to the HA, as long as no redirect servers are involved. If redirect servers are involved, the HAR goes straight to the HA over a security association 🔐.
Here's the tricky bit. If the HAR doesn't include a MIP-Mobile-Node-Address AVP, the Registration Request has 0.0.0.0 for the home address, and the HAR gets processed successfully, the Home Agent MUST allocate the mobile node's address. On the flip side, if the home agent's local AAA server is the one that allocates the mobile node's home address, then the local AAA server MUST include the assigned address in a MIP-Mobile-Node-Address AVP 💅.
When session keys are requested for use by the mobile node, the AAAH MUST create them and include them in the HAR message. When a FA-HA session key is requested, it gets created and distributed by the AAAH server 🍓.
Message Format ✨
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]5.4. Home-Agent-MIP-Answer 🌈
When the Home Agent gets a Home-Agent-MIP-Request, it replies with the Home-Agent-MIP-Answer (HAA) 💖. That's Command-Code 262 with the 'R' bit cleared, and it goes back to its local AAA server. The User-Name MAY be included in the HAA if it was present in the HAR. If the home agent allocated a home address for the mobile node, that address MUST be included in the MIP-Mobile-Node-Address AVP. And the Result-Code AVP MAY contain one of the values defined in section 6 instead of the values defined in [DIAMBASE] 🫶.
Message Format ✨
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]6. Result-Code AVP Values 👑
okay this section is where the new Result-Code [DIAMBASE] values live, and every Diameter implementation that conforms to this specification MUST support them 💅✨.
6.1. Transient Failures 🦋
Transient failures are the "not right now, maybe later" errors 🥺. They tell a peer that the request couldn't be satisfied when it arrived, but that it may be able to satisfy the request in the future.
DIAMETER_ERROR_MIP_REPLY_FAILURE(4005): the home agent uses this when processing of the Registration Request has failed 💀.DIAMETER_ERROR_HA_NOT_AVAILABLE(4006): this tells the foreign agent that the requested Home Agent can't be assigned to the mobile node right now. The foreign agent MUST return a Mobile IPv4 Registration Reply to the mobile node with an appropriate error code 🌸.DIAMETER_ERROR_BAD_KEY(4007): the home agent uses this to tell the local Diameter server that the key it generated is invalid 🙈.DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED(4008): a mobility agent uses this to tell the home Diameter server that the requested packet filter Rules can't be supported 🔥.
6.2. Permanent Failures
Okay so permanent failures are the errors that tell the peer the request just didn't work, and it SHOULD NOT be attempted again. No retry era here 💀 There are two:
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024: the AAAF uses this to tell the AAAH that allocating a home agent in the foreign domain isn't permitted right now 🙅♀️DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025: the AAAF or AAAH uses this to tell the peer that the requested Mobile IPv4 session keys couldn't be delivered via a security association 🔐
7. Mandatory AVPs 🎀
Bestie, this table is the cheat sheet for every AVP in the Mobile IPv4 application. It covers their AVP Code values, types, flag rules, and whether the AVP MAY be encrypted 🔒 Space was tight, so IPFiltrRule is short for IPFilterRule and DiamIdent is short for DiameterIdentity 🙈
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y |
Foreign-AAA
MIP-Home-Agent- 348 7.11 DiamIdent | M | P | | V | N |
Host7.1. MIP-Reg-Request AVP
The MIP-Reg-Request AVP (AVP Code 320) is an OctetString 📦 It carries the Mobile IPv4 Registration Request [MOBILEIP] that the mobile node sends to the foreign agent.
7.2. MIP-Reg-Reply AVP
The MIP-Reg-Reply AVP (AVP Code 321) is an OctetString too 🧚 It carries the Mobile IPv4 Registration Reply [MOBILEIP] that the home agent sends to the foreign agent.
7.3. MIP-Mobile-Node-Address AVP
The MIP-Mobile-Node-Address AVP (AVP Code 333) is an Address type, and it holds the mobile node's home IP address 🏠
7.4. MIP-Home-Agent-Address AVP
The MIP-Home-Agent-Address AVP (AVP Code 334) is an Address type, and it holds the mobile node's home agent IP address 🦋
7.5. MIP-Feature-Vector AVP
Okay this one is giving flag energy 🚩 The MIP-Feature-Vector AVP (AVP Code 337) is an Unsigned32 type. It gets flag values added by the foreign agent, or by the AAAF in the same administrative domain as the foreign agent. The foreign agent SHOULD include the MIP-Feature-Vector AVP in the AMR message it sends to the AAAF.
Flag values currently defined include the following:
1 Mobile-Node-Home-Address-Requested
2 Home-Address-Allocatable-Only-in-Home-Realm
4 Home-Agent-Requested
8 Foreign-Home-Agent-Available
16 MN-HA-Key-Request
32 MN-FA-Key-Request
64 FA-HA-Key-Request
128 Home-Agent-In-Foreign-Network
256 Co-Located-Mobile-NodeThe flags get set according to these rules, so pay attention 👀
If the mobile node includes a valid home address (i.e., one not equal to 0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign agent sets the Mobile-Node-Home-Address-Requested flag in the MIP-Feature-Vector AVP to zero.
If the mobile node sets the home agent field equal to 255.255.255.255 in its Registration Request, the foreign agent sets both the Home-Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-Realm flag to one in the MIP-Feature-Vector AVP.
If the mobile node sets the home agent field equal to 0.0.0.0 in its Registration Request, the foreign agent sets the Home-Agent-Requested flag to one and zeroes the Home-Address-Allocatable-Only-in-Home-Realm flag in the MIP-Feature-Vector AVP.
Whenever the foreign agent sets either the Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested flag to one, it MUST set the MN-HA-Key-Request flag to one. The MN-HA-Key-Request flag is also set to one if the mobile node includes a "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension, with the subtype set to AAA.
If the mobile node includes a "Generalized MN-FA Key Generation Nonce Request" [MIPKEYS] extension with the AAA subtype (1) in its Registration Request, the foreign agent sets the MN-FA-Key-Request flag to one in the MIP-Feature-Vector AVP.
If the mobile node requests a home agent in the foreign network, either by setting the home address field to all ones or by specifying a home agent in the foreign network, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit to one.
If the AAAF is willing and able to assign a home agent in the foreign network, the AAAF sets the Foreign-Home-Agent-Available flag to one.
If the home agent receives a Registration Request from the mobile node indicating that the MN is acting as a co-located mobile node, the home agent sets the Co-Located-Mobile-Node bit to one.
If the foreign agent's local policy allows it to receive AAA session keys and it does not have any existing FA-HA key with the home agent, the foreign agent MAY set the FA-HA-Key-Request flag.
The foreign agent MUST NOT set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags both to one. No double-dipping on those two 🙅♀️
When the AAAF receives the AMR message, it MUST first verify that the sender was an authorized foreign agent. The AAAF then takes any actions indicated by the settings of the MIP-Feature-Vector AVP flags. The AAAF then MAY set additional flags. Only the AAAF may set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags to one, and this is done according to local administrative policy. When the AAAF has finished setting additional flags according to its local policy, the AAAF transmits the AMR with the possibly modified MIP-Feature-Vector AVP to the AAAH ✨
7.6. MIP-MN-AAA-Auth AVP
The MN-AAA-Auth AVP (AVP Code 322) is a Grouped type. It carries some ancillary data that helps the target AAA server (the one in the [MOBILEIP] and [MIPCHAL] Registration Request authentication flow) process the authentication data more easily 🧠 Its value has the following ABNF grammar:
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]7.6.1. MIP-MN-AAA-SPI AVP
The MIP-MN-AAA-SPI AVP (AVP Code 341) is an Unsigned32 type. It indicates the MSA by which the targeted AAA server (AAAH) should attempt to validate the Authenticator that the mobile node computed over the Registration Request data 🔑
7.6.2. MIP-Auth-Input-Data-Length AVP
The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is an Unsigned32 type. It contains the length, in bytes, of the Registration Request data (the data portion of the MIP-Reg-Request AVP) that should be used as input to the algorithm indicated by the MN-AAA-SPI AVP. This is used to figure out whether the Authenticator Data supplied by the mobile node is valid 🧮
7.6.3. MIP-Authenticator-Length AVP
The MIP-Authenticator-Length AVP (AVP Code 339) is an Unsigned32 type. It contains the length of the authenticator that the targeted AAA server (i.e., AAAH) has to validate 📏
7.6.4. MIP-Authenticator-Offset AVP
The MIP-Authenticator-Offset AVP (AVP Code 340) is an Unsigned32 type. It contains the offset into the Registration Request Data where the authenticator for the targeted AAA server (i.e., AAAH) to validate lives 📍
7.7. MIP-FA-Challenge AVP
The MIP-FA-Challenge AVP (AVP Code 344) is an OctetString type. It contains the challenge the foreign agent advertised to the mobile node 📣 This AVP MUST be present in the AMR if the mobile node used the RADIUS-style MN-AAA computation algorithm [MIPCHAL]. Non-negotiable, bestie 🫶
7.8. MIP-Filter-Rule AVP
The MIP-Filter-Rule AVP (AVP Code 342) is an IPFilterRule type. It provides filter rules that have to be configured on the foreign or home agent for the user 🚧 The AAAH sets the packet filtering rules by adding one or more MIP-Filter-Rule AVPs to the HAR if they're destined for the home agent, and/or to the AMA if they're destined for the foreign agent.
7.9. MIP-Candidate-Home-Agent-Host
The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is a DiameterIdentity type. It contains the identity of a home agent in the foreign network that the AAAF proposes to be dynamically assigned to the mobile node 🌸
7.10. MIP-Originating-Foreign-AAA AVP
The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is a Grouped type. It contains the identity of the AAAF, which issues the AMR to the AAAH 🛫 The MIP-Originating-Foreign-AAA AVP MUST only be used in cases when the home agent is or may be allocated in a foreign domain. If the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
{ Origin-Realm }
{ Origin-Host }
* [ AVP ]7.11. MIP-Home-Agent-Host AVP
The MIP-Home-Agent-Host AVP (AVP Code 348) is a Grouped type. It contains the identity of the assigned Home Agent 🏡 If the MIP-Home-Agent-Host AVP is present in the AMR, the AAAH MUST copy it into the HAR.
MIP-Home-Agent-Host ::= < AVP Header: 348 >
{ Destination-Realm }
{ Destination-Host }
* [ AVP ]8. Key Distribution ✨
okay so bestie, the mobile node and the mobility agents need session keys (the MN-FA, FA-HA, and MN-HA ones 🔑) to make the authentication extensions on MIP registration messages, as spelled out in [MOBILEIP]. If session keys get requested, the AAAH MUST return the keys and nonces once the mobile node is successfully authenticated and authorized 💅
The SPI values work as key identifiers, and every session key gets its own SPI 🦋 Nodes that share a key can have several different SPIs that all point to the same key, which is kinda iconic. The entity that receives an authentication extension (the one verifying it) is the one handing the entity that sends it (the one computing it) the SPI value to use for that computation. Also, the keys here are symmetric, since they get used in both directions, even though the SPIs don't have to be symmetric 🎀
The mobile node sets up SPIs for the FA-MN and HA-MN mobility security associations through the Mobile IPv4 AAA Key Request extensions in [MIPKEYS] 🌸 The home agent sets up SPIs for the MN-HA and FA-HA mobility security associations. The foreign agent picks SPIs for the MN-FA and HA-FA mobility security associations.
Once the session keys and nonces have been handed out, later Mobile IPv4 registrations don't need to bug the AAA infrastructure until the keys expire 🙌 Mobile IPv4 says so, and these registrations MUST include the MN-HA authentication extension. Same deal, subsequent registrations MUST also include the MN-FA authentication extension if the MN-FA session key was generated and distributed by AAA. The same goes for later use of the FA-HA authentication extensions 🫶
8.1. Authorization Lifetime vs. MIP Key Lifetime ⏰
The Diameter Mobile IPv4 application runs on two timers: the Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP 🧚
The Authorization-Lifetime holds the number of seconds before the mobile node has to send a follow-up MIP registration request. Its content lines up with the Lifetime field in the MIP header [MOBILEIP] 💜
The MIP-MSA-Lifetime AVP holds the number of seconds before the session keys meant for the mobility agents and the mobile node expire. A value of zero means infinity (no timeout) ♾️ If it isn't zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP. No cap, that's the rule 💅
8.2. Nonce vs. Session Key 🔐
Like I said in section 3.4, the AAAH makes session keys and sends them to the home agent and foreign agent 📨 It also makes nonces that match those same keys and sends them to the mobile node. When you need to protect the session keys and SPIs from untrusted Diameter agents, you need end-to-end security like TLS or IPSec, which gets rid of every Diameter agent between the FA or HA and the AAAH, as covered above 🛡️
In [MIPKEYS], the mobility security associations get set up through nonces that go to the mobile node over Mobile IPv4. To deliver those nonces, the AAAH must generate a random [RANDOM] value of at least 128 bits [MIPKEYS]. Then the mobile node uses that nonce to derive the MN-HA and MN-FA session keys 🌈
More details on how the MN-HA and MN-FA session keys get created are in [MIPKEYS] 📖
The hashing algorithm the mobile node uses to build the session key has to match the one the AAAH used in its session key generation procedure. So the AAAH tells the mobile node which algorithm was used, alongside the nonce 🍓
The FA-HA and HA-FA session key is shared between the FA and the HA. The AAAH generates a random [RANDOM] value of at least 128 bits to use as this session key 🤝
Check sections 9 for the format of the AVPs that carry the session keys 📦
8.3. Distributing the Mobile-Home Session Key 🏠
If the mobile node doesn't have an MN-HA session key, the AAAH is probably the only trusted entity the mobile node can reach. So the AAAH has to generate the MN-HA session key 🥺
The HA-MN (session) key gets sent to the HA as specified in sections 1.2 and 3.4 🎀 The HA and AAAH set up a security association (IPSec or TLS) and send the key over it. If there's no security association between the AAAH and the home agent and one can't be set up, the AAAH MUST return a Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 😭
The AAAH also has to make sure the key reaches the mobile node. Here's the drama: the AAAH only speaks Diameter messages and AVPs, and the mobile node only speaks Mobile IPv4 messages and extensions [MOBILEIP] 🙈 So the AAAH puts the MN-HA MIP-nonce AVP inside a MIP-MN-to-HA-MSA AVP, which gets added to the HAR (for FA COA style Mobile IPv4) or the AMA (for collocated COA-style Mobile IPv4 messages). It then goes to either a local home agent or a home agent in the visited network 🚀 The mobile node uses the nonce to build the MN-HA session key with the MN-AAA key it shares with the AAAH [MIPKEYS] ✨ The AAAH has to count on the home agent (which also understands Diameter) to turn the nonce into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS] inside the Registration Reply message 🫧 The HA puts the SPIs proposed by the mobile node and the home agent into the "Generalized MN-HA Key Generation Nonce Request" extension. The home agent can format the Reply message and its extensions correctly so they can be delivered to the mobile node 💖 The resulting Registration Reply goes into the HAA's MIP-Reg-Reply AVP.
The AAAH parses the HAA message, turns it into an AMA message holding a MIP-Reg-Reply AVP, and sends that AMA to the foreign agent 💌 The foreign agent uses that AVP to rebuild a Registration Reply message containing the "Generalized MN-HA Key Generation Nonce Reply" extension so it can go to the mobile node 🎀
Quick recap, bestie 📝 The AAAH makes the MN-HA nonce, which goes into the MIP-MN-to-HA-MSA AVP, plus a session key, which goes into the MIP-HA-to-MN-MSA AVP. These AVPs get delivered to the home agent inside HAR or AMA messages. The home agent keeps the session key for its own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a "Generalized MN-HA Key Generation Nonce Reply" extension, which gets tacked onto the Mobile IPv4 Registration Reply message. This Registration Reply MUST also include the HA-MN authentication extension, which is built with the freshly allocated HA-MN session key 🔥 Then the home agent packs the Registration Reply message and its extensions into a MIP-Reg-Reply AVP as part of the HAA message heading back to the AAA server 🌸
The key the MN derives from the MN-HA session nonce is identical to the HA-MN session key given to the HA 👑
8.4. Distributing the Mobile-Foreign Session Key 🌷
The AAAH also makes the MN-FA session nonce (when it's requested) and adds it to the MIP-MN-to-FA-MSA AVP 🧚♀️ That AVP goes into the HAR, and the home agent copies it into a "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS] on the Mobile IPv4 Registration Reply message. The HA also puts the SPIs proposed by the mobile node and foreign agent into the "Generalized MN-FA Key Generation Nonce Request" extension. The AAAH includes the FA-MN session key in the MIP-FA-to-MN-MSA AVP inside the AMA, so the foreign agent can use it to compute the FA-MN authentication extension 💜
The key the MN derives from the MN-FA session nonce is identical to the FA-MN session key given to the FA 🫶
8.5. Distributing the Foreign-Home Session Key 🌈
If the foreign agent asks for an FA-HA session key, it also includes a MIP-HA-to-FA-SPI AVP in the AMR to pass along the SPI the home agent should use for this 🍓 The AAAH generates the FA-HA session key, which is identical to the HA-FA session key, and hands it to both the HA and the FA over their own security associations using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs 🦋 The HA shares the SPI that the FA MUST use in the HAA. It's kinda like how the FA shares the SPI that the HA MUST use in the AMR 💅 Later, the AAAH puts these SPIs into the MIP-FA-HA-MSA and MIP-HA-FA-MSA AVPs, respectively, along with the session key ✨
Check Figures 2, 3, 4, and 6 for the messages involved 📋
Here's a tea moment ☕ If multiple MNs are registered on the same FA and HA pair, multiple mobility security associations would get distributed. But only one is required to protect the Mobile IP control traffic between the FA and HA. Keeping all of them creates an unacceptable level of state (you'd have to store two SPIs and a shared key for each FA-HA mobility security association) 😩 To help scalability, the FA and HA may discard FA-HA mobility security associations before they actually expire. Still, if there's no proper discard policy, Mobile IP messages that are in transit or waiting in transmission queues could fail authentication 🙈
The FA MUST always use the FA-HA security association with the latest expiry time when computing authentication extensions on outgoing messages. The FA MAY discard HA-FA mobility security associations 10 seconds after a new HA-FA mobility security association shows up with a later expiry time 🕰️
The HA SHOULD use the HA-FA mobility security association with the latest expiry time when computing authentication extensions in outgoing messages. However, when the HA gets a new HA-FA mobility security association with a later expiry time, the HA SHOULD wait 4 seconds for the AMA to propagate to the FA before it starts using the new association ⏳ Note that the HA always uses the mobility security association from the HAR when building the Mobile IP Registration Reply in the matching HAA 💌 The HA MAY discard an FA-HA mobility security association once it receives a message authenticated by an FA-HA mobility security association with a later expiry time 🌟
9. Key Distribution AVPs ✨
okay bestie, so Mobile IP has this whole set of mobility security associations shared between the mobile node, foreign agent, and home agent 🦋 There are three of them (MN-HA, MN-FA, and FA-HA), and the AAAH creates them dynamically. We already went over these back in sections 3.4 and 8 💅 And fr, any AAA server running the Diameter Mobile IP Application MUST implement the key distribution AVPs in this document 🔥
The AVP names literally tell you who's involved 👑 The first entity in the name uses that security association to create authentication extensions with the given SPI and key. The second entity uses it to verify the authentication extensions on incoming Mobile IP messages. iykyk 🫶
For example, MIP-MN-to-HA-MSA carries the MN-HA nonce, which the mobile node uses to derive the MN-HA Key, and MIP-HA-to-MN-MSA carries the MN-HA key for the home agent. Now the plot twist: security associations are one-way, but this application only hands out ONE key that both one-way associations between two peers share 🙈 The security considerations of reusing the same key in each direction are in section 13. The SPIs, though, are unique to each one-way association, and they get chosen by whichever peer will receive the Mobile IP messages authenticated with that association ✨
Here's the table of all the Diameter AVPs in the Mobile IP application, with their AVP Code values, types, and flag values 💜
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |9.1. MIP-FA-to-MN-MSA AVP 🎀
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is a Grouped type and holds the FA-MN session key 🌸 It gets sent to the FA in an AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA makes an FA-MN authentication extension using the session key and algorithm, and the MN checks that extension with the same session key and algorithm. The data field has this ABNF grammar:
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]9.2. MIP-FA-to-HA-MSA AVP 🍓
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is a Grouped type and holds the FA-HA session key ✨ It's sent to the FA in an AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates the FA-HA authentication extension with the session key and algorithm, and the HA verifies it with that same key and algorithm. The AVP's data field has this ABNF grammar:
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]9.3. MIP-HA-to-FA-MSA AVP 🧚
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is a Grouped type and holds the Home Agent's session key, the one it shares with the foreign agent 💜 It's sent to the HA in an HAR message. The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA authentication extension with the session key and algorithm, and the FA verifies it using that same session key and algorithm. The AVP's data field has this ABNF grammar:
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]9.4. MIP-HA-to-MN-MSA AVP 🌈
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is a Grouped type and holds the HA-MN session key 🦋 It gets sent to the HA in an HAR for FA COA Mobile IPv4, and in an AMA for collocated COA Mobile IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the HA-MN authentication extension with the session key and algorithm, and the MN verifies it with the same key and algorithm. The AVP's field has this ABNF grammar:
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]9.5. MIP-MN-to-FA-MSA AVP 🫶
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is a Grouped type and holds the MN-FA session nonce, which the mobile node uses to derive the MN-FA session key 🔥 It's sent to the HA in an HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates the MN-FA authentication extension with the session key and algorithm, and the FA verifies it using that same key and algorithm.
The home agent uses this AVP when it builds the Mobile IP "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]9.6. MIP-MN-to-HA-MSA AVP 👑
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is a Grouped type and holds the MN-HA session nonce, which the mobile node uses to derive the MN-HA session key ✨ It's sent to the HA in an HAR message for FA COA Mobile IPv4, and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension with the session key and algorithm, and the HA verifies it using that same session key and algorithm.
The Home Agent uses this AVP when it builds the Mobile IP "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]9.7. MIP-Session-Key AVP 🔑
The MIP-Session-Key AVP (AVP Code 343) is an OctetString type and holds the Session Key for the associated Mobile IPv4 authentication extension 💖 The HAAA picks the session key.
9.8. MIP-Algorithm-Type AVP 🧮
The MIP-Algorithm-Type AVP (AVP Code 345) is an Enumerated type and holds the Algorithm identifier for the associated Mobile IPv4 authentication extension 🌸 The HAAA picks the algorithm type. These are the values defined so far:
2 HMAC-SHA-1 [HMAC]9.9. MIP-Replay-Mode AVP 🔁
The MIP-Replay-Mode AVP (AVP Code 346) is an Enumerated type and holds the replay mode the Home Agent uses to authenticate the mobile node 🍓 The HAAA picks the replay mode.
These values are supported (see [MOBILEIP] for more information):
1 None
2 Timestamps
3 Nonces9.10. MIP-FA-to-MN-SPI AVP 🎀
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is an Unsigned32 type and holds the Security Parameter Index that the FA and MN use to refer to the FA-MN mobility security association 💅 The MN allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP]. 🙈
Heads up: that zero-to-255 range is off limits for this SPI, so don't go picking those numbers 🚫
9.11. MIP-FA-to-HA-SPI AVP 🦋
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is an Unsigned32 type and holds the Security Parameter Index that the FA and HA use to refer to the FA-HA mobility security association ✨ The HA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP]. 💀
9.12. MIP-Nonce AVP 🌙
The MIP-Nonce AVP (AVP Code 335) is an OctetString type and holds the nonce sent to the mobile node for the associated authentication extension 🫧 The mobile node follows the procedures in [MIPKEYS] to generate the session key it uses to authenticate Mobile IPv4 registration messages. The HAAA picks the nonce.
9.13. MIP-MSA-Lifetime AVP ⏳
The MIP-MSA-Lifetime AVP (AVP Code 367) is an Unsigned32 type and shows how long, in seconds, the session key or nonce stays valid 🥹 The associated session key or nonce MUST NOT be used once its lifetime has expired. And if that lifetime runs out while the session it belongs to is still going, then either the session key or nonce MUST be changed, or the Mobile IPv4 session MUST be terminated. No cap, that's a hard rule 😭
9.14. MIP-HA-to-FA-SPI AVP 🌟
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is an Unsigned32 type and holds the Security Parameter Index that the HA and FA use to refer to the HA-FA mobility security association 💜 The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP]. 👑
10. Accounting AVPs 📊
10.1. Accounting-Input-Octets AVP 🧾
The Accounting-Input-Octets AVP (AVP Code 363) is an Unsigned64 type and holds the number of octets in IP packets received from the user 💖 This AVP MUST be included in all Accounting-Request messages, and it MAY also show up in the matching Accounting-Answer messages.
10.2. Accounting-Output-Octets AVP 📤
The Accounting-Output-Octets AVP (AVP Code 364) is an Unsigned64 type and holds the number of octets in IP packets sent to the user 🌈 This AVP MUST be included in all Accounting-Request messages, and it MAY also be present in the corresponding Accounting-Answer messages.
10.3. Acct-Session-Time AVP ⏱️
The Acct-Time AVP (AVP Code 46) is an Unsigned32 type and shows how long the current session has been running, in seconds ⭐ This AVP MUST be included in all Accounting-Request messages, and it MAY also be present in the corresponding Accounting-Answer messages.
10.4. Accounting-Input-Packets AVP 📦
okay so the Accounting-Input-Packets AVP (AVP Code 365) is an Unsigned64 that counts how many IP packets came in from the user 📥 it's giving "keeping receipts." This AVP MUST be included in all Accounting-Request messages, and it MAY also show up in the matching Accounting-Answer messages 💅
10.5. Accounting-Output-Packets AVP 📤
the Accounting-Output-Packets AVP (AVP Code 366) is also an Unsigned64, and it counts the IP packets sent to the user 🫶 same vibe as the input one: it MUST be in every Accounting-Request, and it MAY appear in the Accounting-Answer too ✨
10.6. Event-Timestamp AVP ⏰
the Event-Timestamp (AVP Code 55) is a Time value 🕰️ it MAY go in an Accounting-Request to log when the event happened on the mobility agent. The time is counted in seconds since January 1, 1970, 00:00 UTC, so yes, it's the classic Unix epoch, bestie 🌈
11. AVP Occurrence Tables 📋
the tables below show every AVP defined in this document and where it can show up in Diameter messages 🦋 quick heads up: AVPs that can only live inside a Grouped AVP are NOT in these tables, so don't go looking for them there 🙈
the tables use these symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0 - 1 Zero or one instance of the AVP MAY be present in the
message.
1 One instance of the AVP MUST be present in the message.11.1. Mobile IP Command AVP Table 🧁
this table only covers the Command Codes defined in this specification, so it's a tight little squad 💖
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 |
Auth-Application-Id | 1 | 1 | 1 | 1 |
Auth-Session-State | 0-1 | 0-1 | 1 | 0 |
Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 |
Destination-Host | 0-1 | 0 | 0-1 | 0 |
Destination-Realm | 1 | 0 | 1 | 0 |
Error-Message | 0 | 0-1 | 0 | 0-1 |
Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 |
MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 |
MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 |
MIP-FA-Challenge | 0-1 | 0 | 0 | 0 |
MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 |
MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 |
MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|11.2. Accounting AVP Table 💸
this table shows which AVPs from this document have to be in the Accounting messages, following what [DIAMBASE] defines 🧾
+-------------+
| Command-Code|
|------+------+
Attribute Name | ACR | ACA |
-------------------------------------|------+------+
Accounting-Input-Octets | 1 | 0-1 |
Accounting-Input-Packets | 1 | 0-1 |
Accounting-Output-Octets | 1 | 0-1 |
Accounting-Output-Packets | 1 | 0-1 |
Acct-Multi-Session-Id | 1 | 0-1 |
Acct-Session-Time | 1 | 0-1 |
MIP-Feature-Vector | 1 | 0-1 |
MIP-Home-Agent-Address | 1 | 0-1 |
MIP-Mobile-Node-Address | 1 | 0-1 |
Event-Timestamp | 0-1 | 0 |
-------------------------------------|------+------+12. IANA Considerations 🌸
this section lists the namespaces that were either created in this specification or had their values handed out from namespaces IANA already manages 🎀
12.1. Command Codes 🛸
this specification assigns the values 260 and 262 from the Command Code namespace defined in [DIAMBASE]. Check section 5 for how the namespace is assigned in this specification 💜
12.2. AVP Codes 🔑
this specification assigns the values 318 - 348 and 363 - 367 from the AVP Code namespace defined in [DIAMBASE]. For the assignments in this specification, see sections 7, 9, and 10 🫶
12.3. Result-Code AVP Values 🚦
this specification assigns the values 4005 - 4008 and 5024 - 5025 from the Result-Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. Section 6 has the assignment for this specification 🌈
12.4. MIP-Feature-Vector AVP Values 🧩
there are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that are available for assignment 👀 this document assigns bits 1 - 9, as listed in section 7.5. The remaining bits should only be assigned via Standards Action [IANA] 🔒
12.5. MIP-Algorithm-Type AVP Values 🧮
as defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) defines the value 2. All remaining values, except zero, are available for assignment via Designated Expert [IANA] ✨
12.6. MIP-Replay-Mode AVP Values 🔁
as defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) defines the values 1 - 3. All remaining values, except zero, are available for assignment via Designated Expert [IANA] 💅
12.7. Application Identifier 🪪
this specification uses the value two (2) from the Application Identifier namespace defined in [DIAMBASE]. Section 4 has more info on that 🧚
13. Security Considerations 🔐
okay bestie, this is the part where things get real 😭 This spec is a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm depends on the transforms used within Mobile IPv4, plus [MIPCHAL]. Together with [MIPKEYS], it also defines how the home Diameter server can create and distribute session keys and nonces for authenticating and integrity-protecting Mobile IPv4 registration messages [MOBILEIP]. The key distribution is asymmetric 🦋 because talking to the mobile node happens over the Mobile IPv4 protocol [MIPKEYS, MOBILEIP], whereas talking to the Home Agent and Foreign Agent happens over Diameter. Where untrusted Diameter agents are present, end-to-end security MUST be used. That end-to-end security looks like TLS or IPSec security associations between the AAAH and the FA, and between the AAAH and the HA. These connections get authenticated with public keys and certificates, but the identities in those certificates must be authorized and bound to a particular Mobile IPv4 Diameter session before the AAAH can safely start distributing keys. No skipping this step, no cap 🙅♀️
Quick note: the direct connections get set up because of Diameter redirect messages. For example, in Figure 3, the FA gets a redirect response containing the Redirect-Host AVP of the AAAH. That's the identity that should be matched against the certificate the AAAH shows when the secure connection is established. In this case, the network of Diameter proxies and redirect agents is trusted with the job of returning the correct AAAH identity to the FA 🎀
The AAAH also has to make an authorization decision when the FA sets up the connection. If the AAAH and the redirect server are one and the same, the AAAH may have observed and noted the original AMR message that contained the identity of the FA, so it may authorize a TLS or IPSec connection from that same entity. Otherwise, the AAAH would need to keep a list of all authorized visited domains (roaming partners) and authorize TLS or IPSec connections based on that list. Establishing the connection is only the first step, though, and the AAAH gets another chance to deny service when the AMR message itself arrives 💅 At that point, the AAAH can check the internal AVPs of the AMR to make sure the FA is valid. For example, it can check that the Mobile IP COA is equal to the IP address used as the endpoint of the TLS or IPSec connection. BUT, that kind of policy would stop the FA from using different interfaces for AAA and Mobile IP tunnel packets, and it may not be desirable in every deployment situation 🙈
A similar set of considerations applies to the connection between the AAAH and the HA when those entities are in different administrative domains. This time the roles are flipped, because it's the AAAH that contacts the HA via the HAR. The identity of the candidate HA is given to the AAAH in the AMR, and the AAAH should expect to receive that same identity in the public key certificates during TLS or IPSec negotiation. The HA may authorize individual connections by acting as its own redirect server, or it may maintain a list of trusted roaming partners ✨
Now the session key situation 🌸 This application creates and distributes a single session key for each pair of MSAs between two entities. For example, the same session key is used for the MN-HA MSA and the HA-MN MSA. This is safe from a security standpoint, because the session keys are only used with keyed hash functions to generate authenticator values that protect the integrity of each Mobile IP control message. Mobile IP messages have built-in replay protection using timestamps or nonces [MOBILEIP], and because of how the protocol works, requests are always different bitwise from responses, at least in the message type code. This dodges problems that could show up in other situations, where an attacker could mount a replay or reflection attack if the same key were used (for example) to encrypt otherwise unprotected traffic on more than one connection leg in the network 🕵️♀️
Nonces get sent to the mobile node, and they're used to generate the session keys via the HMAC-SHA-1 one-way function. The nonces and authentication extensions can be seen by anyone with access to a clear-text copy of the Registration Reply. So if the pre-shared key between the mobile node and the home Diameter server didn't have enough entropy, it would be vulnerable to an offline dictionary attack. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits. Strong key, strong life 💪
The session key is determined by the long-term secret and the nonce, so the nonce SHOULD be temporally and globally unique. If the nonce repeated, the session key would repeat too, which is a total disaster 💀 To prevent that, a nonce is strongly recommended to be a random [RANDOM] value of at least 128 bits. The long-term secret between the MN and AAAH MUST be refreshed periodically, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is handled with out-of-band mechanisms, which this document doesn't specify 🧚
Last tea ☕ It is not recommended to set the MIP-MSA-Lifetime AVP value to zero, because keeping session keys around for a long time (with no refresh) makes them more vulnerable.
14. References 📚
14.1. Normative References
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
- [DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000.
- [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [MIPKEYS] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IP", RFC 3957, March 2005.
- [AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.
- [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [TLS] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
- [MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
- [CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001.
- [EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
- [MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
- [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
15. Acknowledgements 🫶
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and Pankaj Patel for their participation in the pre-IETF Document Reading Party. Thanks also to Erik Guttman for his very useful proposed text, and to Fredrik Johansson, Martin Julien, and Bob Kopacz for their very useful contributed text.
The authors would also like to thank the participants of 3GPP2's TSG-X working group for their valuable feedback, and the following people for their contribution in the development of the protocol: Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael Chen, Henry Haverinen, and Johan Johansson. General redirect server text due to Pasi Eronen was borrowed from Diameter-EAP.
Pat Calhoun would like to thank Sun Microsystems, as most of the effort put into this document was done while he was in their employ. 💖
Authors' Addresses 💌
Questions about this memo can be directed to:
Pat Calhoun
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408-853-5269
EMail: pcalhoun@cisco.com
Tony Johansson
Bytemobile, Inc.
2029 Stierlin Court
Mountain View, CA 94043
Phone: +1 650-641-7817
Fax: +1 650-641-7701
EMail: tony.johansson@bytemobile.com
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650-625-2986
Fax: +1 650-625-2502
EMail: Charles.Perkins@nokia.com
Tom Hiller
Lucent Technologies
1960 Lucent Lane
Naperville, IL 60566
USA
Phone: +1 630-979-7673
EMail: tomhiller@lucent.com
Peter J. McCann
Lucent Technologies
1960 Lucent Lane
Naperville, IL 60563
USA
Phone: +1 630-713-9359
Fax: +1 630-713-1921
EMail: mccap@lucent.comFull Copyright Statement 📜
Copyright (C) The Internet Society (2005).
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 ⚖️
Okay bestie, so the IETF is basically saying it is not picking a side on whether any rights apply to the tech in this doc, or how much license you'd even be able to get 🙈 It also isn't claiming it went digging for any of those rights either. Not its job to play referee here 💅 The rules for rights in RFC documents are in BCP 78 and BCP 79 📚
Any IPR disclosures sent to the IETF Secretariat live in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️ You can also find any assurances of licenses that were promised, plus the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec. Lowkey the best place to check before you build something 🔍
And the IETF is literally inviting anyone to speak up 📣 If you know about a copyright, a patent, a patent application, or any other proprietary right that might cover tech you'd need to implement this standard, tell them! Send it to ietf-ipr@ietf.org 💌 Main character energy for helping the community 🌈
Acknowledgement 🫶
Funding for the RFC Editor function is currently coming from the Internet Society 💜 So thank you to them for keeping the lights on for all these docs ✨
📦 where this page comes from
- ietf: rfc4004 2005-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms