RFC 2477

Criteria for Evaluating Roaming Protocols

📅 published January 1999, from ietf

Criteria for Evaluating Roaming Protocols 🦋

Okay bestie, this is RFC 2477 💖 It's an Informational doc, so it's sharing info rather than setting a standard. Written by B. Aboba and G. Zorn at Microsoft Corporation, it was published in January 1999 as part of the Network Working Group 🎀 The header doesn't list anything it obsoletes or updates, so it's just doing its own thing ✨

Status of this Memo

Ngl this is the fine print 💅 This memo gives info to the Internet community. It does NOT specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 🫶

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌈

1. Abstract ✨

So this one is all about "roaming capability" for dialup Internet users 📞 Roaming capability means being able to use multiple Internet service providers (ISPs) while still having a formal, customer-vendor relationship with just one of them 🧚 The doc describes the requirements for setting that up 💖

2. Introduction 🌍

Roaming services already work worldwide, and they keep getting more popular [1]. Here's who's interested:

  • Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to team up with other regional providers to cover a wider area.
  • National ISPs wanting to combine operations with one or more ISPs in another nation, for more coverage across a group of countries or a continent.
  • Businesses that want to give their employees a full package of dialup services on a global basis. That can include Internet access as well as secure access to corporate intranets via a Virtual Private Network (VPN) 💼

This doc gives an architectural framework for provisioning roaming capabilities, and it describes the requirements that must be met by the elements of that architecture 🏗️

2.1. Requirements language

Here's the key words bit 🔑 In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [4].

Heads up 👀 The requirements in this document are to be used when evaluating protocol submissions. So the requirements language refers to the capabilities of those protocols. The protocol documents themselves will specify whether a feature is required, recommended, or optional for use in roaming. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted 🔐

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. A protocol submission that satisfies all the must, must not, should and should not requirements for its capabilities is said to be "unconditionally compliant". One that satisfies all the must and must not requirements, but not all the should or should not requirements for its protocols, is said to be "conditionally compliant" 💅

2.2. Terminology

This doc uses these terms a lot 📚

  • phone book: a database or document containing data about dialup access, including phone numbers and any associated attributes.
  • phone book server: a server that maintains the latest version of the phone book. Clients talk to phone book servers to keep their phone books up to date.
  • Network Access Server: the Network Access Server (NAS) is the device that clients dial in to in order to get access to the network.
  • Authentication server: a server that provides for authentication/authorization within the roaming architecture.
  • Accounting server: a server that provides for accounting within the roaming architecture.
  • Authentication proxy: authentication proxies may be deployed within the roaming architecture for several purposes, including authentication forwarding, policy implementation, shared secret management, and attribute editing. To the NAS, the authentication proxy appears to act as an authentication server. To the authentication server, the proxy appears to act as an authentication client 🧚
  • Accounting proxy: accounting proxies may be deployed within the roaming architecture for several purposes, including accounting forwarding, reliability improvement, auditing, and "pseudo-transactional" capability. To the NAS, the accounting proxy appears to act as an accounting server. To the accounting server, the proxy appears to act as an accounting client.
  • Network Access Identifier: in order to provide for the routing of authentication and accounting packets, the user name MAY contain structure. This structure gives authentication or accounting proxies a way to locate the authentication or accounting server that is supposed to receive the request 🗺️

3. Architectural framework 🏗️

The roaming architecture has three major subsystems:

  • Phone book Subsystem
  • Authentication Subsystem
  • Accounting Subsystem

The phone book subsystem handles the maintenance and updating of the user phone book. The phone book tells the user where the roaming-enabled Points of Presence (POPs) are, and their phone numbers 📖 The authentication subsystem gives authorized users access to the POPs in the phone book, and denies access to unauthorized users 🚪 The accounting subsystem's goal is to provide info on the resources used during the user's session ⏱️

3.1. Phone Book Subsystem

The phone book subsystem covers:

  • Phone number presentation
  • Phone number exchange
  • Phone book compilation
  • Phone book update

Phone number presentation: this is the display of available phone numbers to the user, and it ends with the user choosing a number. Since the user interface and sequence of events depend on the connection management software being used, individual vendors will likely take different approaches. Those differences can include variances in the format of client phone books, varying approaches to presentation, etc. There's no inherent problem with that, so phone number presentation need not be standardized 🎨

Phone number exchange: this is the propagation of phone number changes between providers in a roaming association. Current roaming implementations don't fully automate the phone number exchange process [1], so phone number exchange need not be standardized at this time 🔄

Phone book compilation: once an ISP's phone book server has received its updates, it needs to compile a new phone book and propagate it to all the phone book servers that ISP operates. Since the compilation process doesn't affect protocol interoperability, it need not be standardized 🧁

Phone book update: once the phone book is compiled, it needs to be propagated to users. Standardizing the update process lets providers update user phone books independently of their client software or operating system 🎀

3.2. Authentication Subsystem

The authentication subsystem covers:

  • Connection management
  • Authentication
  • NAS Configuration/Authorization
  • Address Assignment/Routing
  • Security

Connection management: to use the POPs of the local provider, you first need to bring up a connection 🔌

Identification: authentication has two parts. There's the claim of identity (identification) and the proof of that claim (verification). As part of the authentication process, users identify themselves to the Network Access Server (NAS) in a way that lets the authentication request be routed to its home destination 🪪

Authentication: authentication is typically required before access to the network is allowed. CHAP [8] and PAP [9] are the two authentication protocols most commonly used within the PPP [10] framework today. Some groups of users need different forms of proof of identity (e.g., token or smart cards, Kerberos credentials, etc.) for special purposes, like getting into corporate intranets. The Extensible Authentication Protocol (EAP) [7] was created to provide a general mechanism for supporting these methods 🔑

NAS configuration/authorization: to set up the session, authorization parameters need to be sent from the home authentication server to the local ISP's NAS 📨

Address assignment/routing: if the user should be able to communicate with the rest of the Internet, the session will be assigned a routable IP address by the NAS 🌐

Security: while authenticating and authorizing the user session, it may be desirable to protect against a variety of security threats 🛡️

3.3. Accounting Subsystem

The accounting subsystem lets the participants in the roaming consortium keep track of what resources are used during a session 📊 Relevant info includes how long the user was connected to the service, connection speed, port type, etc.

4. Roaming Requirements 📋

4.1. Phonebook requirements

4.1.1. Phone book update protocol

Portability: the update protocol MUST allow for updating clients on a range of platforms and operating systems. Therefore, the update mechanism MUST NOT impose any operating system-specific requirements 💻

Authentication: the client MUST be able to determine the authenticity of the server sending the phone book update. The server MAY also be able to authenticate the client 🤝

Versioning: the update protocol MUST provide for updating the phone book from an arbitrary previous version to the latest available version 🔢

Integrity checking: the client MUST be able to determine the integrity of the received update before applying it, and MUST be able to determine the integrity of the newly produced phone book after updating it 🧪

Light weight transfers: since the client may be a low-end machine or internet appliance, the update protocol MUST be lightweight 🪶

Language support: the phone book update mechanism MUST support the ability to request that the phone book be transmitted in a particular language and character set. For example, if the customer has a Russian language software package, then the propagation and update protocols MUST provide a mechanism for the user to request a Russian language phone book 🇷🇺🌸

4.1.2. Phone book format ✨

Okay bestie, the phone book needs a whole vibe check 💅 Let's go through the three kinds of info it has to carry.

Phone number attributes 📞 The phone book format MUST support phone number attributes commonly used by Internet service providers. These attributes are required in order to provide users with information on the capabilities of the available phone numbers. 🌸

Provider attributes 🏢 Beyond info about a given phone number, the phone book MUST provide information on the individual roaming consortium members. These attributes are required in order to provide users with information about the individual providers in the roaming consortium. 👑

Service attributes 🎀 Beyond info about a given phone number and service provider, the phone book MUST provide information relevant to configuration of the service. These attributes are necessary to provide the client with information relating to the operation of the service. ✨

Extensibility 🦋 Attributes are gonna need updating constantly, so the phone book format MUST support the addition of phone number, provider and service attributes without modification to the update protocol. Registration of new phone book attributes will be handled by IANA. The attribute space MUST be sufficiently large to accomodate growth. It's giving "plan for the future" energy 🔮

Compactness 🍓 The phone book gets updated super often, so the phone book format MUST be compact so as to minimize the bandwidth used in updating it. Small and efficient is the move 💜

4.2. Authentication requirements 🔐

4.2.1. Connection Management 🔌

PPP is literally everywhere right now, so a roaming standard MUST provide support for PPP and IP. A roaming standard MAY provide support for other framing protocols such as SLIP. Lowkey, SLIP support is expected to be a struggle 💀 because SLIP does not support negotiation of connection parameters and lacks support for protocols other than IP.

A roaming standard MAY provide support for non-IP protocols (e.g., IPX or AppleTalk) since these may be useful for the provision of corporate intranet access via the Internet. Since the client is meant to start PPP negotiation right away on connection, support for scripting SHOULD NOT be part of a roaming standard. No scripts, just vibes 🙅‍♀️

4.2.2. Identification 🪪

A roaming standard MUST provide a standardized format for the userID and realm presented to the NAS. Everybody's ID has to look the same so the NAS can read it 🫶

4.2.3. Verification of Identity 🕵️‍♀️

Authentication types 🔑 A roaming standard MUST support CHAP, and SHOULD support EAP. Due to security concerns, PAP authentication SHOULD NOT be supported. A possible exception is where PAP is used to support a one time password or token. PAP is giving risky 😬

Scalability 📈 A roaming standard, once available, is likely to be widely deployed on the Internet. A roaming standard MUST therefore provide sufficient scalability to allow for the formation of roaming associations with thousands of ISP members. Thousands of members? Iconic 🌈

RADIUS Support 🛰️ RADIUS [2,3] is basically everywhere as an authentication, authorization and accounting solution, so a roaming standard MUST be able to incorporate RADIUS-enabled devices within the roaming architecture. It is expected that this will be accomplished by development of gateways between RADIUS and the roaming standard authentication, authorization, and accounting protocol. Gateways to the rescue 🧚

4.2.4. NAS Configuration/Authorization 🛠️

To keep things compatible with the NAS or the local network, authentication/authorization proxies often will add, delete, or modify attributes returned by the home authentication server. Proxies also tend to handle resource management and policy functions. So a roaming standard MUST support the ability of proxies to perform attribute editing and implement policy. Proxies have main character energy 👑

4.2.5. Address assignment/routing 🗺️

A roaming standard MUST support dynamic address assignment. Static address assignment MAY be supported, most likely via layer 2 or layer 3 tunneling.

Layer 2 tunneling protocols 🧳 Layer-2 tunneling protocols, such as PPTP, L2F, or L2TP, hold great promise for the implementation of Virtual Private Networks as a means for inexpensive access to remote networks. Therefore proxy implementations MUST NOT preclude use of layer 2 tunneling. Don't block the VPN girlies 🚫

Layer 3 tunneling protocols ✈️ Layer-3 tunneling protocols as embodied in Mobile IP [5] hold great promise for providing "live", transparent mobility on the part of mobile nodes on the Internet. Therefore, a roaming standard MUST NOT preclude the provisioning of Mobile IP Foreign Agents or other Mobile IP functionality on the part of service providers. Mobile IP is literally the glow-up of moving devices 🦋

4.2.6. Security 🛡️

Security analysis 🔍 A roaming standard MUST include a thorough security analysis, including a description of security threats and countermeasures. This includes specification of mechanisms for fraud prevention and detection. No skipping the homework 📚

Hop by hop security 🔒 A roaming standard MUST provide for hop-by-hop integrity protection and confidentiality. This MAY be accomplished through support of network layer security (IPSEC) [6].

End-to-end security 🫣 Policy implementation and attribute editing are super common in roaming systems, so proxies may need to modify packets in transit between a local NAS and the home server. To permit authorized modifications while also guarding against attacks by rogue proxies, a roaming standard needs to support data object security. As a result, a roaming standard MUST provide end-to-end confidentiality and integrity protection on an attribute-by-attribute basis. However, non-repudiation is NOT a requirement for a roaming standard. Rogue proxies are NOT invited to the party 🚨

4.3. Accounting requirements 🧾

Real-time accounting ⏱️ In today's roaming implementations, real-time accounting is a practical necessity for fraud detection and risk management. As a result, a roaming standard MUST provide support for real-time accounting. Real-time or nothing, bestie ⚡

Accounting record formats 📋 There is currently no proposed standard for NAS accounting, and providers use wildly different protocols to communicate accounting information within their own organizations. Therefore, a roaming standard MUST prescribe a standardized format for accounting records. For the sake of efficiency, the record format MUST be compact. Chaos is not the vibe 🙃

Extensibility 🌱 A standard accounting record format MUST be able to encode metrics commonly used to determine the user's bill. Since these metrics change over time, the accounting record format MUST be extensible so as to be able to add future metrics as they come along. The record format MUST support both standard metrics as well as vendor-specific metrics. Future-proof and iconic 👑

5. References 📚

  • [1] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997.
  • [2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
  • [3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
  • [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [5] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
  • [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [7] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
  • [8] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
  • [9] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", RFC 1334, October 1992.
  • [10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

6. Security Considerations 🔐

This document, being a requirements document, does not have any security concerns. The security requirements on protocols to be evaluated using this document are mainly described in section 5.2. Okay so no security concerns in this doc, but the protocols you evaluate with it? Those need the full security glow-up 🫠

7. Acknowledgements 🫶

Thanks to Pat Calhoun (pcalhoun@eng.sun.com), Butch Anton (butch@ipass.com) and John Vollbrecht (jrv@merit.edu) for many useful discussions of this problem space. Real ones 💖

8. Authors' Addresses 💌

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-936-6605
EMail: bernarda@microsoft.com


Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-703-1559
EMail: glennz@microsoft.com

Copyright (C) The Internet Society (1999). 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. 🦋

📦 where this page comes from