RFC 2977
Mobile IP Authentication, Authorization, and Accounting Requirements
Hiii bestie 🎀 okay so this is RFC 2977, and the title is Mobile IP Authentication, Authorization, and Accounting Requirements 🦋
Network Working Group, category Informational 💅 It's dated October 2000 and it was written by S. Glass (Sun Microsystems), T. Hiller (Lucent Technologies), S. Jacobs (GTE Laboratories), and C. Perkins (Nokia Research Center) 👑 There's no Obsoletes or Updates line in the title block, so it doesn't replace or change any other RFC.
Status of this Memo ✨
This memo gives information to the Internet community 🌸 It does not set any kind of Internet standard, and anyone can distribute it freely, with no limits 💜
Copyright Notice 🧚
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🌈
Okay so the Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently figuring out the requirements for Authentication, Authorization, and Accounting 🫶 This doc lists what an AAA service has to support in order to help out with Mobile IP services. It's giving "here's the checklist" energy 💅
1. Introduction 🦋
Clients get Internet service by negotiating a point of attachment to a "home domain" 🏠 that's usually an ISP or some other organization where service requests get made and fulfilled 😭 With mobile devices getting more popular, people need to be able to attach to any domain that's convenient for wherever they are right now 🍓 So a client needs access to resources from an administrative domain that's not their home domain, and that's called a "foreign domain" 🌍
The need for service from a foreign domain usually calls for Authorization in lots of models, and that leads straight to Authentication, and of course Accounting 💀 That's where the "AAA" comes from. People argue about which of these leads to the others or comes from the others, but everyone agrees the three AAA functions are super interdependent 🫶
An agent in a foreign domain gets asked to give a mobile user access to a resource 🧚 It's pretty likely to request or require the client to provide credentials that can be authenticated before access is allowed ✨ The resource could be as simple as a conduit to the Internet, or as complex as access to specific private resources inside the foreign domain 🔥 Credentials can be exchanged in lots of different ways, but all of those are outside the scope of this document 🙈 Once the user is authenticated, they may be authorized to access services inside the foreign domain 👑 After that, an accounting of the actual resources can be put together 📚
Mobile IP is a technology that lets a network node (the "mobile node") move from its "home" network to other networks, either inside the same administrative domain or into different administrative domains 🦋 Moving between domains that need AAA services created an immediate need to design and specify AAA protocols 😭 Once those AAA protocols and infrastructure exist, they'll give people the economic incentive for a wide-ranging deployment of Mobile IP 💖 This document is going to identify, describe, and discuss the functional and performance requirements that Mobile IP puts on AAA protocols 🔥
The formal description of Mobile IP can be found in [13,12,14,17].
In this document, we've tried to show the requirements in a progressive way 🌸 First we show the basic AAA model for Mobile IP, and then we work out requirements in this order:
- requirements based on the general model
- requirements based on providing IP service for mobile nodes
- requirements derived from specific Mobile IP protocol needs
After that, we look at some related AAA models and talk about the requirements that come from those models 🧚
2. Terminology 📚
This document uses the following terms a lot, on top of the ones defined in RFC 2002 [13] 💅
- Accounting 💜 The act of collecting information on resource usage for trend analysis, auditing, billing, or cost allocation.
- Administrative Domain 🏰 An intranet, or a collection of networks, computers, and databases under a common administration. Computer entities operating in a common administration may be assumed to share administratively created security associations.
- Attendant 🎀 A node designed to provide the service interface between a client and the local domain.
- Authentication 🔐 The act of verifying a claimed identity, in the form of a pre-existing label from a mutually known name space, as the originator of a message (message authentication) or as the end-point of a channel (entity authentication).
- Authorization 🗝️ The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential.
- Billing 🧾 The act of preparing an invoice.
- Broker 🤝 An intermediary agent, trusted by two other AAA servers, able to obtain and provide security services from those AAA servers. For instance, a broker may obtain and provide authorizations, or assurances that credentials are valid.
- Client 🦋 A node wishing to obtain service from an attendant within an administrative domain.
- Foreign Domain 🌏 An administrative domain, visited by a Mobile IP client, and containing the AAA infrastructure needed to carry out the necessary operations enabling Mobile IP registrations. From the point of view of the foreign agent, the foreign domain is the local domain.
- Inter-domain Accounting 🌉 Inter-domain accounting is the collection of information on resource usage of an entity within an administrative domain, for use within another administrative domain. In inter-domain accounting, accounting packets and session records will typically cross administrative boundaries.
- Intra-domain Accounting 🏡 Intra-domain accounting is the collection of information on resource within an administrative domain, for use within that domain. In intra-domain accounting, accounting packets and session records typically do not cross administrative boundaries.
- Local Domain 📍 An administrative domain containing the AAA infrastructure of immediate interest to a Mobile IP client when it is away from home.
- Real-time Accounting ⏱️ Real-time accounting involves processing information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk.
- Session record 📝 A session record is a summary of a user's resource consumption over the entire session. Accounting gateways that create the session record may do so by processing interim accounting events.
Heads up 🙈 The key words in this document are interpreted as described in [4]. The list is: "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT".
3. Basic Model ✨
okay so this section is where the RFC sketches the basic model for how AAA servers should work, and it's the part the Mobile IP working group was really vibing with 🫶. the big idea is that a client from one administrative domain (the home domain) often needs stuff from another one (the foreign domain). there's an agent over there called the "attendant" that handles the client's request, and it's gonna ask the client for credentials it can check before letting them in. those credentials are usually assigned by and only understood by the home domain, and they can be used to set up secure channels with the mobile node 🔐
here's the picture 🦋
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C |- -|- -| A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| |
+--------------+Figure 1: AAA Servers in Home and Local Domains
the attendant usually doesn't have direct access to the data it needs, so it has to check with an authority (typically in the same foreign domain) to get proof the client has legit credentials 💅 since the attendant and the local authority are in the same admin domain, they're expected to have (or be able to set up, for as long as needed) a secure channel for sharing sensitive access info, and keeping it private from the visiting mobile node at the very least 🤫
the local authority (AAAL) might not have enough info stored locally to verify the client's credentials, and that's fine bc unlike the attendant, the AAAL is supposed to be configured with enough info to negotiate credential checks with external authorities 🧚 the local and external authorities should have solid security relationships and access controls set up, so they can work out the authorization that lets the client use whatever resources they asked for, possibly without needing any other AAA agents involved 👑 in lots of typical cases, the authorization just depends on securely authenticating the client's credentials ✨
once the local authority gets the authorization and tells the attendant the negotiation went well, the attendant can finally give the client the resources 🎀
there can be lots of attendants for each AAAL, and lots of clients from lots of different home domains 🌈 each home domain has its own AAAH that can check credentials from clients it administers 🏠
the security model is kinda implied by the figure above, and it's super important to nail down exactly which security associations it assumes 🙈
first, it's natural to assume the client has a security association with the AAAH, since that's basically what it means to belong to the home domain 💜
second, the model in figure 1 makes it clear that AAAL and AAAH have to share a security association. otherwise they couldn't trust each other's authentication results, authorizations, or even the accounting data passed between them 😭 the RFC says this kind of bilateral relationship is not scalable in the end, so the AAA framework MUST provide more scalable mechanisms, which get covered in section 6 ✨
finally, the attendant can naturally share a security association with the AAAL. this is necessary bc the attendant has to know it's allowed to hand out local resources to the client 🍓
for a real-life example, RADIUS [16] is used today to let mobile computer clients get on the Internet through a local ISP 🌸 the ISP wants to make sure the mobile client can pay for the connection. once the client gives credentials (like identification, unique data, and an unforgeable signature), the ISP checks with the client's home authority to verify the signature and make sure the client will actually pay. the NAS can play the attendant role, and the local and home authorities can be RADIUS servers 💖 also, credentials that got authorization at one attendant SHOULD be unusable in any future negotiations at that same attendant or any other one 🔥
from the description and example above, we get a few requirements:
- each local attendant has to have a security relationship with the local AAA server (AAAL)
- the local authority has to share, or dynamically set up, security relationships with external authorities that can check client credentials
- the attendant has to keep state for pending client requests while the local authority contacts the right external authority
- since the mobile node might not start its network connectivity from inside its home domain, it MUST be able to provide complete, yet unforgeable, credentials without ever having been in touch with its home domain 🫠
- since the mobile node's credentials have to stay unforgeable, intervening nodes (like the attendant, the local authority (AAAL), or any other intermediate nodes) MUST NOT be able to learn any secret information that would let them rebuild and reuse the credentials 🔐
from that last requirement, we get the reason the client has to share, or dynamically set up, a security relationship with the external authority in the Home Domain 🥹 otherwise, given the implied network topology, it's technically infeasible for the client to make unforgeable signatures that the AAAH can check. figure 2 shows the natural security associations from this model. the RFC also notes that, per section 6, AAAL and AAAH can agree to bring in a third party between them to help arbitrate secure transactions in a more scalable way 🧚♀️
+------+ +------+
| | | |
| AAAL +--------------+ AAAH |
| | | |
+---+--+ +--+---+
| |
| |
+---+--+ +--+---+
C = client | | | |
A = attendant | A | | C |
AAAL = local authority | | | |
AAAH = home authority +------+ +------+Figure 2: Security Associations
on top of the requirements above, the RFC adds more that come from real experience with today's roaming protocols 🌷
- there are scenarios where one attendant has to handle requests from lots of clients at the same time 🫧
- the attendant MUST protect against replay attacks 🚨
- the attendant equipment should be as cheap as possible, since it's getting copied as many times as possible so it can serve as many clients as possible in the foreign domain 💸
- attendants SHOULD be configured to get authorization from a trusted local AAA server (AAAL) for any Quality of Service requirements the client asks for ⭐
nodes in two separate admin domains (like AAAH and AAAL) often need extra steps to verify who they're talking to, or to keep the data in their communication private 🕵️♀️ those considerations lead to important security requirements, like the ones mentioned above for security between servers. but the RFC says the exact choice of security associations between AAA servers is out of scope for this document 🙅♀️ those choices probably won't depend on any specific features of the general model in figure 1 either. the security associations needed between Mobile IP entities, though, are super central to designing a good AAA infrastructure for Mobile IP 🦋 the general model is generally compatible with what Mobile IP needs, but some basic changes are needed in the Mobile IP security model, which section 5 goes into 💜
last thing: recent discussion in the mobile-ip working group showed the attendant MUST be able to end service to the client based on a policy decision from either the AAAH or AAAL server 🛑✨
3.1. AAA Protocol Roaming Requirements
okay so this is where the roaming requirements come in 🌸 these come from real problems people hit while running existing roaming RADIUS networks 👀 the AAA protocol MUST satisfy them so providers can offer a robust service 💅 TR45.6 came up with this list while working with the Mobile IP working group 🦋
- Support a reliable AAA transport mechanism. ✨
- there must be an effective hop-by-hop retransmission and failover mechanism so that reliability does not solely depend on end-to-end retransmission 💖
- this transport mechanism will be able indicate to an AAA application that a message was delivered to the next peer AAA application or that a time out occurred 🫶
- retransmission is controlled by the reliable AAA transport mechanism, and not by lower layer protocols such as TCP 🔥
- even if the AAA message is to be forwarded, or the message's options or semantics do not conform with the AAA protocol, the transport mechanism will acknowledge that the peer received the AAA message 🎀
- acknowledgements SHOULD be allowed to be piggybacked in AAA messages 🌈
- AAA responses have to be delivered in a timely fashion so that Mobile IP does not timeout and retransmit ⏰
- Transport a digital certificate in an AAA message, in order to minimize the number of round trips associated with AAA transactions. Note: this requirement applies to AAA applications and not mobile stations. The certificates could be used by foreign and home agents to establish an IPSec security association to secure the mobile node's tunneled data. In this case, the AAA infrastructure could assist by obtaining the revocation status of such a certificate (either by performing online checks or otherwise validating the certificate) so that home and foreign agents could avoid a costly online certificate status check. 🧚
- Provide message integrity and identity authentication on a hop-by-hop (AAA node) basis. 🍓
- Support replay protection and optional non-repudiation capabilities for all authorization and accounting messages. The AAA protocol must provide the capability for accounting messages to be matched with prior authorization messages. 💜
- Support accounting via both bilateral arrangements and via broker AAA servers providing accounting clearinghouse and reconciliation between serving and home networks. There is an explicit agreement that if the private network or home ISP authenticates the mobile station requesting service, then the private network or home ISP network also agrees to reconcile charges with the home service provider or broker. Real time accounting must be supported. Timestamps must be included in all accounting packets. 👑
4. Requirements related to basic IP connectivity ✨
okay so the requirements in the last section are about how the functional units relate to each other, and they don't care what the underlying network addressing looks like 🌸 but lots of nodes (mobile or just portable) are programmed to grab some IP-specific resources during startup, right when they try to get onto the Internet 💅
so we add these extra requirements on the AAA services so those clients can be happy 🦋
- Either AAA server MUST be able to obtain, or to coordinate the allocation of, a suitable IP address for the customer, upon request by the customer. 💖
- AAA servers MUST be able to identify the client by some means other than its IP address. 🫶
policy in the home domain may dictate that the home agent instead of the AAAH manages the allocation of an IP address for the mobile node. AAA servers MUST be able to coordinate the allocation of an IP address for the mobile node at least in this way. 🔥
AAA servers today identify clients by using the Network Access Identifier (NAI) [1]. a mobile node can identify itself by including the NAI along with the Mobile IP Registration Request [6] 🎀 the NAI is of the form "user@realm"; it is unique and well suited for use in the AAA model illustrated in figure 1. using a NAI (e.g., "user@realm") allows AAAL to easily determine the home domain (e.g., "realm") for the client 🌈 and both the AAAL and the AAAH can use the NAI to keep records indexed by the client's specific identity 🧚
5. AAA for Mobile IP ✨
okay so Mobile IP clients need some extra special features from the AAA services 💖, on top of the basic AAA stuff and whatever IP connectivity needs. To picture the general model for Mobile IP, the mobile node (MN) is the client in figure 1, and the attendant is the foreign agent (FA). If there's no foreign agent around, like an IPv4 mobile node with a co-located care of address or an IPv6 mobile node, the attendant job goes to the address allocation entity instead, e.g., a DHCP server. That attendant stuff is outside this doc 🙈. The home agent matters a lot for Mobile IP, but during the initial registration it's allowed to play a role that's subordinate to the AAAH 🫶. We tweak the general model for Mobile IP (check out figure 3). After the initial registration, the mobile node can keep using Mobile IP in the foreign domain without the AAA servers getting involved again, so the initial registration will probably take longer than the later ones 😭.
To shrink that extra overhead, we need to cut down the time the AAA servers spend talking to each other 🏃♀️. A big chunk of that latency is the trip across the wide-area Internet that probably separates the AAAL and the AAAH. This is a strong reason to integrate the AAA functions themselves, and to integrate AAA with the initial Mobile IP registration too 🔥. To cut down the number of messages crossing the network for the initial registration of a Mobile Node, the AAA functions in the visited network (AAAL) and the home network (AAAH) need to interface with the foreign agent and the home agent to handle the registration message. Latency drops when initial registration is handled together with AAA and the mobile IP mobility agents. Subsequent registrations, though, are handled according to RFC 2002 [13]. Another latency trick for accounting is exchanging small records 🦋.
Since attendants can provide lots of different sub-services to mobile clients, there MUST be extensible accounting formats 💅. That way the specific services being provided can be identified, and accounting still works if more services show up in the future 🌈.
The AAA home domain and the HA home domain of the mobile node don't have to be in the same administrative domain 👑. This can happen if the home address comes from one domain, like an ISP the user uses at home, while authorization and accounting come from a different, specialized domain, like a credit card company 💳. The foreign agent only sends the mobile node's authentication info to the AAAL, which talks to the AAAH. Once the mobile node is successfully authorized, the foreign agent can carry on with the Mobile IP registration procedure ✨. If access to the AAA functionality and the Mobile IP protocol happen one after the other, that adds more delay 😬. Subsequent registrations are handled according to RFC 2002 [13], with no further interaction with the AAA. Whether to combine or separate the Mobile IP protocol data from the AAA messages is ultimately a policy decision 🧚. Separating them can only be done successfully if the IP address of the mobile node's home agent is given to the foreign agent doing the attendant function 🔑.
All needed AAA and Mobile IP functions SHOULD be processed during a single Internet traversal ✈️. This MUST be done without making the AAA servers process protocol messages sent to Mobile IP agents. The AAA servers MUST identify the Mobile IP agents and security associations needed to process the Mobile IP registration, pass the necessary registration data to those Mobile IP agents, and stay uninvolved in the routing and authentication steps specific to Mobile IP registration 🙅.
For Mobile IP, the AAAL and AAAH servers have these extra general jobs:
- enable [re]authentication for Mobile IP registration
- authorize the mobile node (once its identity has been established) to use at least the set of resources for minimal Mobile IP functionality, plus potentially other services the mobile node asked for
- initiate accounting for service utilization
- use AAA protocol extensions specifically for including Mobile IP registration messages as part of the initial registration sequence to be handled by the AAA servers
These tasks, plus the more specific ones coming up later in this section, are handled best and fastest by the AAA servers shown in figure 1, because the tasks often happen together and the processing needs access to the same data at the same time 🎀.
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | | +------+ |
| | | | | | | |
| | AAAL | | | | AAAH | |
| | +-------------------+ | |
| +---+--+ | | +--+---+ |
| | | | | |
| | | | | |
+------+ | +---+--+ | | +--+---+ |
| | | | | | | | | |
| MN +- -|- -+ FA + -- -- -- -- - + HA | |
| | | | | | | | | |
+------+ | +------+ | | +------+ |
| | | |
+--------------+ +----------------------+Figure 3: AAA Servers with Mobile IP agents
In the model in figure 1, the initial AAA transactions are handled without needing the home agent, but Mobile IP requires every registration to be handled between the home agent (HA) and the foreign agent (FA), as shown by the sparse dashed (lower) line in figure 3 🦋. So during the initial registration, something has to happen that lets the home agent and foreign agent handle later Mobile IP registrations. After the initial registration, the AAAH and AAAL in figure 3 aren't needed anymore, and later Mobile IP registrations just follow the lower control path between the foreign agent and the home agent 🌸.
Any Mobile IP data that the FA sends through the AAAL to the AAAH MUST be treated as opaque by the AAA servers 🔒. Authorization data the AAA servers need MUST be delivered to them by the foreign agent, built from the data supplied by the mobile node. The foreign agent becomes a translation agent between the Mobile IP registration protocol and AAA 🌉.
As mentioned in section 3, nodes in two separate administrative domains often have to take extra steps to guarantee their security and privacy, as well as the security and privacy of the data they're exchanging 🔐. Today, these security measures can use several different algorithms. Some rely on a public-key infrastructure [8], and others rely on distributing symmetric keys to the communicating nodes [9]. AAA servers SHOULD be able to verify credentials using either style in their interactions with Mobile IP entities 💜.
In order to enable subsequent registrations, the AAA servers MUST be able to perform some key distribution during the initial Mobile IP registration process from any particular administrative domain 🗝️.
This key distribution MUST be able to provide the following security functions:
- identify or create a security association between MN and home agent (HA); this is required for the MN to produce the [re]authentication data for the MN--HA authentication extension, which is mandatory on Mobile IP registrations.
- identify or create a security association between mobile node and foreign agent, for use with subsequent registrations at the same foreign agent, so that the foreign agent can continue to obtain assurance that the same mobile node has requested the continued authorization for Mobile IP services.
- identify or create a security association between home agent and foreign agent, for use with subsequent registrations at the same foreign agent, so that the foreign agent can continue to obtain assurance that the same home agent has continued the authorization for Mobile IP services for the mobile node.
- participate in the distribution of the security association (and Security Parameter Index, or SPI) to the Mobile IP entities
- The AAA server MUST also be able to validate certificates provided by the mobile node and provide reliable indication to the foreign agent.
- The AAAL SHOULD accept an indication from the foreign agent about the acceptable lifetime for its security associations with the mobile node and/or the mobile node's home agent. This lifetime for those security associations SHOULD be an integer multiple of the registration lifetime offered by the foreign agent to the mobile node. This MAY allow for Mobile IP reauthentication to take place without the need for reauthentication to take place on the AAA level, thereby shortening the time required for mobile node reregistration.
- The AAA servers SHOULD be able to condition their acceptance of a Mobile IP registration authorization depending upon whether the registration requires broadcast or multicast service to the mobile node tunneled through the foreign agent.
- In addition, reverse tunneling may also be a necessary requirement for mobile node connectivity. Therefore, AAA servers SHOULD also be able to condition their acceptance of Mobile IP registration authorization depending upon whether the registration requires reverse tunneling support to the home domain through the foreign agent.
The lifetime of any security associations distributed by the AAA server for use with Mobile IP SHOULD be long enough to avoid too-frequent initiation of the AAA key distribution, since each invocation of this process is likely to cause lengthy delays between [re]registrations [5]. Registration delays in Mobile IP cause dropped packets and noticeable disruptions in service 😭. Note that any key distributed by AAAH to the foreign agent and home agent MAY be used to initiate Internet Key Exchange (IKE) [7].
Note further that the mobile node and home agent may well have a security association established that does not depend upon any action by the AAAH 💫.
5.1. Mobile IP with Dynamic IP Addresses 🦋
okay so, remember from section 4 how lots of people want their mobile nodes identified by their NAI, and they want a dynamically allocated home address to use in the foreign domain? 💖 These people honestly don't care how their computer does Mobile IP under the hood. They might not even know their home agent exists, or have any security association except the one between them and the AAAH (see figure 2). So the Mobile IP registration data has to ride along inside the AAA messages 📨. Also, the AAA home domain and the HA home domain have to be part of the same administrative domain 🫶.
Mobile IP needs the home address given to the mobile node to be on the same subnet as the Home Agent serving it 🤓. So for home addresses to actually be useful, the home AAA (AAAH) SHOULD be able to pick a home agent for the newly allocated home address 🔥. A lot of the time the mobile node already knows its home agent's address, even if it doesn't have a home address yet. That means the home AAA (AAAH) MUST be able to coordinate handing out a home address with whichever home agent the mobile node might be pointing at 💅.
Allocating a home address and a home agent for the mobile is a huge simplification for the client's setup 😭. Right now, in the Proposed Standard Mobile IP specification [13], a mobile node has to be configured with a home address, the address of a home agent, and a security association with that home agent. With these AAA features, the mobile node only needs its NAI and a secure shared secret for use by the AAAH 🌸. Its home address, its home agent's address, the security association with that home agent, and even the identity (DNS name or IP address) of the AAAH can all be figured out dynamically during the initial Mobile IP registration with the mobility agent in the foreign domain (aka a foreign agent with AAA interface features) ✨. Still, the mobile node may choose to include the MN-HA security extension as well as AAA credentials, and the proposed Mobile IP and AAA server model MUST work when both are present 🎀.
Why does all this work? The NAI encodes the client's identity and the name of the client's home domain 🧚. This follows existing industry practice for how NAIs are used today (see section 4). So the home domain name is available for the local AAA (AAAL) to find the home AAA serving that client's home domain 🗺️. In the general model, the AAAL would also have to identify the right security association for use with that AAAH. Section 6 talks about a way to reduce how many security associations have to be maintained between pairs of AAA servers, like the AAAL and AAAH we just described 💜.
5.2. Firewalls and AAA 🔥
Mobile IP has had some deployment headaches with firewall traversal, see for instance [11] 😩. Since the firewall and AAA server can be part of the same administrative domain, we propose that the AAA server SHOULD be able to issue control messages and keys to the firewall at the boundary of its administrative domain. Those messages configure the firewall to let Mobile IP registration and data traffic from the mobile node through 🛡️✨.
5.3. Mobile IP with Local Home Agents 🏠
+-------------------------+ +--------------+
| +------+ +------+ | | +------+ |
| | | | | | | | | |
| | HA +----+ AAAL | | | | AAAH | |
| | | | +-------------------+ | |
| +-+----+ +---+--+ | | +------+ |
| | | | | Home Domain |
| | +- - - - - + | +--------------+
+------+ | +-+--+-+ |
| | | | | |
| MN +------+ FA | |
| | | | | Local Domain |
+------+ | +------+ |
+-------------------------+
Figure 4: Home Agent Allocated by AAALIn some Mobile IP models, mobile nodes boot up on subnets that are technically foreign, but the services they need are local. So talking to the home subnet as if they were sitting on home turf isn't necessary 🌍. As long as the mobile node can get an address routable from within the current domain (public or private), it can use Mobile IP to roam around that domain. It calls the subnet where it booted its temporary home 🏡. This address will likely be dynamically allocated when the mobile node asks for it.
In these situations, the client might be happy to use a dynamically allocated IP address and doesn't care where the home network is (geographically or topologically) 🤷♀️. The local AAA server (AAAL) may be able to offer this extra allocation service to the client. Then the home agent lives in the local domain, which will likely mean smaller delays for new Mobile IP registrations ⚡.
In figure 4, the AAAL has received a request from the mobile node to allocate a home agent in the local domain. The new home agent gets keys from the AAAL so future Mobile IP registrations work 🔑. From the picture, it's clear this setup avoids the firewall problems at domain boundaries we briefly covered in section 5.2 🙌. On the other hand, this configuration makes it hard for the mobile node to receive data from communication partners in its home administrative domain 😬. Note that in this model, the mobile node's home address is tied to the foreign domain for routing purposes. So any dynamic DNS update that associates the mobile node's home FQDN (Fully Qualified Domain Name [10]) with its new IP address will require putting a foreign IP address into the home DNS server database 🧐.
5.4. Mobile IP with Local Payments 💸
Since the AAAL is expected to be able to allocate a local home agent on demand, we can simplify things even more ✨. If the AAAL can handle any necessary authorization locally (for example, if the client pays with cash or a credit card), then there's no need for an AAA protocol or infrastructure to talk to the AAAH 🙅♀️. The resulting simple setup is shown in figure 5.
In this simplified model, the role of the AAAH is taken over by either a national government (for cash payments), a card authorization service (if payment is by credit card), or some other authority acceptable to all parties 🏛️. Then the AAAL expects those external authorities to guarantee the value of the client's payment credentials (cash or credit) 💳. There are likely to be other cases where clients get access to local resources, or to the Internet, without any charges at all 🎁. Those setups might show up in airports and other common areas where business clients tend to hang out ✈️.
+-------------------------+
| +------+ +------+ |
| | | | | |
| | HA +----+ AAAL | |
| | | | | |
| +--+---+ +----+-+ |
| | | |
| +- - - - - + | |
+------+ | +-+--+-+ |
| | | | | |
| MN +- -|- - - - - - - + FA | |
| | | Local Domain | | |
+------+ | +------+ |
+-------------------------+
Figure 5: Local Payment for Local Mobile IP servicesThe service provider might get enough reward from client goodwill, or from ads shown on Internet portals that clients use 📣. In situations like this, the AAAL SHOULD still allocate a home agent, appropriate keys, and the mobile node's home address 🎯.
5.5. Fast Handover 🏃♀️💨
Mobile IP networks have frequent movement from one coverage area to another, so the handoff latency has to be kept as low as possible 🚀. For one way to do this with Binding Updates, check out the Route Optimization document [15] 📖. When the mobile node enters a new visited subnet, it would be great for it to provide the previous foreign agent's NAI 🙏. The new FA can use that info to either contact the previous FA to get the KDC session key information, or try to retrieve the keys from the AAAL. If the AAAL can't provide the keying information it needs, the request has to go to the mobile node's AAAH to get new keying information 🔑. After the initial authorization, further authorizations SHOULD be done locally within the Local Domain 🏘️.
When an MN moves into a new foreign subnet because of a handover and is now served by a different FA, the AAAL in this domain may contact the AAAL in the domain the MN was just handed off from. It can do this to verify the MN's authenticity and/or to get the session keys 🕵️♀️. The new serving AAAL may figure out the address of the AAAL in the previously visited domain from the previous FA NAI information the MN supplied 🧩.
6. Broker Model 🦋
okay so Figure 1 shows a setup where the local and the home authority have to share trust 🫶. depending on the security model, this can cause a quadratic growth in the number of trust relationships as the number of AAA authorities (AAAL and AAAH) goes up 😭. the roamops working group [3] flagged this as a problem, and any AAA proposal MUST solve this problem. brokers fix a lot of the scalability mess that comes with needing a direct business/roaming relationship between every pair of administrative domains 💅. so for networks to stay scalable across highly diverse service provider networks with lots of domains (many service providers and large numbers of private networks), multiple layers of brokers MUST be supported for both of the broker models described ✨.
Integrity or privacy between the home and serving domains can be handled either with hop-by-hop security associations or with end-to-end security associations set up with help from the broker infrastructure 🔐. a broker can act as a proxy between two administrative domains that each have a security association with the broker, relaying AAA messages back and forth securely 🎀.
Or a broker can help two domains set up a security association even when they don't have a direct association with each other, so the messages skip the broker when they travel between the domains 🦋. this works by having the broker relay a shared secret key to both domains that want to talk securely, and then those domains use the keys the broker supplied to set up their security association 🔑.
Say AAAB takes responsibility for paying the serving domain on behalf of the home domain. then the serving domain is assured of getting paid for the services it offers 💸. still, the redirection broker will usually need a copy of the authorization messages from the home domain and the accounting messages from the serving domain, so it can decide whether it's willing to take responsibility for the services being authorized and used 👀. if the broker doesn't accept that responsibility for any reason, it must be able to terminate service to a mobile node in the serving network 🚫. when multiple brokers are involved, most situations need every broker to get those copies too, and that can be an extra burden on foreign agents and AAALs 😮💨.
This mechanism can cut down latency for messages moving between the domains after the broker is done with its part 🏃♀️. but there can be many more messages overall because of all the extra copies of authorization and accounting messages sent to the brokers 📬. there can also be extra latency for initial network access, especially when a new security association has to be created between AAAL and AAAH (for example, because of ISAKMP) 🥲. those delays can really matter for latency-critical applications ⏱️.
Local Domain Home Domain
+--------------+ +----------------------+
| +------+ | +------+ | +------+ |
| | | | | | | | | |
| | AAAL +-------+ AAAB +--------+ AAAH | |
| | | | | | | | | |
| +------+ | +------+ | +------+ |
| | | | |
| | | +----------------------+
+------+ | +---+--+ |
| | | | | | C = client
| C +- -|- -+ A | | A = attendant
| | | | | | AAAL = local authority
+------+ | +------+ | AAAH = home authority
| | AAAB = broker authority
+--------------+
Figure 6: AAA Servers Using a BrokerThe AAAB in Figure 6 is the broker's authority server 🏰. the broker acts as a settlement agent and gives many service providers and enterprises a security layer and one central point of contact 🤝.
AAAB lets the local and home domains cooperate without each network needing a direct business or security relationship with every other network 🙌. so brokers give you the scalability you need to manage trust between otherwise independent network domains 🌸. using a broker doesn't stop you from managing separate trust relationships between domains, but it does give you another option 💜. just like with AAAH and AAAL (see section 5), data specific to Mobile IP control messages MUST NOT be processed by the AAAB 🙅♀️. any credentials or accounting data that AAAB has to process must be present in AAA message units, not pulled out of Mobile IP protocol extensions 📦.
The following requirements come mostly from [2], which talks about brokers in the specific case of authorization for roaming dial-up users 📞.
- allowing management of trust with external domains by way of brokered AAA.
- accounting reliability. Accounting data that traverses the Internet may suffer substantial packet loss. Since accounting packets may traverse one or more intermediate authorization points (e.g., brokers), retransmission is needed from intermediate points to avoid long end-to-end delays.
- End to End security. The Local Domain and Home Domain must be able to verify signatures within the message, even though the message is passed through an intermediate authority server.
- Since the AAAH in the home domain MAY be sending sensitive information, such as registration keys, the broker MUST be able to pass encrypted data between the AAA servers.
The need for End-to-End security comes from the following attacks, which were identified when brokered operation uses RADIUS [16] (see [2] for more information on the individual attacks) 😱:
- Message editing
- Attribute editing
- Theft of shared secrets
- Theft and modification of accounting data
- Replay attacks
- Connection hijacking
- Fraudulent accounting
these are seriously serious problems 🚨, and they cannot be allowed to persist in any acceptable AAA protocol and infrastructure 💀.
7. Security Considerations 🔐
okay this part is SO important 😭. this is a requirements document for AAA based on Mobile IP, and since AAA is all about security, most of this document covers the security considerations AAA MUST handle on behalf of Mobile IP 🛡️. as with any security proposal, adding more entities that talk to each other using security protocols creates new administrative requirements for keeping the right security associations between those entities 🗂️. the cute part is that for the AAA services proposed here, these administrative requirements feel totally natural, and the Internet already knows them well from experience with dial-up network access 📞✨.
8. IPv6 Considerations 🧚
the big difference between Mobile IP for IPv4 and Mobile IPv6 is that IPv6 has no foreign agent 🙈. so the attendant function has to live somewhere else. the logical places for it are either the local router (for stateless address autoconfiguration) or the nearest DHCPv6 server (for stateful address autoconfiguration) 🏠. with the latter, the DHCPv6 server and the AAALv6 might end up being super close, but we believe the protocol functions should still be kept separate 💜.
the MN-NAI would be just as useful for identifying the mobile node to the AAALv6 as it is in the earlier sections of this document 🪪.
9. Acknowledgements 🫶
thank you to Gopal Dommety and Basavaraj Patil for taking part in the Mobile IP subcommittee of the aaa-wg, which was in charge of formulating the requirements in this document 🙌. thanks to N. Asokan for perceptive comments on the mobile-ip mailing list 💌. some of the text in this document came from a draft co-authored by Pat Calhoun 📝. Patrik Flykt suggested text about letting AAA home domain functions be separated from the domain that manages the home address of the mobile computer 💡.
the requirements in section 5.5 and section 3.1 came from a draft submitted by members of the TIA's TR45.6 Working Group 🌈. we want to shout out the authors of that draft: Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety, Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman, Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric Jaques, Ed Campbell, and Yingchun Xu 👑🙏.
References 📚
[1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[2] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[3] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, December 1998.
4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Ramon Caceres and Liviu Iftode. Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments. IEEE Journal on Selected Areas in Communications, 13(5):850--857, June 1995.
[6] Calhoun, P. and C. Perkins, "Mobile IP Network Address Identifier Extension, RFC 2794, March 2000.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[9] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[10] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[11] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998.
[12] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[13] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[14] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[15] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[16] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[17] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, February 1998.
Addresses 💖
okay bestie, the working group can be reached through its current chairs 🧚 and here's where to find them:
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-6709 EMail: Basavaraj.Patil@nokia.com
Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA Phone: +1 847-632-3148 EMail: QA3445@email.mot.com
Questions about this memo can be directed to: 🎀
Pat R. Calhoun Network and Security Center Sun Microsystems Laboratories 15 Network Circle Menlo Park, California 94025 USA Phone: +1 650-786-7733 Fax: +1 650-786-6445 EMail: pcalhoun@eng.sun.com
Gopal Dommety IOS Network Protocols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1-408-525-1404 Fax: +1 408-526-4952 EMail: gdommety@cisco.com
Steven M. Glass Sun Microsystems 1 Network Drive Burlington, MA 01803 USA Phone: +1-781-442-0504 EMail: steven.glass@sun.com
Stuart Jacobs Secure Systems Department GTE Laboratories 40 Sylvan Road Waltham, MA 02451-1128 USA Phone: +1 781-466-3076 Fax: +1 781-466-2838 EMail: sjacobs@gte.com
Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566 USA Phone: +1 630 979 7673 Fax: +1 630 713 3663 EMail: tomhiller@lucent.com
Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA Phone: +1 630 713 9359 Fax: +1 630 713 4982 EMail: mccap@lucent.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Basavaraj.Patil@nokia.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 Fax: +1 650 625-2502 EMail: charliep@iprg.nokia.com
Full Copyright Statement 🔥
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc2977 2000-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms