RFC 2194

Review of Roaming Implementations

📅 published September 1997, from ietf

RFC 2194: Review of Roaming Implementations ✨

okay bestie, this one is a September 1997 doc from the Network Working Group 🎀 It's an Informational RFC, so it's giving "here's what's out there," not "do it this way." The authors are B. Aboba (Microsoft), J. Lu (AimQuest Corp.), J. Alsop (i-Pass Alliance), J. Ding (Asiainfo), and W. Wang (Merit Network, Inc.) 🦋 The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 💅

1. Status of this Memo

this memo is giving "info for the Internet community" 📚 It does not specify an Internet standard of any kind, so don't go treating it like one 🙈 Distribution is totally unlimited too 🌈

2. Abstract

this doc reviews how existing roaming implementations are designed and how they work 🧚 "Roaming capability" is loosely defined as being able to use any one of several Internet service providers (ISPs) while only having a formal, customer-vendor relationship with one of them 💜 Places where you'd need this include ISP "confederations" and ISP-provided corporate network access support 🏢

3. Introduction

ngl there's been a lot of buzz lately around features that fall under "roaming capability" for Internet users 🔥 The interested parties are:

  • Regional ISPs in a particular state or province, teaming up with other regional providers to cover a wider area 🗺️
  • National ISPs combining operations with one or more ISPs in another nation, so they can offer better service across a group of countries or a whole continent 🌏
  • Businesses that want to give their employees a full package of access services worldwide 💼 That can include Internet access plus secure access to corporate intranets through a Virtual Private Network (VPN), built on tunneling protocols like PPTP, L2F, or L2TP 🔐

so what does roaming actually need? 🤔 This list is a first cut at the requirements for successful roaming among an arbitrary set of ISPs:

  • Phone number presentation
  • Phone number exchange
  • Phone book compilation
  • Phone book update
  • Connection management
  • Authentication
  • NAS Configuration/Authorization
  • Address assignment and routing
  • Security
  • Accounting

this doc reviews existing roaming implementations and describes what each one does within that framework 💅 It also covers implementations that aren't full roaming but still tackle a few of those problems. Those usually fall into the bucket of shared use networks or non-IP dialup networks 🦋

3.1. Terminology

the doc uses these terms a lot, so here's the tea ☕

home ISP : the ISP you actually have an account with 💖

local ISP : the ISP you call to get access 📞 With roaming, your local ISP can be different from your home ISP 🌸

phone book : a database or document with dialup access info, including phone numbers and any related attributes 📒

shared use network : an IP dialup network that two or more organizations share 🤝 These usually use distributed authentication and accounting to keep the sharing parties' relationship running smoothly ✨ Since roaming needs those same facilities, shared use is often the first step toward roaming 🪜 One way a provider can offer roaming is by signing shared use agreements with multiple networks 💜 The catch is that shared use has been held back by a lack of interoperability between implementations 😭

non-IP dialup network : a dialup network that gives users access to its member systems over protocols other than IP 🧚 These networks may have phone book synchronization so that systems, admins, and users all have a current list of participating systems 📋 Examples of non-IP dialup networks with phone book synchronization are FidoNet and WWIVnet 👑

4. Global Reach Internet Consortium (GRIC)

the story: AimQuest Corporation, a US-based Internet technology developer, led the way 🇺🇸 Ten ISPs from the USA, Australia, China, Japan, Hong Kong, Malaysia, Singapore, Taiwan, and Thailand formed the Global Reach Internet Connection (GRIC) in May, 1996 🎀 The goals were to make a global roaming service happen and to coordinate billing and settlement among the members 💅 Commercial operation kicked off in December of 1996, and GRIC has since grown to over 100 major ISPs and Telcos worldwide ✨ Members include NETCOM (USA), KDD and Mitsubishi (Japan), iStar (Canada), Easynet (UK), Connect.com (Australia), Iprolink (Switzerland), Singapore Telecom, Chunghwa Telecom (Taiwan), and Telekom Malaysia 🌈 More info on GRIC is at http://www.gric.net/ 🔗

GRIC members picked software built by AimQuest 💜 AimQuest's roaming implementation has three major pieces: the AimTraveler Authentication Server (AAS), the AimTraveler Routing Server (ARS), and the AimQuest Internet Management System (AIMS), which is software that makes the billing process easier 💰 More on the AimQuest roaming implementation is at http://www.aimquest.com/ 🦋

the AimTraveler Authentication Server (AAS) runs at each member ISP's location and handles incoming authentication requests from NAS devices and other AASes 🔐 The AimTraveler Routing Server (ARS) can run anywhere 🌍 You can use a single routing server if you want centralized routing, or run multiple routing servers to boost speed and reliability or to gateway to networks of especially large partners 🧚

the first AimTraveler software, deployed by AimQuest in May, 1996, supported direct authentication between roaming consortium members 💖 But as GRIC grew, managing the relationships between authentication servers became a mess 😩 So in August, 1996, AimQuest started developing the AimTraveler Routing Server (ARS) to improve scalability 📈

the routing server has two parts: the Central Accounting Server and the Central Routing Server 🎀 The Central Accounting Server collects all the roaming accounting data for settlement 💵 The Central Routing Server manages and maintains info on the authentication servers in the roaming consortium 🗂️ You can add, delete, or update ISP authentication server info (for example, adding a new member ISP) by editing a configuration file on the Central Routing Server ✏️ The AimTraveler Authentication Server configuration files don't need to be changed for that 🙌

the AimTraveler Authentication and Routing Servers are available for various UNIX platforms 🐧 Windows NT versions are still in development 🛠️ The AimTraveler Authentication Server supports both the UNIX password file and Kerberos 🔑

AIMS is built for large ISPs that want one centralized management system for all their ISP operations, including sales, trouble-ticketing, service, and billing 🏢 It produces usage and transaction statement reports, and it has a settlement module that makes settlement/billing reports for roaming consortium members 📊 Based on those reports, providers charge their ISP/roaming customers and settle the roaming balance among themselves 🤑 AIMS currently runs on Sun/Solaris/Oracle, and a version for Windows NT and SQL Server was expected to be available in Q4 1996 ⭐

4.1. Phone number presentation

right now there are two main ways GRIC users can find available phone numbers 📱 One is a Web-based directory from the GRIC secretariat, and the other is a GRIC phone book client on the user's PC that can dial 🖥️

4.1.1. Web based directory

there's a directory of GRIC phone numbers on the GRIC home page at http://www.gric.com/ 🌸 The list is arranged by country and provider 🌏 For each provider in a country, the directory is shown as a table with this info:

  • Provider address, voice phone and fax
  • Customer support phone number
  • Provider domain name
  • Primary Domain Name Server
  • Secondary Domain Name Server
  • Dial-up IP Address
  • News server
  • Web page
  • POP phone numbers (i.e. 1-408-366-9000)
  • POP locations (i.e. Berkeley)
  • Proxy addresses
  • Dialer configuration

to find a number with the Web-based directory, users are expected to be online 💻 They navigate to the right country and provider, look up the number, and paste it into the AimQuest Ranger dialer 🦋

4.1.2. GRIC phone book client

the GRIC phone book client gives you phone book presentation and automatic phone number updates 🪄 The GRIC phone book includes a list of countries, states, cities, and area/city codes, plus detailed provider info like the customer support phone number and Internet server configuration info 📖 The phone book is written in Java and you can download it from the AimQuest website:

http://www.aimquest.com/dialer.html

4.2. Phone number exchange

GRIC members send info about themselves and their POPs to the GRIC secretariat, which AimQuest runs 📨 The secretariat then compiles a new phone book and posts updates on the GRIC FTP and Web servers 🌐

GRIC users download the phone numbers either as a Windows .ini file or in HTML 💾

4.3. Phone book compilation

GRIC phone books are compiled by hand 🖐️ They're basically a concatenation of available numbers from all roaming consortium members, with no policy applied 🧃 When new POPs come online, their numbers get forwarded to GRIC, which adds them to the phone book servers 🚀

4.4. Phone book update

phone numbers in the GRIC phone book client update automatically when you connect ⚡ The AimTraveler server has an address book with the phone numbers of all roaming consortium members 📓

4.5. Connection management

the AimTraveler software supports SLIP and PPP, plus PAP and CHAP authentication 🔌✨

4.6. Authentication ✨

okay so GRIC does distributed authentication 🫶 and the userID is your email address, so something like liu@Aimnet.com is what gets presented to the remote NAS device. it's giving "my login is my email" energy 💌

After the initial PPP authentication exchange, the NAS passes along the userID, the domain, and the password info. If it's CHAP instead, it passes the challenge and the response. Then it all goes to the AimTraveler Authentication Server, which speaks both TACACS+ and RADIUS 🔐

If it's a regular customer login, it's just normal userID and password authentication, nothing spicy 💅 But if the user is a "roamer" (a userID with an @ and a domain name), the authentication server sends a query to the closest routing server. The AimTraveler Routing Server first authenticates the AAS that sent the request. If that works, it checks its authentication server table. If it can match the user's domain to a "Home ISP", the Home ISP authentication server's routing information gets sent back to the local ISP's authentication server 🗺️ Then the AAS uses that info to ask the user's Home ISP AAS to verify the userID and password.

If the user is valid, the Home ISP authentication server sends a "permission granted" message back to the Local ISP authentication server 🎉 The Local ISP authentication server then tells the NAS to give the user a dynamic IP address from its address pool. But if the username or password is wrong, the Home ISP AAS sends a rejection to the Local ISP AAS, and the NAS drops the user 💀 bye bestie

If there are multiple routing servers and the query to the first one doesn't find a match, it gets forwarded to the next one 🔁 The server queries get cached on the routing servers, which makes repeated queries faster ⚡ The cache stays around until a routing server table entry gets updated or deleted. When that happens, a message goes out to all neighbour routing servers so they can delete their caches too 🧹

The local authentication server also gets the accounting data from the NAS. For a regular customer login, the data gets written to the Local ISP AAS log file. For a "roamer," it gets written to three places: the Local ISP AAS log file, the Home ISP AAS log file, and the ARS log file 📒✨

And if the local ISP authentication server has caching turned on, it caches the Home ISP authentication server configurations that the routing server sent over. So if the same domain gets queried again, the local authentication server doesn't have to bug the routing server again 🙈 The local cache gets cleared when the local authentication server receives an update message from the routing server or from the system manager.

4.7. NAS Configuration/Authorization 🎀

AimTraveler has two components: a Client (AAS) and a Server (ARS) 👯

The AimTraveler Client acts as the PPP dial-up authentication server. When it spots an '@' sign in the userID field, it asks the AimTraveler Server for routing info, and then forwards the authentication request to the user's home authentication server 🧚 The AimTraveler Server is a centralized routing server, and it holds the authorized ISP's domain name, the authentication servers, and other info.

AimTraveler currently supports RADIUS and TACACS+, and it could be extended to support other authentication protocols too 🔧 It also receives all the accounting records, and those get used as input data for billing 💸

Here's the tea: ISPs' NAS devices might be configured differently from each other 🫠 So the attributes that come back from the home ISP AAS get thrown away.

4.8. Address assignment and routing 🌸

All addresses in GRIC get assigned dynamically from inside the local ISP's address pool 🏡 Static addresses and routed LAN connections will be considered in the future, once GRIC offers corporate roaming service and tunneling protocols get implemented. so not right now, but it's on the list ✨

4.9. Security 🔐

Okay, this one's serious, so pay attention 🚨 The user's password gets hashed with MD5 before it's sent from the Local ISP AAS to the Home ISP AAS. An encryption key is shared between the AAS and the ARS 🗝️ And the current version of the AimTraveler AAS does not support token cards or tunneling protocols. so no token cards and no tunneling yet, periodt 🙅‍♀️

4.10. Accounting 💜

The AimTraveler Authentication Server (AAS) software can act as either a RADIUS or a TACACS+ accounting server 📊 When accounting info comes in from the NAS, the local AimTraveler Authentication Server (AAS) sends the accounting data (user name, domain name, login time) to both the Central Accounting Server (which is part of the ARS) and the user's Home ISP AimTraveler authentication server. For GRIC, the Central Accounting Server is run by AimQuest 🏢

The data sent to the central accounting server and the home ISP is identical, except for the form of the user id and the time stamp ⏰ Say a traveler's home ISP is in the US but they're traveling in Japan. The Local (Japanese) ISP AimTraveler authentication server gets an accounting record stamped with Japan time, while the Home (US) ISP AimTraveler authentication server gets one stamped with the appropriate US timezone 🌏

The accounting data includes 2 new attributes for settlement reporting 🧾

  Attribute              Number   Type
  ---------              ------   ----

  Roaming-Server-ID       101     string
  Isp-ID                  102     string

The Roaming-Server-ID attribute identifies the AAS that sent the authentication request. The Isp-ID attribute identifies the local ISP 📍 With that info, the home ISP can track the roaming activities of its users, aka where they're logging in from 👀

The AimTraveler Server running at AimQuest keeps a record of all roaming transactions, and those feed into the settlement and billing process 💰 At the end of each month, AimQuest provides a roaming transaction summary to GRIC members using AIMS. And the AIMS software can be configured so that it takes into account the settlement rules that GRIC members agreed to 🫶

5. i-Pass implementation 🦋

5.1. Overview 🌈

i-Pass Alliance Inc., based in Mountain View, California, has developed and operates a commercial authentication and settlement clearinghouse service that provides global roaming between Internet service providers 🌍 It's fully operational, so it's not a someday thing, it's a right now thing ✨

i-Pass Alliance Inc. also has offices in Toronto, Singapore, and London 🗼 More info is available at http://www.ipass.com.

The i-Pass network is made up of a bunch of servers that give real-time authentication services to partner ISPs 🖥️ Authentication requests and accounting records for roaming users get encrypted and sent to an i-Pass server, where they're logged, and then forwarded to a home ISP for authentication and/or logging 🔒

Periodically, i-Pass reconciles all the accounting records, generates billing statements, and acts as a single point for collecting and remitting payments 💸

i-Pass only provides its service to ISPs and channel partners 🤝 It does not try to set up a business relationship with the individual-user customers of an ISP. not its problem, not its vibe 🙅‍♀️

5.2. Access Point Database (APD) 🗺️

i-Pass keeps a list of roaming access points in an Oracle database 🗄️ You can search this list by geographic region using a Web browser, or download the whole thing using FTP 📥 The info stored for each access point includes:

  • Name of service provider
  • Country
  • State or Province
  • City or Region
  • Telephone number
  • Technical support phone number
  • Service types available
  • Technical information (help file)
  • Service pricing information

The Access Point Database is maintained by i-Pass staff, based on input from i-Pass partners 🫶

5.3. Phone number presentation 📞

i-Pass has developed a Windows application with a simple point-and-click interface called the "i-Pass Dial Wizard" 🪄 It helps end-users select and connect to a local Internet access point, and honestly it's so easy 🥹

The Dial Wizard lets users first select the country they're roaming in. Then it shows a list of states, provinces, or other regions in that country. Finally, it shows a list of access points within the chosen state or province 🗺️ For each access point in the region, the Dial Wizard displays the city name, the modem phone number, and the price info.

When the user picks an access point, a Windows 95 "DialUp Networking" icon gets created for it ✨ If there's a login script tied to that access point, the DialUp Scripting tool gets configured automatically. So end-users never have to set up any login scripting themselves 🙌

The Dial Wizard has a built-in phonebook with all the i-Pass access points in it 📒 That phonebook may be refreshed automatically from a master copy on the ISP's web site.

The Dial Wizard is free for i-Pass partners 🎁 i-Pass also offers the i-Pass Dial Wizard Customization Kit, which lets ISP partners make customized versions of the Dial Wizard with their own logo, etc. main character energy for ISPs 👑

5.4. Authentication 🔐

There are three entities involved in handling an authentication request 🧩

  • Local ISP: At the local ISP, the authentication server is modified to recognize user IDs of the form username@auth_domain as remote authentication requests. Those requests get forwarded to an i-Pass server.
  • i-Pass Server: The i-Pass server receives the authentication request, logs it, and forwards it to the home ISP identified by the auth_domain portion of the user ID.
  • Home ISP: The home ISP receives the authentication request, performs authentication using its normal authentication method, and returns a YES/NO response to the i-Pass server, which in turn forwards the reply to the originating ISP.

i-Pass provides software components that run on the authentication servers of the local and home ISPs 💻 Each member ISP has to integrate these components with the native authentication method its ISP is using. To make this easier, i-Pass has developed "drop-in" interfaces for the most commonly used authentication methods 🪂 At the date of writing, these interfaces are supported:

  • Livingston RADIUS
  • Ascend RADIUS
  • Merit RADIUS
  • TACACS+
  • Xylogics erpcd (Versions 10 and 11)

There's also a generic interface that authenticates based on the standard UNIX password file. This is meant as a starting point for ISPs using authentication methods other than the ones listed above 🌱

The software integration effort for a typical ISP is on the order of 2-5 man-days, including testing ⏳ Platforms currently supported include:

  • Solaris 2.5 (Sparc).LI
  • Solaris 2.5 (Intel)
  • BSDI
  • Digital Unix
  • Linux
  • FreeBSD
  • HP/UX

ISPs may choose to provide authentication for their end-users roaming elsewhere, but not to provide access points to the i-Pass network 🧳 In that case, the software integration effort is greatly reduced and can be as little as 1/2 a man-day 🎀✨

5.5. Accounting 💸

okay so accounting transactions get handled the exact same way authentication requests do 🫶 they're logged at the i-Pass servers, AND they're sent in real-time to the home ISP. the whole point is letting ISPs update users' credit limit info on a real-time basis, to the extent their billing and accounting systems can actually support that 💅

Settlement happens monthly ✨ the process works out the costs for each individual session and then aggregates them for each ISP. a net amount gets calculated, and it's either due from i-Pass to the ISP or from the ISP to i-Pass, depending on how the usage actually went 🦋

the following reports go out to member ISPs 📮

  • A Monthly Statement showing summaries of usage, service provided, and any adjustments along with the net amount owing.
  • A Call Detail Report showing roaming usage by the ISP's customers.
  • A Service Provided report showing detailed usage of the ISP's facilities by remote users.

those reports are generated as ASCII documents and distributed to i-Pass partners electronically, either by e-mail or from a secure area on the i-Pass web site. hard-copy output is available on request 🖨️

the Call Detail Report also comes as a comma-delimited ASCII file, suitable for importing into the ISP's billing database. ISPs will normally use it to generate end-user billing for roaming usage 💖

5.6. Security 🔐

this is the serious bit, bestie 🙈 all transactions between ISPs and the i-Pass servers are encrypted using the SSL protocol. public key certificates get verified at both the client and the server. i-Pass issues these certificates and acts as the Certificate Authority.

transactions are also verified based on a number of other criteria, such as source IP address 🛡️

5.7. Operations 🛰️

i-Pass runs several authentication server sites. each site has two redundant server systems located in secure facilities and "close" to the Internet backbone 🌐 the sites are geographically distributed so that failures from natural disasters etc. are less likely to take everything down.

i-Pass also maintains a Network Operations Center in Mountain View, staffed on a 7x24 basis (literally always on 💀). its functions include monitoring the i-Pass authentication servers, monitoring authentication servers located at partner facilities, and dealing with problem reports.

6. ChinaNet implementation 🇨🇳

ChinaNet is owned by China Telecom and is China's largest Internet backbone, and it's giving big main character energy 👑 it was constructed by AsiaInfo, a Dallas based system integration company, and has 31 backbone nodes in 31 Chinese provincial capital cities. each province is building its own provincial network, has its own dialup servers, and administers its own user base.

so that ChinaNet users can reach nodes outside their province while traveling, a nationwide roaming system has been implemented 🧳 the roaming system was developed by AsiaInfo and is based on the RADIUS protocol.

6.1. Phone number presentation 📞

since China Telecom uses one phone number (163) for nationwide Internet access, most cities have the same Internet access number 🙌 so a phone book is not currently required for the ChinaNet implementation. a web-based phone book will be added in a future software release to support nationwide ISP/CSP telephone numbers and HTTP server addresses ✨

6.2. Connection management 🔌

the current roaming client and server supports both PPP and SLIP.

6.3. Address assignment and routing 🗺️

ChinaNet only supports dynamic IP address assignment for roaming users. static addresses are supported for users authenticating within their home province.

6.4. Authentication 🔑

when a user accesses a local NAS, it provides its userID either as username or as username@realm. the NAS passes the userID and password to the RADIUS proxy/server. if the username notation is used, the RADIUS proxy/server assumes the user is a local user and handles local authentication accordingly. if username@realm is used, the RADIUS proxy/server processes it as a roaming request 🧠

when the RADIUS proxy/server handles a request from a roaming user, it first checks the cache to see if the user information is already stored there. if there's a cache hit, the RADIUS proxy/server does the local authentication accordingly. if it doesn't find user information in its cache, it acts as a proxy and forwards the authentication request to the home RADIUS server. when the home RADIUS server responds, the local server forwards the response to the NAS. if the user is authenticated by the home server, the local RADIUS proxy caches the user information for a period of time (3 days by default) 💾

caching exists to avoid frequent proxying of requests and responses between the local RADIUS proxy and the home RADIUS server. when the home RADIUS server sends back a valid authentication response, the local RADIUS proxy/server caches the user information for a period of time (3 days by default). when the user next authenticates directly against the home RADIUS server, the home RADIUS server sends a request to the local server or servers to clear the user's information from the cache 🧹

6.4.1. Extended hierarchy 🪜

in some provinces, the local telecommunications administration (Provincial ISP) delegates control further to county access nodes, creating another level of hierarchy 🏘️ this is done to improve scalability and to avoid having the provincial ISP databases grow too large. in the current implementation, each provincial ISP maintains its own central RADIUS server, including information on all users in the province, while county nodes maintain distributed RADIUS servers. for intra-province roaming requests, the local RADIUS proxy/server directly forwards the request to the home RADIUS server.

for inter-province roaming requests though, the local RADIUS server does NOT forward the request directly to the home RADIUS server 😳 instead, the request goes to the central provincial RADIUS server for the home province. this only works when county level ISPs don't mind combining and sharing their user information. in this case it's fine, since all county level ISPs are part of China Telecom. in a future release, this multi-layer hierarchy will be implemented using multi-layer proxy RADIUS, in a manner more resembling DNS 🌸

6.5. Security 🔐

encryption is used between the local RADIUS proxy/server and the home RADIUS server. public/private key encryption will be supported in the next release. IP tunneling and token card support is under consideration 👀

6.6. Accounting 🧾

accounting information is transferred between the local RADIUS accounting proxy/server and the home RADIUS accounting server. every day, each node sends a summary accounting information record to a central server in order to support nationwide settlement. the central server is run by the central Data Communication Bureau of China Telecom. every month, the central server sends the settlement bill to the provincial ISPs 💰

6.7. Inter-ISP/CSP roaming 🌏

ChinaNet supports both ISP and CSP (Content Service Provider) roaming on its system ✨ for example, Shanghai Online, a Web-based commercial content service, uses RADIUS to authenticate ChinaNet users who don't have a Shanghai Online account. to make this work, the Shanghai Online servers act as a RADIUS client authenticating against the home RADIUS server. when users access a protected document on the HTTP server, they're prompted to send a username/password for authentication. the user then responds with their userID in username@realm notation.

a CGI script on the HTTP server then acts as a RADIUS authentication client and sends the request to the home RADIUS server. after the home RADIUS server responds, the CGI script passes the information to the local authentication agent. from this point forward, everything is taken care of by the local Web authentication mechanism 🫶

7. Microsoft implementation 🪟

Microsoft's roaming implementation was originally developed to support the Microsoft Network (MSN), which now offers Internet access in seven countries: US, Canada, France, Germany, UK, Japan, and Australia 🌍 in each of these countries, service is offered in cooperation with access partners. since users can connect to the access partner networks while keeping a customer-vendor relationship with MSN, this implementation fits within the definition of roaming as used in this document 🎀

7.1. Implementation overview 🧩

the first version of the Microsoft roaming software was deployed by the MSN partners in April, 1996. this version included a Phone Book manager tool running under Windows 95, plus a RADIUS server/proxy implementation running under Windows NT. TACACS+ is currently not supported 🙅‍♀️ additional components now under development include a Connection Manager client for Windows 95 and an HTTP-based phone book server for Windows NT. the Phone Book manager tool is also being upgraded to provide more automated phone book compilation 🚀

7.2. Phone number presentation 📱

the Connection Manager is responsible for presenting and updating phone numbers, as well as for dialing and making connections. to select phone numbers, users are asked to choose the desired country and region/state. phone numbers are then presented for the area selected. the primary numbers are those from the user's service provider that match the service type (Analog, ISDN, Analog & IDN) and the country and region/state selected. the other numbers (selected by clicking the More button) belong to other service providers that have a roaming agreement with the user's service provider 🗺️

7.2.1. Cost data 💸

cost data is not presented to users along with the phone numbers. however, that information may be made available by other means, such as via a Web page 🌸

7.2.2. Default phone book format ✨

okay so the Connection Manager lets you customize the phone book format 💅 and honestly I think a lot of ISPs are gonna use that, bestie. 🫶 But if you just want to plug and play, there's a default phone book format. It's made of a few files:

  • Service profile
  • Phone Book
  • Region file

The service profile is the info sheet for a service 📋. That service could be a solo Internet Service Provider, or it could be a roaming consortium 🌈. The service profile is an .ini file, and it holds:

  • The name of the service
  • The filename of the service's big icon
  • The filename of the service's little icon
  • A description of the service
  • The service phone book filename
  • The service phone book version number
  • The service regions file
  • The URL of the service phone book server
  • The prefix used by the service (i.e. "MSN/aboba")
  • The suffix or domain used by the service (i.e. "aboba@msn.com")
  • Whether the user name is optional for the service
  • Whether the password is optional for the service
  • Maximum length of the user name for the service
  • Maximum length of the password for the service
  • Information on service password handling (lowercase, mixed case, etc.)
  • Number of redials for this service
  • Delay between redials for this service
  • References to other service providers that have roaming agreements
  • The service profile filenames for each of the references
  • Mask and match phone book filters for each of the references (these are 32 bit numbers that are applied against the capability flags in the phone book)
  • The dial-up connection properties configuration (this is the DUN connectoid name)

The phone book file is a comma delimited ASCII file 🍓. Each line has these fields:

  • Unique number identifying a particular record (Index)
  • Country ID
  • A zero-base index into the region file
  • City
  • Area code
  • Local phone number
  • Minimum Speed
  • Maximum speed
  • Capability Flags:
  • The filename of the dialup network file (typically refers to a script associated with the number)

The capability flags are where it gets spicy 🌶️ so here's the full breakdown:

Bit 0: 0=Toll, 1=Toll free
Bit 1: 0=X25, 1=IP
Bit 2: 0=Analog, 1=No analog support
Bit 3: 0=no ISDN support, 1=ISDN
Bit 4: 0
Bit 5: 0
Bit 6: 0=No Internet access, 1=Internet access
Bit 7: 0=No signup access, 1=Signup access
Bit 8-31: reserved

Here's a sample phone book file, bestie 🧚:

65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
200133,1,1,Birmingham,205,5551212,9600,28800,0,10,
130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile
65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile

7.2.3. Additional attributes 🦋

okay so as we said earlier, some ISPs are gonna need extra phone number attributes or provider info that the default format doesn't cover 🙈. Different providers want different stuff, and new technologies keep showing up, so the list of attributes is gonna keep growing. That's why extensibility in the phone book format is highly desirable. Main character energy for future-proofing 👑

Here are some extra attributes that customers have already asked for:

  • Multicast support flag
  • External/internal flag (to differentiate display between the "internal" or "other" list box)
  • Priority (for control of presentation order)
  • Modem protocol capabilities (V.34, V.32bis, etc.)
  • ISDN protocol capabilities (V.110, V.120, etc.)
  • No password flag (for numbers using telephone-based billing)
  • Provider name

7.2.4. Addition of information on providers 💜

the default phone book doesn't have a way to show info about each individual ISP inside a roaming consortium 😭. It only does the consortium as a whole. For example, the provider icons (big and little) live in the service profile ✨. The service description is expected to hold the customer support number. But that info can't be given per member of a roaming consortium, which is kinda sad 🥺. Per-provider info that would be useful includes:

  • Provider voice phone number
  • Provider icon
  • Provider fax phone number
  • Provider customer support phone number

7.3. Phone number exchange 📞

rn, phone number exchange isn't supported by the phone book server 💀. So in the MSN implementation, it's all done by hand. When new POPs come online, the numbers get forwarded to MSN, which tests them and approves them for the phone book server. Updated phone books get made and loaded onto the server every week 🗓️.

7.4. Phone book compilation 🧩

the Phone Book Manager tool was built to make life easier for the access partners 🫶. It can add, remove, and edit phone numbers, and it makes both a brand new phone book and the difference files that go with it.

With version 1 of the Phone Book Administration tool, phone books get compiled by hand. They're basically a concatenation of the available numbers from every partner, with no policy applied 🙃. With version 1, partners prepare the updates and send them to MSN, which tests the numbers and approves them for the phone book. Then the updates get stuck together into one global update file.

The new version of the Phone Book Administration tool automates a ton of that compilation work 🔥. That means compilation can be decentralized, with each partner running their own phone book server. Partners can maintain and test their own phone books and post them on their own Phone Book Server, which is honestly iconic 👑.

7.5. Phone book update 🔄

there's a way to download phone book deltas, and also a way to download arbitrary executables that can do more complicated update processing 🧚. Digital signatures are only used when downloading executables, since only those are a security threat - the Connection Manager client doesn't check digital signatures on deltas because bogus deltas can't really cause any harm 🙈.

The Connection Manager updates the phone book every time the user logs on 🌸. It does this with an HTTP GET request to the phone book server. When the server looks at the request, it can consider stuff like the OS version on the client, the language on the client, the version of Connection Manager on the client, and the version of the phone book on the client. That's how it figures out what to send back 💖.

In the GET response, the phone book server sends back the difference files needed to update the client's phone book to the latest version. The client builds the new phone book by applying these difference files one after another ✨. This whole process updates the entire phone book, and it's simple enough to implement on a bunch of different HTTP servers, either as a CGI script or (on NT) as an ISAPI DLL 💅.

The difference files in the default phone book are a list of phone book entries, and each entry is uniquely identified by its index number 🔢. Additions are phone book entries with all the information filled in. Deletions are signified by entries with all entries zeroed out 🗑️. Here's a sample difference file:

65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
200133,0,0,0,0,0,0,0,0,0
130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile
65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile

7.6. Connection management 🎀

the Connection Manager can support any protocol that you can configure through Windows Dialup Networking, including PPP and SLIP running over IP 💜. By default, the IP address and the DNS server IP address both get assigned by the NAS. The DNS server assignment capability is described in [1] ✨.

7.7. Authentication 🔐

the Connection Manager client and the RADIUS proxy/server both support suffix style notation (i.e. "aboba@msn.com"), and prefix notation ("MSN/aboba") 🫶.

Prefix notation was made for NAS devices with small maximum userID lengths 📏. Its compactness gives way more characters for the userID field. But more and more NAS devices now support 253 octet userIDs (the maximum RADIUS supports), so the need for prefix notation is shrinking 🥹.

After the NAS device gets the userID from the Connection Manager client, it passes the userID/domain and password info (or, for CHAP, the challenge and the response) to the RADIUS proxy 🦋. The RADIUS proxy checks whether the domain is authorized for roaming by looking at a static configuration file. If it's authorized, the proxy forwards the request to the right RADIUS server. The domain to server mapping is also set up in a static configuration file 🗂️.

Static configuration files work well for small roaming consortia, but for bigger consortia they get tedious fr fr 😩. More scalable options could include using DNS SRV records for the domain to RADIUS server mapping 🌈.

7.8. NAS configuration/authorization 🎀

okay so the attributes the home RADIUS server sends back might make total sense to home NAS devices, but the local NAS could be set up differently, or be from a completely different vendor 🙈. so the RADIUS proxy may need to edit the attribute set the home server returned, so the local NAS gets the right config info ✨. the editing happens via attribute discard and insertion of attributes by the proxy.

alternatively, the home RADIUS server can be set up to not return any network-specific attributes at all, and let the local RADIUS proxy insert them instead 🦋.

these are the attributes most likely to cause conflicts:

Framed-IP-Address Framed-IP-Netmask Framed-Routing Framed-Route
Filter-Id Vendor-Specific Session-Timeout Idle-Timeout
Termination-Action

IP address and routing conflicts are literally so common 💀. when dynamic address assignment is used, an IP address pool that fits the local NAS can be swapped in for the pool the home RADIUS server designated 🌸.

BUT not every address conflict can be fixed by editing 😭. like, if it's a static network address for a LAN, the local NAS might not be able to accept the home server's assignment, and the roaming hosts might not be able to accept a different one either. yikes.

filter IDs also pose a problem 🙃. the local NAS might not implement the filter the home server designated. even if there's an equivalent filter, the proxy's configuration would have to track changes in the filter configs of every member of the roaming consortium in order to guarantee correct operation, and in practice that's likely to be unworkable. uploading the filter configuration directly isn't a fix either, because filter languages vary a ton across today's NAS devices.

since vendor specific attributes only have meaning to devices made by that vendor, using them is problematic in a heterogeneous roaming consortium 🧩. editing them, discarding them, or letting them be ignored is possible, but it might not always be acceptable. when vendor specific attributes relate to security, the proxy may not be allowed to modify or discard them, and the only acceptable option might be for the local NAS to drop the user 😤. unfortunately RADIUS doesn't distinguish between mandatory and optional attributes, so the proxy has no way to take guidance from the server.

conflicts over session or idle timeouts may happen since both the local and home ISP feel the need to adjust these parameters ⏰. the home ISP may want to adjust the parameter to match the user's software, while the local ISP may want to adjust it to match its own service policy. as long as the desired parameters aren't too far apart, a compromise is often possible 🤝.

7.9. Address assignment and routing 🌈

while the Connection Manager software supports both static and dynamic address assignment, in the MSN implementation all addresses are dynamically assigned.

however, selected partners also offer LAN connectivity to their customers, usually via static address assignment. these accounts don't have roaming privileges, though, since no mechanism has been put in place for letting these static routes move between providers 🚧.

users who want LAN roaming between providers are encouraged to pick a router that supports Network Address Translation (NAT). NAT versions in several low-end routers are compatible with the dynamic addressing used on MSN, and they support DHCP on the LAN side too ✨.

7.10. Security 🔐

the RADIUS proxy/server implementation does not support token cards or tunneling protocols 💅.

7.11. Accounting 💸

in the MSN roaming implementation, the accounting data exchange is specified in terms of an accounting record format, plus a method for transferring the records from the partners to MSN, which acts as the settlement agent 🏦. defining the interaction by record formats and transfer protocols means the partners don't talk to the settlement agent using NAS accounting protocols. so accounting protocol interoperability isn't required.

BUT for this perk to be fully realized, the accounting record format has to be extensible 🙌. that makes it more likely the format can be adapted to the wide variety of accounting protocols in use (like SNMP, syslog, RADIUS, and TACACS+), plus future protocols too. honestly, if the record format can't express the metrics a partner's accounting protocol provides, the record format won't be of much use in a heterogeneous roaming consortium 📉.

7.11.1. Accounting record format 📝

the Microsoft RADIUS proxy/server supports customizing the accounting record format, and it's expected that some ISPs will use that capability 💖. but for anyone who wants to use it "off the shelf," a default accounting record format is provided. the accounting record includes information provided by RADIUS:

User Name (String; the user's ID, including prefix or suffix)
NAS IP address (Integer; the IP address of the user's NAS)
NAS Port (Integer; identifies the physical port on the NAS)
Service Type (Integer; identifies the service provided to the user)
NAS Identifier (Integer; unique identifier for the NAS)
Status Type (Integer; indicates session start and stop,
  as well as accounting on and off)
Delay Time (Integer; time client has been trying to send)
Input Octets (Integer; in stop record, octets received from port)
Output Octets (Integer; in stop record, octets sent to port)
Session ID (Integer; unique ID linking start and stop records)
Authentication (Integer; indicates how user was authenticated)
Session Time (Integer; in stop record, seconds of received service)
Input Packets (Integer; in stop record, packets received from port)
Output Packets (Integer; in stop record, packets sent to port)
Termination Cause (Integer; in stop record, indicates termination cause)
Multi-Session ID (String; for linking of multiple related sessions)
Link Count (Integer; number of links up when record was generated)
NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)

but since this default format isn't extensible, it can't easily be adapted to protocols other than RADIUS, to services other than dialup (i.e. dedicated connections), or to rated events (i.e. file downloads) 😬. this is a serious limitation, and as a result customers have requested a more general accounting record format 🥺.

7.11.2. Transfer mechanism 🚚

before being transferred, the accounting records are compressed to save bandwidth 🗜️. the records are transferred via FTP, and the transfer is initiated by the receiving party rather than the sending party. the local ISP keeps a duplicate set of records for verification purposes 🔍.

8. Merit Network Implementation 🌐

8.1. Overview 🦋

MichNet is a regional IP backbone network operated within the state of Michigan by Merit Network, Inc., a nonprofit corporation based in Ann Arbor, Michigan. Started in 1966, MichNet currently provides backbone level Internet connectivity and dial-in IP services to its member and affiliate universities, colleges, K-12 schools, libraries, government institutions, other nonprofit organizations, and commercial business entities 🎓.

as of May 1, 1997, MichNet had 11 members and 405 affiliates. its shared dial-in service operated 133 sites in Michigan and one in Washington, D.C, with 4774 dial-in lines. additional dial-in lines and sites are being installed daily 📈.

MichNet also provides national and international dial-in services to its members and affiliates through an 800 number and other external services, which it contracts with national and global service providers 🌍.

the phone numbers of all MichNet shared dial-in sites are published on the Merit web site and in the MichNet newsletters. Merit also provides links to information about the national and international service sites through their respective providers' web sites. that information can be found at http://www.merit.edu/mich-net/shared.dialin/ 🎀

8.1.1. MichNet State-Wide Shared Dial-In Services ✨

okay bestie, so every MichNet shared dial-in service site is run by either Merit or one of its member or affiliate orgs 🏠 and all sites must support PPP and Telnet connections 📞 no cap, that's the baseline 💅

each org in the shared dial-in service gets a realm-name 🎀 usually it looks like a fully qualified domain name. users identify themselves with a MichNet AccessID, which is their local id + "@" + the realm-name, so something like user@realm 🦋

Merit runs a set of AAA servers that speak RADIUS 🔐 these are the core servers. they support every dial-in site and act as proxy servers for the AAA servers at participating orgs 🧚 for security reasons, only Merit staff run the core servers. this matters because the user password is in the clear when the proxy core server decodes an incoming request, then re-encodes it and forwards it on again 🙈 so yeah, trust is kind of the whole vibe here 🫶

the core servers also enforce one common policy across all dial-in servers 👑 the big one is that each provider of access must make dial-in ports available to others when the provider's own users don't need them. to make that work, the proxy server treats realms as either owners or guests 🌸

one piece of deciding whether the provider's org needs the port is that the proxy core server tracks which realms are connected to each session on a given huntgroup 🔍 if there are only a few ports free (how "few" is defined is by a formula), guests get denied 🚫 guests also get a time limit and their sessions get cut after a while: currently one hour during prime time, two hours during non-prime time ⏰

the other piece is capping how many guests can connect at all 🧮 this happens by limiting simultaneous guest sessions per realm. each realm gets a number of "simultaneous access tokens", aka SATs 🪙 when a guest session is authorized, the end server for the realm decrements its available SATs, and when the session ends, the SAT count goes back up 📈 if a session is going to be a "guest" and needs a SAT, the core adds a Merit-specific attribute to the request 💜 the end server must reply with an attribute naming the "token pool" the session's token comes from 🎯 the end result? total guests across the whole network are limited to the total tokens allocated to all realms. iconic, honestly 🔥

each realm is authenticated and authorized by its own AAA server 🏰 the proxy core servers forward requests to the right one using a configuration file that says where each realm gets authenticated 🗺️ requests from realms that aren't in that config get dropped 🗑️

the Merit AAA server software supports all of this policy 💖 Merit gives this software to member and affiliate orgs. it's designed to play nice with lots of existing authentication servers, like Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS 🧚 so most institutions can just keep using whatever auth mechanism they already have ✨

8.1.2. MichNet National and International Dial-In Services 🌍

okay so beyond the shared service, Merit also lets people dial in from outside Michigan by connecting to other dial-in services 🛫 these are usually billed by connect time ⏱️ Merit acts as the accounting agent between its members and affiliates and the outside service provider 🧾

right now the supported services are a national 800 number and service through the ADP/Autonet dial-in network 📱 an IBM/Advantis connection is being tested, and a few other service interconnects are being looked into 🔬

when a member or affiliate user calls one of these external dial-in services, the call gets authenticated like this: each external service forwards RADIUS authentication requests and accounting messages to a Merit proxy core server 💌 the core forwards the request to the member or affiliate's server for approval 🙋‍♀️ session records get logged at both the Merit core server and the member or affiliate server 📒 Merit bills members and affiliates monthly based on the accounting logs 💸 and the members and affiliates are responsible for rebilling their own users 🫠

the Merit AAA software can ask for positive confirmation that charges were accepted ✅ and it has tools for piling up and reporting usage by realm and by user 📊 very organized, very serious, very cute 🎀

8.2. Authentication and Authorization 🔑

okay the vibe for auth: Telnet sessions use the classic id and password method, where the id is a MichNet AccessID in the form user@realm 💻 PPP sessions can be authenticated either with an AccessID and password inside a script, or with PAP 🧩 challenge/response auth using EAP is still in development 🚧 coming soon, bestie 🫶

here's the flow when a user dials into a MichNet shared dial-in port 📞 the NAS sends an Access-Request to a core AAA server using RADIUS 📨 first the core server applies any relevant huntgroup access policies to the request 🛡️ if the request fails that policy check, an Access-Reject goes back to the NAS 🙅‍♀️ otherwise, the core forwards it to the user's home authentication server based on their realm 🏡 the home server authenticates and authorizes the request and sends back an Access-Accept or Access-Reject to the core 📬 if it's an Access-Accept, the home server creates a dial-in session identifier that's unique to this session and puts it in a Class attribute inside that Access-Accept 🪪 the core looks at the original request and the home server's response again and decides to accept or reject 🤔 then the core sends either an Access-Accept or Access-Reject to the NAS, and that's the end of that 🎬

when a user dials into a contracted ISP's huntgroup (MichNet National and International Service), the ISP sends a RADIUS access request to a Merit core server 🛰️ the rest of the auth and authz path is the same as the shared dial-in service, except two things change 🧠 no huntgroup access policy gets applied, and a Huntgroup-Service attribute gets sent to the home auth server with its value set to the name of the service 🏷️ the home server must return a copy of that attribute with a flag appended to the original value, to show it positively authorized the user's access to that service ✅ this is giving very precise handshake energy 🤝

the shared dial-in service usually needs some kind of authorization 💅 for example, a user dialing into a huntgroup as a guest must be authorized with a token from their realm 🎟️ participating institutions get to define their own authorization rules 👑 right now, authorization can be based on any combo of the user's group status and account status 🧩 there's also a set of programming interfaces for plugging in new authorization policies 🔌 extendable, no notes 💖

8.3. Accounting 🧾

in the Merit AAA server, a session starts the moment the user connects to the NAS and ends when they disconnect ⏳ during the session, both the core server and the home server keep track of its status 👀 this lets the AAA servers apply policies based on current status, like limiting guest access by realm to the number of available tokens, or capping simultaneous sessions for a given AccessID 🚦 info like whether the session is a guest, whether it used a token, and other details gets included with the accounting stop info when it's logged 📝 Merit made enhancements to RADIUS, local to the AAA server, to support keeping session status around 🛠️

when a user session is successfully authenticated, the NAS sends a RADIUS accounting start request to the core server 🚀 the core forwards it to the user's home server 🏠 the home server updates the session's status and replies to the core, and the core replies to the NAS 💌 in that accounting start request, a NAS that follows the RADIUS spec must send back the Class attribute and value it got in the Access-Accept for the session 🔁 that's how the home server's dial-in session identifier comes back around 🪄

when a user ends a session, an accounting stop request goes through the same path 🔚 the NAS sends the dial-in session identifier back again, which gives a way to uniquely identify a session 🆔 by configuring the finite state machine in each AAA server, any accounting requests can be logged by whichever server receives them 🧠

since the same session logs exist on every server along a session's auth and accounting path, reconciling specific sessions is pretty easy to sort out 🧹 for the shared dial-in service there are no usage charges 🆓 Merit has tools to check that organizations don't authorize more guest sessions than the SATs allocated to them 🔎 for surcharged sessions, Merit sends each org a summary bill every month 📆 detailed session record files are available for solving problems 🕵️‍♀️ each org is responsible for billing its own users, and should have the same session records Merit collects 📚

Merit gets a monthly invoice from other dial-in service providers and pays them directly 💳 but only after checking that the charges match the session records Merit logged ✔️ accurate, fair, periodt 💅

8.4. Software and Development 🛠️

so Merit built the AAA server software that does all of the above 🎉 it started by modifying the RADIUS server that Livingston provided 🧱 later, Merit basically rewrote almost all of it so enhancing and extending capabilities would be way easier 🌈 Merit offers a basic version of the server for free for noncommercial use 🆓

Merit also started the Merit AAA Server Consortium 🤝 it includes Merit plus a bunch of NAS vendors, ISPs, and server software vendors 🏢 the consortium supports ongoing development of the Merit AAA server ✨ the goal is a server that does proxy and end server work, is feature rich, and interoperates with major vendors' NAS products 💜

the building block of the Merit AAA server is the Authentication/Authorization Transfer Vector (AATV) 🧚 it's a seriously powerful concept that gives the server ultimate modularity and flexibility 🦋 the structure and methods of the AATV model are published with every version of the AAA server 📖

objects for extending the authorization server are also in the enhanced version of the AAA server 🧩 Merit is also exploring a way to extend the AAA server in its executable form, to boost efficiency and scalability, and to get better monitoring, instrumentation, and administration of the server 📈🫶

9. FidoNet implementation ✨

okay so FidoNet has been doing phone book syncing since 1984 📞✨, and it's up to around 35,000 member nodes now 🌸. it's a non-IP dialup network, so it doesn't give members IP services and doesn't use IP-based authentication tech 🙈. instead, member nodes run bulletin-board services, like mail and conferences called echoes 💬.

to talk to each other, FidoNet member systems need a synchronized phone book called the Nodelist 📖. the Nodelist lets you turn FidoNet addresses (written like zone:network/node, for example 1:161/445) into phone numbers 📱. since it's dialup, phone numbers are literally needed to deliver mail and conference traffic 💀.

to keep the weekly sync from being a nightmare 😭, the weekly Nodelist updates are sent as difference files called the Nodediff. when you apply the Nodediff to last week's Nodelist, you get this week's Nodelist 🔥. the Nodediffs also get compressed before transfer so they move faster 🏃‍♀️.

info on FidoNet, FidoNet Technical Standards (FTS) documents (including the Nodelist specification), and standards proposals is available from the FidoNet archive at http://www.fidonet.org/ 🦋.

9.1. Scaling issues

okay this part is giving math 🤓. with 35,000 entries, the FidoNet Nodelist is now 3.1 MB, and the weekly Nodediffs are 175 KB. compressed, the Nodelist is about 1 MB and the weekly Nodediff is 90 KB 🗜️. so transferring the Nodediff takes roughly 45 seconds over a 28,800 bps modem. that's a whole vibe 🕰️.

to level up scalability 📈, the domain name service approach is looked at in [8]. the proposal envisages a capability analogous to the DNS ISDN record, used to map names to phone numbers, plus an extra record to hold the attributes linked to a given name 🧚.

9.2. Phone number presentation

so FidoNet member systems do the phone book syncing for you 🙌, which means users only need to know the FidoNet address of the systems they want to contact. users don't have to keep their own copy of the Nodelist 💅. this is kind of like the Internet, where the DNS handles the domain name to IP address mapping so you don't have to memorize IP addresses 🫶.

still, FidoNet systems like being able to show lists of nodes 📋. so Nodelist compilers usually make two versions: one that can be searched or displayed online, and one that the system dialer uses 💜.

9.2.1. FidoNet Nodelist format

the FidoNet Nodelist format is documented in detail in [3] 📚. the Nodelist file is made of data lines and comment lines, and comment lines start with a semi-colon ✨. the first line is a general interest comment line with the date and the day number, plus a 16-bit CRC 🔢. the CRC is there so the system building the new Nodelist can check that it's intact 🛡️.

every Nodelist data line has eight comma-separated fields, and here they are 👀:

Keyword
Zone/Region/Net/Node number
Node name
Location
Sysop name
Phone number
Maximum Baud rate
Flags (optional)

FidoNet Nodelists are arranged geographically 🗺️, so systems in the same zone, region, and network get grouped together. that means no separate regions file is needed 🙅‍♀️. the keyword field can be used to show that a system is temporarily out of service 🚧.

[3] goes into the Nodelist flags in a lot of detail 🤯. the flags include info on supported modem modulation and error correction protocols 🔊. [4] also proposes a series of ISDN capability flags, and [5] proposes flags showing a node's online times ⏰.

9.3. Phone number exchange

FidoNet coordinators are in charge of keeping their networks, regions, and zones up to date 👑. every week, network coordinators send their regional coordinators updated versions of their portions of the Nodelist 📨. the regional coordinators compile what their network coordinators sent and submit it to the zone coordinator 🗂️. then the zone coordinators exchange their submissions to make the new Nodelist 🔄. the catch is that the view from different zones can differ at any given time 👀.

9.3.1. The Nodediff

the Nodediff format is discussed in detail in [3] 📖. when preparing Nodediffs, network coordinators may send only their difference updates, and those can be collated to produce the Nodediff directly 🧩.

one weakness here is that the coordinator submissions have no security applied to them 😬. this leaves the door open for fraudulent updates to spread 🚨. to deal with that, [6] proposes adding a shared secret to the update files 🔐.

9.3.2. Addition of nodes

to get a FidoNet address and a spot in the Nodelist 🎀, a system has to prove it's functioning by sending mail to its local network coordinator 📬. once the local network coordinator gets the application, they allocate a new FidoNet address and add a Nodelist entry ✨.

9.3.3. Deletion of nodes

nodes are required to be functioning during the zone mail hour so they can receive mail 📭, and they get the weekly Nodelist from their local network coordinators every week 📅. so there's a built-in way to spot non-functional nodes 🕵️‍♀️.

nodes found to be down get reported to the local network coordinator and then marked as down in the Nodelist 🪦. nodes that stay down for more than two weeks may be removed from the Nodelist, at the network coordinator's discretion ⚖️.

9.4. Phone book update

the Nodelist holds the phone numbers and attributes of every participating system 📇. new Nodelists come out on Fridays 🎉. local network coordinators make them available to participating systems, and they get them from the regional and zone coordinators 🤝.

it's standard practice for participating systems to get their Nodelists from their local network coordinators 💖. but if the local network coordinator isn't available for some reason, the updates or the full Nodelist can be picked up from other network or regional coordinators 🙏. please note that since the view from different zones may differ, nodes that want to update their Nodelists should not contact systems outside their zone 🚫.

9.5. Phone book compilation

once FidoNet systems have the Nodediff, they apply it to the previous week's Nodelist to make a new one 🪄. to receive Nodediffs and compile the Nodelist, you need the following software 💻:

  • A FidoNet-compatible mailer implementation, used to transfer files
  • A Nodelist compiler

the Nodelist compiler does two jobs 🧑‍🍳. first, it applies Nodediffs to the previous Nodelist to produce an updated one. second, it compiles the updated Nodelist into the format the member system's mailer implementation needs 🎯. it's important to note that while the Nodelist and Nodediff formats are standardized (FTS-0005), and so is the file transfer protocol (FTS-0001), the compiled format each mailer uses is implementation dependent 🫠.

one reason compiled formats differ is that out of band information gets added to the Nodelist during compilation 🕶️. that extra info includes phone call costs and shared secrets 💰.

9.5.1. Cost data

cost info isn't part of the Nodelist 🙅‍♀️, but when a Nodelist compiler turns the Nodelist into the mailer's format, it supports adding cost info 💸. the mailer then uses that info to guide its behavior 🧭.

phone call costs depend on the rates the local phone company charges 📞. so this info is local in nature and usually gets typed into the Nodelist compiler's configuration file by the system administrator 🛠️.

9.5.2. Shared secrets

in FidoNet, shared secrets are used for authenticated sessions between systems 🔑. these sessions matter a lot between the local, regional, and zone coordinators, since they're the ones preparing and sending the Nodediffs 🥹. only a single shared secret is used per system 🫶.

9.6. Accounting

in FidoNet, accounting mostly comes from local, regional, and zone coordinators needing to get their expenses reimbursed 💵. to support that, utilities have been built to account for network usage at the system level based on various metrics 📊. the accounting techniques are not applied at the user level though 🙃. distributed authentication and accounting are not implemented, so users may not roam between systems 🧳❌.

10. Acknowledgements

thank you to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of AimQuest for the useful chats about this problem space 🫶💕.

Security Considerations

🔒 security is serious business, bestie. the security issues are discussed in sections 5.6 and 6.5 of this document, so go read those before you do anything else 😤.

11. References

[1] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, Microsoft, December 1995.

[2] Fielding, R., et al., "Hypertext Transfer Protocol - HTTP/1.1.", RFC 2068, UC Irvine, January, 1997.

[3] Baker, B., R. Moore, D. Nugent. "The Distribution Nodelist." FTS-0005, February, 1996.

[4] Lentz, A. "ISDN Nodelist flags." FSC-0091, June, 1996.

[5] Thomas, D. J. "A Proposed Nodelist flag indicating Online Times of a Node." FSC-0062, April, 1996.

[6] Kolin, L. "Security Passwords in Nodelist Update Files." FSC-0055, March, 1991.

[7] Gwinn, R., D. Dodell. "Nodelist Flag Changes Draft Document." FSC-0009, November, 1987.

[8] Heller, R. "A Proposal for A FidoNet Domain Name Service." FSC-0069, December, 1992.

[9] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, Livingston, Merit, Daydreamer, January 1997.

[10] Rigney, C., "RADIUS Accounting", RFC 2059, Livingston, January 1997.

12. Authors' Addresses ✨

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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

Juan Lu
AimQuest Corporation
1381 McCarthy Blvd.
Milpitas, California 95035

Phone: 408-273-2730  ext. 2762
EMail: juanlu@aimnet.net


John Alsop
i-Pass Alliance Inc.
650 Castro St., Suite 280
Mountain View, CA 94041

Phone: 415-968-2200
Fax:   415-968-2266
EMail: jalsop@ipass.com

James Ding
Asiainfo
One Galleria Tower
13355 Noel Road, #1340
Dallas, TX 75240

Phone: 214-788-4141
Fax:   214-788-0729
EMail: ding@bjai.asiainfo.com

Wei Wang
Merit Network, Inc.
4251 Plymouth Rd., Suite C
Ann Arbor, MI 48105-2785

Phone: 313-764-2874
EMail: weiwang@merit.edu
📦 where this page comes from