RFC 2989

Criteria for Evaluating AAA Protocols for Network Access

📅 published November 2000, from ietf

RFC 2989 💖 Criteria for Evaluating AAA Protocols for Network Access

okay bestie, this is RFC 2989, and it's called Criteria for Evaluating AAA Protocols for Network Access 🎀 It came out in November 2000 and it's marked Informational 📚, which means it's here to inform the Internet community and doesn't set any Internet standard. It's giving a team project, because there are 28 authors from a bunch of companies:

  • B. Aboba, Microsoft
  • P. Calhoun, S. Glass, Sun Microsystems, Inc.
  • T. Hiller, P. McCann, H. Shiino, P. Walsh, Lucent
  • G. Zorn, G. Dommety, Cisco Systems, Inc.
  • C. Perkins, B. Patil, Nokia Telecommunications
  • D. Mitton, S. Manning, Nortel Networks
  • M. Beadles, SmartPipes Inc.
  • X. Chen, Alcatel
  • S. Sivalingham, Ericsson Wireless Communications
  • A. Hameed, Fujitsu
  • M. Munson, GTE Wireless
  • S. Jacobs, GTE Laboratories
  • B. Lim, LG Information & Communications, Ltd.
  • B. Hirschman, Motorola
  • R. Hsu, Qualcomm, Inc.
  • H. Koo, Samsung Telecommunications America, Inc.
  • M. Lipford, Sprint PCS
  • E. Campbell, 3Com Corporation
  • Y. Xu, Watercove Networks
  • S. Baba, Toshiba America Research, Inc.
  • E. Jaques, Vodaphone Airtouch

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

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

Abstract 🦋

This doc is a summary of the Authentication, Authorization, Accounting (AAA) protocol requirements for network access 🫶 To put it together, the authors pulled inputs from documents made by the Network Access Server Requirements Next Generation (NASREQ), Roaming Operations (ROAMOPS), and MOBILEIP working groups, plus TIA 45.6.

It gathers the requirements from those sources and splits them into three piles: authentication, authorization and accounting. If you want the full details, go check the original documents 📖

1. Introduction 💅

So this document is a summary of AAA protocol requirements for network access. The inputs came from the NASREQ [3], ROAMOPS [2], and MOBILEIP [5] working groups, plus TIA 45.6 [4]. It collects the requirements from those sources and separates them into requirements for authentication, authorization and accounting. The details live in the original documents 🧚

1.1. Requirements language

Okay, this part is important 👑 In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be read as described in [1].

These requirements are meant to be used when evaluating AAA protocol submissions. So the requirements language describes the capabilities of those protocols, and the protocol documents will say whether each feature is required, recommended, or optional 🍓 For example, requiring that a protocol support confidentiality is not the same thing as requiring that all protocol traffic be encrypted. Not the same vibe at all 🙈

A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. 💀

If a submission meets every MUST, MUST NOT, SHOULD and SHOULD NOT requirement for its capabilities, it's called "unconditionally compliant" 👑 If it meets all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols, it's called "conditionally compliant." Still valid, just not the full glow-up ✨

1.2. Terminology

Okay, here's the glossary 📚 Bookmark this one, bestie.

  • Accounting: collecting info on resource usage for trend analysis, auditing, billing, or cost allocation.
  • Administrative Domain: an internet, or a collection of networks, computers, and databases under one common administration. Computer entities in the same administration can be assumed to share administratively created security associations.
  • Attendant: a node built to provide the service interface between a client and the local domain.
  • Authentication: verifying a claimed identity, using a pre-existing label from a mutually known name space, as either the originator of a message (message authentication) or the end-point of a channel (entity authentication).
  • Authorization: working out whether a particular right, like access to some resource, can be granted to whoever presents a particular credential.
  • Billing: preparing an invoice 🧾
  • Broker: a Broker is an entity in a different administrative domain from both the home AAA server and the local ISP. It provides services, like facilitating payments between the local ISP and the home administrative entities. There are two types of brokers: proxy and routing 🌸
  • Client: a node that wants to get service from an attendant within an administrative domain.
  • End-to-End: the security model where security information can traverse and still be validated even when an AAA message gets processed by intermediate nodes like proxies, brokers, etc. 🔐
  • Foreign Domain: an administrative domain visited by a Mobile IP client, containing the AAA infrastructure needed to carry out the operations that enable Mobile IP registrations. From the foreign agent's point of view, the foreign domain is the local domain 🌍
  • Home Domain: an administrative domain containing the network whose prefix matches a mobile node's home address, and containing the AAA infrastructure needed to carry out the operations that enable Mobile IP registrations. From the home agent's point of view, the home domain is the local domain 🏡
  • Hop-by-hop: the security model where each direct set of peers in a proxy network shares a security association, and the security information does not traverse an AAA entity 🦋
  • Inter-domain Accounting: collecting info on the resource usage of an entity within one administrative domain, for use within another administrative domain. Accounting packets and session records typically cross administrative boundaries in this case 🚀
  • Intra-domain Accounting: collecting info on resource usage within an administrative domain, for use within that same domain. Accounting packets and session records typically do not cross administrative boundaries here 🏠
  • Local Domain: an administrative domain containing the AAA infrastructure that a Mobile IP client cares about most when it's away from home 🧳
  • Proxy: an AAA proxy is an entity that acts as both a client and a server. When it gets a request from a client, it acts as an AAA server. When that same request needs to be forwarded to another AAA entity, it acts as an AAA client 🔁
  • Local Proxy: an AAA server that meets the definition of a Proxy and sits in the same administrative domain as the network device (e.g., NAS) that issued the AAA request. A local proxy usually enforces local policies before it forwards responses to the network devices, and it's generally used to multiplex AAA messages from a large number of network devices 🧠
  • Network Access Identifier: the Network Access Identifier (NAI) is the userID the client submits during network access authentication. When roaming, the NAI identifies the user and helps route the authentication request. The NAI doesn't have to match the user's e-mail address or the user-ID submitted in an application layer authentication 🪪
  • Routing Broker: an AAA entity that meets the definition of a Broker but is not in the transmission path of AAA messages between the local ISP and the home domain's AAA servers. When a Routing Broker gets a request, it returns information to the AAA requester, including what's needed to contact the Home AAA server directly. Certain organizations providing Routing Broker services MAY also act as a Certificate Authority, so the Routing Broker can return the certificates the local ISP and home AAA servers need to communicate securely 🔒
  • Non-Proxy Broker: sometimes a Routing Broker gets called a Non-Proxy Broker, so now you know 🤓
  • Proxy Broker: an AAA entity that meets the definition of a Broker and acts as a Transparent Proxy, serving as the forwarding agent for all AAA messages between the local ISP and the home domain's AAA servers 🎀
  • Real-time Accounting: processing info on resource usage within a defined time window. The time limits are usually there to cap financial risk ⏱️
  • Roaming Capability: loosely, the ability to use any one of multiple Internet service providers (ISPs) while keeping a formal customer-vendor relationship with just one. Examples where roaming capability might be needed include ISP "confederations" and ISP-provided corporate network access support 🌐
  • Session record: a summary of a user's resource consumption over the entire session. Accounting gateways that create the session record may do it by processing interim accounting events 📝
  • Transparent Proxy: an AAA server that meets the definition of a Proxy but doesn't enforce any local policies. That means it doesn't add, delete or modify attributes, and it doesn't modify information within the messages it forwards 🫧

2. Requirements Summary 🌟

The AAA protocol evaluation criteria for network access are summarized below. For details on the requirements, check the documents referenced in the footnotes 💜

2.1. General requirements 🎀

okay bestie, these are the general requirements, the ones that apply to literally everything AAA does 💅 the table is giving a breakdown of which requirements matter to each of the three groups (NASREQ, ROAMOPS, and Mobile IP) ✨

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  General                  | NASREQ  | ROAMOPS | MOBILE  |
|  Reqts.                   |         |         |   IP    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Scalability             |    M    |   M     |    M    |
|      a                    |   12    |   3     |  30 39  |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Fail-over               |    M    |         |    M    |
|      b                    |   12    |         |   31    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Mutual auth             |    M    |         |    M    |
|   AAA client/server       |   16    |         |   30    |
|      c                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Transmission level      |         |   M     |    S    |
|   security                |         |   6     |  31 39  |
|      d                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Data object              |    M    |   M     |    M    |
|  Confidentiality          |   26    |   6     |   40    |
|      e                    |         |         |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Data object              |    M    |   M     |    M    |
|  Integrity                |   16    |   6     |  31 39  |
|      f                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Certificate transport    |    M    |         |  S/M    |
|      g                    |   42    |         |31,33/46 |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Reliable AAA transport   |    M    |         |    M    |
|  mechanism                |   22    |         |  31 32  |
|      h                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Run Over IPv4           |    M    |   M     |    M    |
|                           |   11    |   1     |   33    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Run Over IPv6           |    M    |         |    S    |
|                           |   11    |   1     |   47    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Support Proxy and        |    M    |         |    M    |
|  Routing Brokers          |   12    |         |  31 39  |
|      i                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Auditability             |    S    |         |         |
|      j                    |   25    |         |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Dual App and Transport  |         |   O     |     M   |
|    Security not required  |         |   6     |    40   |
|      k                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Ability to carry         |    M    |         |    S    |
|  service-specific attr.   |   43    |         |  31 33  |
|      l                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key 🔑

M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT

Clarifications 💖

[a] The AAA protocol needs to handle millions of users and tens of thousands of simultaneous requests ✨ The AAA architecture and protocol MUST be capable of supporting tens of thousands of devices, AAA servers, proxies and brokers 🚀

[b] If a server stops responding, the protocol needs a way to switch service over to another backup or secondary server 🔄

[c] This one is about mutual authentication between the AAA client and server 🤝

[d] The AAA protocol requires authentication, integrity protection and confidentiality at the transmission layer 🔐 This is also called hop-by-hop security, where the security is set up between two communicating peers. All of that security gets removed once a receiving AAA entity processes the AAA message, so it's not giving end-to-end vibes 🙈

[e] The AAA protocol requires confidentiality at the object level, where an object is one or more attributes 💜 Object-level confidentiality means only the target AAA entity the data is ultimately meant for can decrypt it, even if the message passes through intermediate AAA entities (like proxies or brokers) 🫶

[f] The AAA protocol requires authentication and integrity protection at the object level, which is again one or more attributes 🧚 Object-level authentication has to stick around across intermediate AAA entities (like proxies or brokers), so any AAA entity in a proxy chain can verify it. This means data covered by object-level security CANNOT be modified by intermediate servers 🚫

[g] The AAA protocol MUST be capable of transporting certificates 📜 This is meant as an optimization, so you don't have to rely on an out-of-band protocol to go fetch certificates 🎀

[h] This one is about resilience against packet loss, and it includes:

1. Hop-by-hop retransmission and fail-over, so reliability doesn't depend only on single-hop transport retransmission 🔁

2. Control of the retransmission mechanism by the AAA application 🎛️

3. Acknowledgment by the transport that a message was delivered successfully, kept separate from message semantics or syntax evaluation ✅

5. Piggy-backing of acknowledgments in AAA messages 🎒

6. Timely delivery of AAA responses ⏰

[i] In the Mobile IP AAA architecture, brokers can sit in the forwarding path, where they act as transparent proxies (proxy brokers) 🧋 Or brokers can act as certifying authorities outside the forwarding path (routing brokers) 👑

[j] An auditable process is one where you can definitively figure out what actions were performed on AAA packets as they travel from the home AAA server to the network device and back 🕵️‍♀️📋

[k] The AAA protocol MUST allow communication to be secured 🔒 It MUST also allow an underlying security service (like IP Security) to be used. When that latter option is used, the former MUST NOT be required 🌸

[l] The AAA protocol MUST be extensible by third parties (like other IETF Working Groups) so they can define attributes specific to the service being defined 🌈 In other words, the AAA protocol MUST allow groups other than the AAA WG to define standard attributes 👸

2.2. Authentication Requirements 🔐

okay bestie, authentication is where the AAA protocol proves who's who, so let's look at the requirements table 🦋

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
| Authentication            | NASREQ  | ROAMOPS | MOBILE  |
| Reqts.                    |         |         |   IP    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   NAI Support             |    M    |   M     |   S/M   |
|      a                    |    9    |   2     |32,34,39/|
|                           |         |         |   40    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   CHAP Support            |    M    |   M     |         |
|      b                    |   10    |   3     |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   EAP Support            |    M    |   S     |         |
|      c                    |   10    |   3     |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   PAP/Clear-Text Support  |    M    |   B     |         |
|      d                    |   26    |   3     |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Re-authentication       |    M    |         |    S    |
|   on demand               |   17    |         |   33    |
|      e                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Authorization Only      |    M    |         |         |
|   without Authentication  |    9    |         |         |
|      f                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Key
   M = MUST
   S = SHOULD
   O = MAY
   N = MUST NOT
   B = SHOULD NOT

Clarifications

[a] The AAA protocol MUST allow the use of Network Access Identifiers (NAI) [8] to identify users and/or devices.

[b] The AAA protocol MUST allow CHAP [20] authentication information to be transported. This is commonly used by Network Access Servers that request authentication of a PPP user. 💜

[c] The AAA protocol MUST allow for Extensible Authentication Protocol (EAP) [14] payload to be transported. Since some EAP authentication mechanisms require more than one round trip, the AAA protocol must allow for such authentication mechanisms to be used. The actual EAP authentication mechanism negotiated MUST be transparent to the AAA protocol. When EAP is used, authentication typically occurs between the user being authenticated and his/her home AAA server. 🌸

[d] While PAP is deprecated, it is still in widespread use for its original intended purpose, which is support of clear-text passwords. 😭 As a result, an AAA protocol will need to be able to securely transport clear-text passwords. This includes providing for confidentiality of clear-text passwords traveling over the wire, as well as protecting against disclosure of clear-text passwords to proxies in the forwarding path.

[e] The AAA protocol MUST allow for a user to be re-authenticated on-demand. The protocol MUST allow for this event to be triggered by either the user, access device (AAA client), or the home or visited AAA server. 🔥

[f] The AAA protocol MUST NOT require that credentials of the user be provided during authorization. The AAA protocol supports authorization by identification or assertion only. 🙈

2.3. Authorization Requirements 👑

now the authorization side, where the server decides what you're actually allowed to do ✨

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
| Authorization             | NASREQ  | ROAMOPS | MOBILE  |
| Reqts.                    |         |         |   IP    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Static and Dynamic      |         |         |         |
|   IPv4/6 Address Assign.  |    M    |   M     |   M     |
|      a                    |   11    |   5     | 32 36   |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   RADIUS gateway          |    M    |   M     |    M    |
|   capability              |   44    |   3     |    45   |
|      b                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Reject                  |    M    |   M     |   M     |
|   capability              |   12    |   4     |  39     |
|      c                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Precludes layer 2       |    N    |   N     |         |
|   tunneling               |   11    |   5     |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Re-Authorization on      |    M    |         |   S     |
|   demand                  |   18    |         | 30 33   |
|      d                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Support for Access Rules,|    M    |         |         |
|  Restrictions, Filters    | 11, 19  |         |         |
|      e                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  State Reconciliation     |    M    |         |         |
|      f                    |   20    |         |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Unsolicited Disconnect   |    M    |         |         |
|      g                    |   18    |         |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT

Clarifications

[a] The AAA protocol MUST allow a server to provide a static or dynamic address during the authorization phase of a user and/or device. The address assigned MUST be either of type IPv4 or IPv6. If both the client AND the server are aware of a pre-configured address, then it is considered static. Anything else is dynamic. 🌈

[b] This requirement refers to the ability of a new AAA protocol be sufficiently compatible with the large installed base of attributes for existing approaches (RADIUS), such that a server implementation could speak both protocols, or translate between them. 🧚

[c] This requirement refers to the ability of a proxy broker to deny access without forwarding the access request to the AAA server, or to deny access after receiving an access accept from the AAA server. 💅

[d] This requirement refers to the ability of the AAA client or server to trigger re-authorization, or to the ability of the server to send updated authorization information to the device, such as "stop service." Authorization can allow for a time period, then additional authorization can be sought to continue. A server can initially authorize a user to connect and receive services, but later decide the user is no longer allowed use of the service, for example after N minutes. Authorizations can have a time limit. Re-authorization does not necessarily imply re-authentication. ⭐

[e] This requirement refers to the ability to of the protocol to describe access operational limitations and authorization restrictions to usage to the NAS which includes (but is not limited to):

  1. Session expirations and Idle Timeouts
  2. Packet filters
  3. Static routes
  4. QoS parameters

[f] This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling.

The design must provide for recovery from data loss due to a variety of faults, including NAS and AAA server reboots, and NAS/AAA server communication outages, and MUST be independent of the accounting stream. The granularity of the recovery of state information after an outage may be on the order of a fraction of a minute. In order to provide for state recovery, explicit session/resource status and update and disconnect messages will be required.

Because of potential multi-domain issues, only systems that allocate or use a resource should track its state. 🦋

[g] This requirement refers to the ability of the AAA server to request the NAS to disconnect an active session for authorization policy reasons. 🎀

2.4. Accounting Requirements 🧾✨

okay so accounting is basically the group chat's receipts 💅 Here's the comparison table for NASREQ, ROAMOPS, and MOBILE IP, with the letter codes explained underneath.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
| Accounting                | NASREQ  | ROAMOPS | MOBILE  |
| Reqts.                    |         |         |   IP    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Real-time accounting    |    M    |    M    |   M     |
|      a                    |   14    |    7    |  31     |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Mandatory Compact       |         |    M    |         |
|    Encoding               |         |    7    |         |
|      b                    |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Accounting Record       |         |    M    |   M     |
|    Extensibility          |         |    7    |  33     |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Batch Accounting        |    S    |         |         |
|      c                    |   21    |         |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Guaranteed Delivery     |    M    |         |    M    |
|      d                    |   22    |         |   31    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|   Accounting Time Stamps  |    M    |         |    M    |
|      e                    |   23    |         |   40    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Dynamic Accounting       |    M    |         |         |
|      f                    |   48    |         |         |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT

Now the clarifications, which are the juicy bits:

  • [a] This one is kinda loosely defined: it's reporting synchronously with events. Usually the time window is on the order of seconds, not milliseconds ⏱️
  • [b] The AAA protocol's Accounting data format MUST NOT be bloated, imposing a large overhead for one or more accounting data elements. Nobody wants a fat payload 🙅‍♀️
  • [c] This refers to the ability to buffer or store multiple accounting records, then send them together at some later time 📦
  • [d] This is an application layer acknowledgment 💌 It gets sent when the receiving server is willing to take responsibility for the message data.
  • [e] This is about reflecting the time of occurrence of events like log-on, logoff, authentication, authorization and interim accounting. It also implies the ability to provide unambiguous time-stamps 🕰️
  • [f] This refers to accounting for dynamic authentication and authorization. To support this, there can be multiple accounting records for a single session 🎀

2.5. Unique Mobile IP requirements 🛰️

Okay, so on top of everything above, Mobile IP has its own extra requirements. Here's the table:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Encoding of Mobile IP    |         |         |   M     |
|  registration messages    |         |         |   33    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Firewall friendly        |         |         |   M     |
|      a                    |         |         |   35    |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |         |         |         |
|  Allocation of local Home |         |         |   S/M   |
|  agent                    |         |         |  37/41  |
|                           |         |         |         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
  • [a] A firewall friendly protocol is one designed to play nice with a firewall acting as a proxy 🧱 For example, this would let a Home Agent AAA server sitting behind a firewall be reachable from the Internet, so it can provide AAA services to a Mobile IP Foreign Agent 🌐

Here are the notes, kept word for word so you can cross-reference them:

        Notes

        [1] Section 4.2.1 of [2]
        [2] Section 4.2.2 of [2]. Also see [8].
        [3] Section 4.2.3 of [2]. Also see [14].
        [4] Section 4.2.4 of [2].
        [5] Section 4.2.5 of [2].
        [6] Section 4.2.6 of [2].
        [7] Section 4.3 of [2].
        [8] Section 6 of [3].  Also see [6].
        [9] Section 8.2.2.2 of [3].  Also see [14].
        [10] Section 8.2.2.1 of [3].  Also see [14].
        [11] Section 8.3.2.2 of [3].  Also see [7].
        [12] Section 8.1.1 of [3].
        [13] Section 8.1.4.4 of [3].
        [14] Section 8.4.1.2 of [3].

        [15] Section 8.4.2 of [3].
        [16] Section 8.1.3 of [3].
        [17] Section 8.2.1.2 of [3].
        [18] Section 8.3.1.1 of [3].
        [19] Section 8.3.2.1 of [3].  Also see [7].
        [20] Section 8.3.2.3 of [3].  Also see [6], [7].
        [21] Section 8.4.1.3 of [3].
        [22] Section 8.4.1.1 of [3].
        [23] Section 8.4.1.4 of [3].
        [24] Section 8.4.3.1 of [3].
        [25] Section 8.4.3.2 of [3].
        [26] Section 8.2.3.1 of [3].
        [27] Section 8.3.3.1 of [3].
        [28] Section 8.1.4.1 of [3].
        [29] Refer [15]
        [30] Section 3 of [5]
        [31] Section 3.1 of [5]
        [32] Section 4 of [5]
        [33] Section 5 of [5]
        [34] Section 5.1 of [5]
        [35] Section 5.2 of [5]
        [36] Section 5.3 of [5]
        [37] Section 5.4 of [5]
        [38] Section 5.5 of [5]
        [39] Section 6 of [5]
        [40] Section 5.1 of [4]
        [41] Section 5.2.2 of [4]
        [42] Section 8.2.2.2 of [3]
        [43] Section 8.1.2.3 of [3]
        [44] Section 8.1.2.2 of [3]
        [45] Section 5.4 of [4]
        [46] Section 7 of [4]
        [47] Section 8 of [5]
        [48] Section 8.4.1.5 of [3]

3. References 📚

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
  • [3] Beadles, M. and D. Mitton, "Criteria for Evaluating Network Access Server Protocols", Work in Progress.
  • [4] Hiller, T., et al., "Cdma2000 Wireless Data Requirements for AAA", Work in Progress.
  • [5] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
  • [6] Mitton, D., Beadles, M., "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
  • [7] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
  • [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
  • [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  • [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
  • [11] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
  • [13] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
  • [14] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
  • [15] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP", RFC 2290, Feb 1998
  • [16] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
  • [17] Perkins, C., "IP Mobility Support", RFC 2002, Oct 1996.
  • [18] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
  • [19] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
  • [20] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

4. Security Considerations 🔒

Okay, real talk, this one's a plot twist 😭 This document is a requirements document, so it does not have any security concerns. The security requirements on protocols evaluated using this document are described in the referenced documents, so go check those out 🕵️‍♀️

5. IANA Considerations 🔢

No new number spaces here, bestie. This memo does not create any new number spaces for IANA administration 🧁

6. Acknowledgments 🫶

Huge thank-yous to the members of the Mobile IP, AAA, and NASREQ working groups who discussed and commented on these requirements 💖 We also want to thank the AAA evaluation team, Mike St. Johns, Barney Wolf, Mark Stevens, David Nelson, Dave Mitton, Basavaraj Patil and Stuart Barkley, for their thorough review of this document. Absolute legends 👑✨

7. Authors' Addresses ✨

Okay bestie, these are the legends who actually wrote this spec. Here's how to reach each of them 💌

Bernard Aboba 🌸

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425-936-6605
Fax:   +1 425-936-7329
EMail: bernarda@microsoft.com

Pat R. Calhoun 🦋

Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025

Phone: +1 650-786-7733
EMail: pcalhoun@eng.sun.com

Steven M. Glass 🎀

Steven M. Glass
Sun Microsystems
1 Network Drive
Burlington, MA 01845

Phone: +1 781-442-0504
Fax:   +1 781-442-1677
EMail: steven.glass@sun.com

Tom Hiller 🧚

Tom Hiller
Wireless Data Standards & Architectures
Lucent Technologies
263 Shuman Drive
Room 1HP2F-218
Naperville, IL 60563

Phone: +1 630-976-7673
EMail: tom.hiller@lucent.com

Peter J. McCann 💜

Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL  60566

Phone: +1 630-713 9359
EMail: mccap@lucent.com

Hajime Shiino 🍓

Hajime Shiino
Lucent Technologies Japan Ltd.
25 Mori Bldg. 1-4-30 Roppongi,
Minato-ku Tokyo
Japan

Phone: +81-3-5561-3695
EMail: hshiino@lucent.com

Glen Zorn 🔥

Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004

Phone: +1 425-468-0955
EMail: gwz@cisco.com

Gopal Dommety 🌈

Gopal Dommety
IOS Network Protocols
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706

Phone: +1 408-525-1404
Fax:   +1 408-526-4952
EMail: gdommety@cisco.com

Charles E. Perkins ⭐

Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, CA

Phone: +1 650-625-2986
Fax:   +1-650-625-2502
EMail: charliep@iprg.nokia.com

Basavaraj Patil 👑

Basavaraj Patil
Nokia Networks
6000 Connection Dr.
Irving, TX 75039

Phone: +1 972-894-6709
Fax:   +1 972-894-5349
EMail: Basavaraj.Patil@nokia.com

David Mitton 🦋

David Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821

Phone: +1 978-288-4570
EMail: dmitton@nortelnetworks.com

Serge Manning 🌸

Serge Manning
Nortel Networks
2201 Lakeside Blvd
Richardson, TX  75082-4399

Phone: +1 972-684-7277
EMail: smanning@nortelnetworks.com

Mark Anthony Beadles 💅

Mark Anthony Beadles
SmartPipes, Inc.
565 Metro Place South
Suite 300
Dublin, OH 43017

Phone: +1 614-923-5657
EMail: mbeadles@smartpipes.com

Pat Walsh 🫶

Pat Walsh
Lucent Technologies
263 Shuman Blvd.
1F-545
Naperville, IL

Phone: +1 630-713-5063
EMail: walshp@lucent.com

Xing Chen ✨

Xing Chen
Alcatel USA
1000 Coit Road
Plano, TX 75075

Phone: +1 972-519-4142
Fax:   +1 972-519-3300
EMail: xing.chen@usa.alcatel.com

Sanjeevan Sivalingham 🌈

Sanjeevan Sivalingham
Ericsson Wireless Communications Inc.,
Rm Q-356C
6455 Lusk Blvd
San Diego, CA 92126

Phone: +1 858-332-5670
EMail: s.sivalingham@ericsson.com

Alan Hameed 🎀

Alan Hameed
Fujitsu
2801 Telecom Parkway
Richardson, TX 75082

Phone: +1 972-479-2089

Mark Munson 🍓

Mark Munson
GTE Wireless
One GTE Place
Alpharetta, GA  30004

Phone: +1 678-339-4439
EMail: mmunson@mobilnet.gte.com

Stuart Jacobs 💜

Stuart Jacobs
Secure Systems Department
GTE Laboratories
40 Sylvan Road,
Waltham, MA 02451-1128

Phone: +1 781-466-3076
Fax:   +1 781-466-2838
EMail: sjacobs@gte.com

Byung-Keun Lim 🧚

Byung-Keun Lim
LG Electronics, Ltd.
533, Hogye-dong, Dongan-ku, Anyang-shi,
Kyungki-do,431-080
Korea

Phone: +82-31-450-7199
Fax:   +82-31-450-7050
EMail: bklim@lgic.co.kr

Brent Hirschman 🔥

Brent Hirschman
1501 Shure Dr.
Arlington Hieghts, IL 60006

Phone: +1 847-632-1563
EMail: qa4053@email.mot.com

Raymond T. Hsu 🌸

Raymond T. Hsu
Qualcomm Inc.
6455 Lusk Blvd.
San Diego, CA 92121

Phone: +1 619-651-3623
EMail: rhsu@qualcomm.com

Haeng S. Koo 🦋

Haeng S. Koo
Samsung Telecommunications America, Inc.
1130 E. Arapaho Road
Richardson, TX 75081

Phone: +1 972-761-7755
EMail: hskoo@sta.samsung.com

Mark A. Lipford 👑

Mark A. Lipford
Sprint PCS
8001 College Blvd.; Suite 210
Overland Park, KS  66210

Phone: +1 913-664-8335
EMail: mlipfo01@sprintspectrum.com

Ed Campbell 💖

Ed Campbell
3Com Corporation
1800 W. Central Rd.
Mount Prospect, IL 60056

Phone: +1 847-342-6769
EMail: ed_campbell@3com.com

Yingchun Xu 🌈

Name: Yingchun Xu
WaterCove Networks
One Century Centre, Suite 550
1750 E. Golf Road
Schaumburg, IL

Phone: +1 847-477-9280
EMail: yxu@watercove.com

Shinichi Baba 🍓

Shinichi Baba
Toshiba America Research, Inc.
PO Box 136,
Convent Station, NJ 07961-0136

Phone: +1 973-829-4795
EMail: sbaba@tari.toshiba.com

Eric Jaques 🫶

Eric Jaques
Vodafone AirTouch
2999 Oak Road, MS-750
Walnut Creek, CA 94596

Phone: +1 925-279-6142
EMail: ejaques@akamail.com

8. Intellectual Property Statement 🔥

Okay so, the IETF is being very chill here and says it takes no position on whether any intellectual property rights claimed over the tech in this doc are valid or how far they reach. It also doesn't promise it has tried to find any of those rights, and it's not saying whether licenses are available or not. 🙈

If you want the scoop on how the IETF handles rights for standards-track and standards-related docs, check out BCP-11. Copies of claimed rights that were submitted for publication, assurances of licenses, or the results of any attempt to get a general license or permission for implementers or users can all be requested from the IETF Secretariat.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to practice this standard. Send that info to the IETF Executive Director. 💌

Copyright (C) The Internet Society (2000). All Rights Reserved. ✨

So here's the deal: this document and translations of it can be copied and handed out to others. You can also make derivative works that comment on or explain it, or help with implementing it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions at all. The one condition is that the above copyright notice and this paragraph stay on every copy and derivative work. 🫶

The catch is that this document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when you need to translate it into languages other than English. 🌸

These limited permissions are perpetual and won't be revoked by the Internet Society or its successors or assigns. 👑

The document and the info in it are provided on an "AS IS" basis, and the disclaimer is serious business, so here it is in full:

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