NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
However, since this default format is not extensible, it cannot
easily be adapted to protocols other than RADIUS, services other than
dialup (i.e. dedicated connections) or 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
Prior to being transferred, the accounting records are compressed so
as to save bandwidth. The transfer of accounting records is handled
via FTP, with the transfer being initiated by the receiving party,
rather than by the sending party. A duplicate set of records is kept
by the local ISP 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 contracting with national and global service providers.
The phone numbers of all MichNet shared dial-in sites are published
both 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. Such
information can be found at http://www.merit.edu/mich-
net/shared.dialin/.
8.1.1. MichNet State-Wide Shared Dial-In Services
Each MichNet shared dial-in service site is owned and maintained by
either Merit or by a member or affiliate organization. All sites must
support PPP and Telnet connections.
Each organization participating in the shared dial-in service is
assigned a realm-name. Typically the realm-name resembles a fully
qualified domain name. Users accessing the shared dial-in service
identify themselves by using a MichNet AccessID which consists of
their local id concatenated with "@" followed by the realm-name -
e.g. user@realm
Merit operates a set of Authentication, Authorization and Accounting
(AAA) servers supporting the RADIUS protocol which are called core
servers. The core servers support all the dial-in service sites and
act as proxy servers to other AAA servers running at the
participating organizations. For security reasons, Merit staff run
all core servers; in particular, the user password is in the clear
when the proxy core server decodes an incoming request and then re-
encodes it and forwards it out again,
The core servers also enforce a common policy among all dial-in
servers. The most important policy is that each provider of access
must make dial-in ports available to others when the provider's own
users do not have a need for them. To implement this policy, the
proxy server distinguishes between realms that are owners and realms
that are guests.
One piece of the policy determining whether the provider's
organization has need of the port, is implemented by having the proxy
core server track the realms associated with each of the sessions
connected at a particular huntgroup. If there are few ports available
(where few is determined by a formula) then guests are denied access.
Guests are also assigned a time limit and their sessions are
terminated after some amount of time (currently one hour during prime
time, two hours during non-prime time).
The other part of the policy is to limit the number of guests that
are allowed to connect. This is done by limiting the number of
simultaneous guest sessions for realms. Each realm is allocated a
number of "simultaneous access tokens" - SATs. When a guest session
is authorized the end server for the realm decrements the count of
available SATs, and when the session is terminated the count of SATs
is incremented. A Merit specific attribute is added to the request
by the core if the session will be a "guest" and will require a SAT.
The end server must include a reply with an attribute containing the
name of the "token pool" from which the token for this session is
taken. The effect of this is to limit the number of guests connected
to the network to the total number of tokens allocated to all realms.
Each realm is authenticated and authorized by its own AAA server. The
proxy core servers forward requests to the appropriate server based
on a configuration file showing where each realm is to be
authenticated. Requests from realms not in the configuration are
dropped.
The Merit AAA server software supports this policy. Merit provides
this software to member and affiliate organizations. The software is
designed to work with many existing authentication servers, such as
Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS. This
enables most institutions to utilize the authentication mechanism
they have in place.
8.1.2. MichNet National and International Dial-In Services
In addition to the MichNet shared dial-in service, Merit also
provides access from locations outside of Michigan by interconnecting
with other dial-in services. These services are typically billed by
connect time. Merit acts as the accounting agent between its member
and affiliate organizations and the outside service provider.
The services currently supported are a national 800 number and
service via the ADP/Autonet dial-in network. Connection with
IBM/Advantis is being tested, and several other service interconnects
are being investigated.
Calls placed by a Merit member/affiliate user to these external
dial-in services are authenticated by having each of those services
forward RADIUS authentication requests and accounting messages to a
Merit proxy core server. The core forwards the requests to the
member/affiliate server for approval. Session records are logged at
the Merit core server and at the member/affiliate erver. Merit bills
members/affiliates monthly, based on processing of the accounting
logs. The members and affiliates are responsible for rebilling their
users.
The Merit AAA software supports the ability to request positive
confirmation of acceptance of charges, and provides tools for
accumulating and reporting on use by realm and by user.
8.2. Authentication and Authorization
Authentication of a Telnet session is supported using the traditional
id and password method, with the id being a MichNet AccessID of the
form user@realm, while a PPP session may be authenticated either
using an AccessID and password within a script, or using PAP.
Support for challenge/response authentication mechanisms using EAP is
under development.
When a user dials into a MichNet shared dial-in port, the NAS sends
an Access-Request to a core AAA server using the RADIUS protocol.
First the core server applies any appropriate huntgroup access
policies to the request. If the Request fails the policy check, an
Access-Reject is returned to the NAS. Otherwise, the core server
forwards it to the user's home authentication server according to the
user's realm. The home authentication server authenticates and
authorizes the access request. An Access-Accept or Access-Reject is
sent back to the core server. If an Access-Accept is sent, the home
server will create a dial-in session identifier which is unique to
this session and insert it in a Class attribute in the Access-Accept.
The core server looks at the request and the response from the home
server again and decides either to accept or reject the request.
Finally, the core server sends either an Access-Accept or Access-
Reject to the NAS.
When a user dials into a contracted ISP's huntgrup (MichNet National
and International Service), the ISP sends a RADIUS access request to
a Merit core server. The rest of the authentication and authorization
path is the same as in the shared dial-in service, except that no
huntgroup access policy is applied but a Huntgroup-Service attribute
is sent to the home authentication server with its value being the
name of the service, and a copy of the attribute must be returned by
the home server with a flag appended to the original value to
indicate a positive authorization of user access to the specified
service.
The MichNet shared dial-in service typically requires authorization
of some sort, for example, a user dialing into a huntgroup as a guest
must be authorized with a token from the user's realm. Participating
institutions have control in defining authorization rules. Currently
authorization may be done using any combination of the user's group
status and user's account status. A set of programming interfaces is
also provided for incorporating new authorization policies.
8.3. Accounting
In the Merit AAA server, a session is defined as starting from the
moment the user connects to the NAS, and ending at the point when the
user disconnects. During the course of a session, both the core
server and the home server maintain status information about the
session. This allows the AAA servers to apply policies based on the
current status, e.g. limit guest access by realm to number of
available tokens, or to limit number of simultaneous sessions for a
given AccessID. Information such as whether the session is for a
guest, whether it used a token, and other information is included
with the accounting stop information when it is logged. Merit has
made enhancements to the RADIUS protocol, that are local to the AAA
server, to support maintenance of session status information.
When a user session is successfully authenticated, the NAS sends out
a RADIUS accounting start request to the core server. The core server
forwards that request to the user's home server. The home server
updates the status of the session and then responds to the core. The
core server in turn responds to the NAS. In the accounting Start
request, a NAS conforming to the RADIUS specification must return the
Class attribute and value it received in the Access-Accept for the
session, thus sending back the dial-in session identifier created by
the session's home server.
When a user ends a session, an accounting stop request is sent
through the same path. the same path. The dial-in session
identifier is again returned by the NAS, providing a means of
uniquely identifying a session. By configuring the finite state
machine in each of the AAA servers, any accounting requests may be
logged by any of the servers where the accounting requests are
received.
Because the same session logs are available on every server in the
path of a session's authorization and accounting message, problems
with reconciliation of specific sessions may be resolved easily. For
the shared dial-in service, there are no usage charges. Merit has
tools to verify that organizations do not authorize more guest
sessions than the number of SATs allocated to the organization. For
surcharged sessions, Merit sends each organization a summary bill
each month. Files with detail session records are available for
problem resolution. Each organization is responsible for billing its
own users, and should have the same session records as are collected
by Merit.
Merit receives a monthly invoice from other dial-in service providers
and pays them directly, after first verifying that the charges
correspond to the session records logged by Merit.
8.4. Software and Development
Merit has developed the AAA server software which supports the above
capabilities initially by modifying the RADIUS server provided by
Livingston, and later by doing a nearly total rewrite of the software
to make enhancement and extension of capabilites easier. Merit makes
a basic version of its server freely available for noncommercial use.
Merit has started the Merit AAA Server Consortium which consists of
Merit and a number of NAS vedors, ISPs and server software vendors.
The consortium supports ongoing development of the Merit AAA server.
The goal is to build a server that supports proxy as well as end
server capabilities, that is feature rich, and that interoperates
with major vendors' NAS products.
The building block of the Merit AAA server, the
Authentication/Authorization Transfer Vector (AATV), is a very
powerful concept that enables the ultimate modularity and flexibility
of the AAA server. The structure and methods of the AATV model are
published with all versions of the AAA server.
Objects for extending the authorization server are also available in
the enhanced version of the AAA server. Merit is also looking at ways
to provide a method of extending the AAA server in its executable
form, to improve the server efficiency and scalability, and to
provide better monitoring, instrumentation and administration of the
server.
9. FidoNet implementation
Since its birth in 1984, FidoNet has supported phone book
synchronization among its member nodes, which now number
approximately 35,000. As a non-IP dialup network, FidoNet does not
provide IP services to members, and does not utilize IP-based
authentication technology. Instead member nodes offer bulletin-board
services, including access to mail and conferences known as echoes.
In order to be able to communicate with each other, FidoNet member
systems require a sychronized phone book, known as the Nodelist. The
purpose of the Nodelist is to enable resolution of FidoNet addresses
(expressed in the form zone:network/node, or 1:161/445) to phone
numbers. As a dialup network, FidoNet requires phone numbers in
order to be deliver mail and conference traffic.
In order to minimize the effort required in regularly synchronizing a
phone book of 35,000 entries, the weekly Nodelist updates are
transmitted as difference files. These difference files, known as
the Nodediff, produce the Nodelist for the current week when applied
to the previous week's Nodelist. In order to minimize transfer time,
Nodediffs are compressed prior to transfer.
Information on FidoNet, as well as FidoNet Technical Standards (FTS)
documents (including the Nodelist specification) and standards
proposals are available from the FidoNet archive at
http://www.fidonet.org/.
9.1. Scaling issues
With a Nodelist of 35,000 entries, the FidoNet Nodelist is now 3.1 MB
in size, and the weekly Nodediffs are 175 KB. In compressed form, the
Nodelist is approximately 1 MB, and the weekly Nodediff is 90 KB. As
a result, the transfer of the Nodediff takes approximately 45 seconds
using a 28,800 bps modem.
In order to improve scalability, the implementation of a domain name
service approach is examined in [8]. The proposal evisages use of a
capability analagous to the DNS ISDN record in order to map names to
phone numbers, coupled with an additional record to provide the
attributes associated with a given name.
9.2. Phone number presentation
While FidoNet member systems perform hone book synchronization, users
need only know the FidoNet address of the systems they wish to
contact. As a result users do not need to maintain copies of the
Nodelist on their own systems. This is similar to the Internet, where
the DNS takes care of the domain name to IP address mapping, so that
users do not have to remember IP addresses.
Nevertheless, FidoNet systems often find it useful to be able to
present lists of nodes, and as a result, FidoNet Nodelist compilers
typically produce a representation of the Nodelist that can be
searched or displayed online, as well as one that is used by the
system dialer.
9.2.1. FidoNet Nodelist format
The FidoNet Nodelist format is documented in detail in [3]. The
Nodelist file consists of lines of data as well as comment lines,
which begin with a semi-colon. The first line of the Nodelist is a
general interest comment line that includes the date and the day
number, as well as a 16-bit CRC. The CRC is included so as to allow
the system assembling the new Nodelist to verify its integrity.
Each Nodelist data line contains eight comma separated fields:
Keyword
Zone/Region/Net/Node number
Node name
Location
Sysop name
Phone number
Maximum Baud rate
Flags (optional)
FidoNet Nodelists are arranged geographically, with systems in the
same zone, region, and network being grouped together. As a result,
FidoNet Nodelists do not require a separate regions file. Among other
things, the keyword field can be used to indicate that a system is
temporarily out of service.
Reference [3] discusses Nodelist flags in considerable detail. Among
other things, the flags include information on supported modem
modulation and error correction protocols. Reference [4] also
proposes a series of ISDN capability flags, and [5] proposes flags to
indicate times of system availability.
9.3. Phone number exchange
FidoNet coordinators are responsible for maintaining up to date
information on their networks, regions, and zones. Every week network
coordinators submit to their regional coordinators updated versions
of their portions of the Nodelist. The regional coordinators then
compile the submissions from their network coordinators, and submit
them to the zone coordinator. The zone coordinators then exchange
their submissions to produce the new Nodelist. As a result, it is
possible that the view from different zones may differ at any given
time.
9.3.1. The Nodediff
The format of the Nodediff is discussed in detail in [3]. In
preparing the Nodediffs, network coordinators may transmit only their
difference updates, which can be collated to produce the Nodediff
directly.
One weakness in the current approach is that there is no security
applied to the coordinator submissions. This leaves oen the
possibility of propagation of fraudulent updates. In order to address
this, [6] proposes addition of a shared secret to the update files.
9.3.2. Addition of nodes
In order to apply for allocation of a FidoNet address and membership
in the Nodelist, systems must demonstrate that they are functioning
by sending mail to the local network coordinator. Once the local
network coordinator receives the application, they then allocate a
new FidoNet address, and add a Nodelist entry.
9.3.3. Deletion of nodes
Since FidoNet nodes are required to be functioning during the zone
mail hour in order to receive mail, and since nodes receive the
weekly Nodelist from their local network coordinators on a weekly
basis, there is a built-in mechanism for discovery of non-functional
nodes.
Nodes found to be down are reported to the local network coordinator
and subsequently marked as down within the Nodelist. Nodes remaining
down for more than two weeks may be removed from the Nodelist, at the
discretion of the network coordinator.
9.4. Phone book update
The Nodelist contains the phone numbers and associated attributes of
each participating system. New Nodelists become available on Fridays,
and are made available to participating systems by their local
network coordinators, who in turn receive them from the regional and
zone coordinators.
While it is standard practice for participating systems to get their
Nodelists from their local network coordinators, should the local
network coordinator not be available for some reason, either the
updates or the complete Nodelist may be picked up from other network,
or regional coordinators. Please note that since the view from
different zones may differ, nodes wishing to update their Nodelists
should not contact systems from outside their zone.
9.5. Phone book compilation
Once FidoNet systems have received the Nodediff, the apply it to the
previous week's Nodelist in order to prepare a new Nodelist. In
order to receive Nodediffs and compile the Nodelist, the following
software is required:
A FidoNet-compatible mailer implementation, used to transfer files
A Nodelist compiler
One of the purposes of the Nodelist compiler is to apply Nodediffs to
the previous Nodelist in order to produce an updated Nodelist. The
other purpose is to compile the updated Nodelist into the format
required by the particular mailer implementation used by the member
system. It is important to note that while the Nodelist and Nodediff
formats are standardized (FTS-0005), as is the file transfer protocol
(FTS-0001), the compiled format used by each mailer is implementation
dependent.
One reason that compiled formats to differ is the addition of out of
band information to the Nodelist during the compilation process.
Added information includes phone call costs as well as shared
secrets.
9.5.1. Cost data
Although cost information is not part of the Nodelist, in compiling
the Nodelist into the format used by the mailer, Nodelist compilers
support the addition of cost information. This information is then
subsequently used to guide mailer behavior.
Since phone call costs depend on the rates charged by the local phone
company, this information is local in nature and is typically entered
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. Such authenticated sessions are particularly
important between the local, regional and zone coordinators who
handle preparation and transmission of the Nodediffs. A single shared
secret is used per system.
9.6. Accounting
Within FidoNet, the need for accounting arises primarily from the
need of local, regional and zone coordinators to be reimbursed for
their expenses. In order to support this, utilities have been
developed to account for network usage at the system level according
to various metrics. However, the accounting techniques are not
applied at the user level. Distributed authentication and acounting
are not implemented and therefore users may not roam between systems.
10. Acknowledgements
Thanks to Glen Zorn of Microsoft and Lynn Liu and Tao Wang of
AimQuest for useful discussions of this problem space.
Security Considerations
Security issues are discussed in sections 5.6 and 6.5.
11. References
[1] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses", RFC1877, Microsoft, December 1995.
[2] Fielding, R., et al., "Hypertext Transfer Protocol - HTTP/1.1.",
RFC2068, 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)", RFC2058, Livingston,
Merit, Daydreamer, January 1997.
[10] Rigney, C., "RADIUS Accounting", RFC2059, 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