Jacques Caron
INTERNET-DRAFT IP Sector Technologies
Expires: October 2002 April 2002
DNS-based roaming
<draft-caron-dns-based-roaming-00.txt>
1 Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2 Abstract
To achieve global roaming, that is, allow any client of any service
provider (the home network) to use the facilities of any other
network provider (the foreign network), it is necessary to enable
the foreign network to find AAA facilities able to handle requests
for those users, based on the NAI provided. This document documents
such a method, based on DNS.
Table of Contents
1 Status of this Memo..............................................1
2 Abstract.........................................................1
3 Introduction.....................................................2
4 Terminology......................................................3
5 Conventions used in this document................................3
6 Description of the algorithm.....................................3
7 Example..........................................................5
Caron Informational - Expires August 2002 1
INTERNET-DRAFT DNS-based roaming April 2002
8 Security Considerations..........................................6
9 References.......................................................7
10 Author's Addresses..............................................8
3 Introduction
[1] showed that global roaming is required to achieve critical mass
and enable widespread use of public WLAN access technologies, and
more.
Global roaming means that any user of a given service provider (the
home network) should be able to use the facilities of another
service provider (the foreign network). This implies that the
foreign network must be able to charge usage fees, directly or
indirectly, to the home network. This in turn requires that the
foreign network must be able to send AAA (authentication,
authorization and accounting) requests to the home network.
In a restricted roaming environment, this is usually achieved by the
use of a single roaming operator, to which foreign networks send all
non-local requests (the equivalent of a "default route"), and which
then uses static prefix or suffix tables to "route" the requests
towards the appropriate home network. See [2] for details.
Another alternative in such an environment would be direct bilateral
roaming agreements between all operators (as happens for GSM
roaming), but this obviously doesn't scale between tens of thousands
of operators, which will not want to maintain such technical and
commercial relationships with all others directly.
In a global roaming environment, there may be multiple roaming
operators, in hierarchical or lateral relationships, between any
combination of foreign and home networks. Default and static
routing, though useful or even needed in some cases, do not scale to
the requirements of such an environment, and thus require a dynamic
system allowing to find the path between the two endpoints.
It should be noted that it's indeed really a path that needs to be
found, following established relationships between operators, and
not a direct link between a foreign network and a home network, so
as to allow all involved parties to maintain accounting and be able
to do proper compensation.
This document describes a method to achieve this based on DNS. The
rationale for this is that the NAI (Network Access Identifier, [3]),
which is used to identify a roaming user, is derived from a domain
name, and hence the authority and delegation structure of DNS can be
re-used.
Caron Informational - Expires October 2002 2
INTERNET-DRAFT DNS-based roaming April 2002
4 Terminology
Home network The service provider which holds the commercial
relationship with the end user.
Foreign network The service provider which is currently
providing service to the end user.
5 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [4].
6 Description of the algorithm
When a foreign network wants to perform an AAA query for a roaming
user, it needs to construct an AAA request the relevant AAA
protocol, e.g. RADIUS [5,6,7] or diameter [8]. This request will
then be forwarded between different agents (client, proxies, relays
and servers), through the different parties involved, until it
reaches the home network for that user.
The foreign network SHOULD first get the roaming user's NAI by any
means specific to the media used. This might involve PAP, CHAP or
EAP authentication for dialup or VPDN PPP users, EAP within 802.1X
for Ethernet or Wireless Ethernet users, or any other relevant.
The NAI is in the form user@domain, and until the request reaches
the home network for the specified domain, the user part MUST be
ignored and carried transparently, and all routing decisions MUST be
based solely on the domain part.
At each step along the way, any of the following actions can occur:
- the domain is recognized as being local, and the request is
handled based on the user part of the NAI;
- the node handling the request does not perform any intelligent
routing, but only forwards the request towards one single other node
(or several, in a load-sharing or high-availability scenario): this
is similar to "default routing";
- the node has direct knowledge of one or several other nodes that
can handle the request: this is similar to "static routing";
- the node has several possible other nodes it can send the request
to, but no prior configuration enables it to pick which one.
Caron Informational - Expires October 2002 3
INTERNET-DRAFT DNS-based roaming April 2002
The last case is where "dynamic routing" happens. Basically, two
possible scenarios can happen:
- there is a direct relationship between the node trying to route
the request and that which can handle it;
- there is no such relationship, and it is necessary to trace back a
"chain" of relationships up to a node that has a direct
relationship.
To achieve this, administrators of a domain wishing to let users
within that domain (that is, with NAIs having that domain after the
@) roam MUST set up the following records in the zone for their
domain:
- gr-radius is an A record with the address of the AAA server for
that domain;
- gr-up is an A record with the address of a "higher-level" AAA
server that can then forward the request to gr-radius.
A node wishing to forward a request then uses those records by
following these steps:
1. The node looks up A records for "gr-radius.<domain>." in the
DNS, where <domain> is the domain portion of the NAI.
2. If such a record is found, the address is looked up in the peer
table of the node. If this is successful, the request is sent to
that peer, and the lookup stops here.
3. If no such record is found, or if the corresponding address is
not found in the peer table, the node looks up A records for "gr-
up.<domain>." in the DNS.
4. If such a record is found, the address is looked up in the peer
table of the node. If this is successful, the request is sent to
that peer, and the lookup stops here.
5. If no such record is found, of if the corresponding address is
not found in the peer table, the node looks up PTR records for the
address found in the DNS.
6. The process is then restarted using all but the hostname
portion of the name found as the domain.
To avoid infinite loops, the process should never be restarted more
than 15 times.
Caron Informational - Expires October 2002 4
INTERNET-DRAFT DNS-based roaming April 2002
7 Example
Consider the following scenario:
+---+ +---+
|RO1|----|RO2|
+---+ +---+
| |
+---+ +---+
|FN | |ISP|
+---+ +---+
|
+---+
|HN |
+---+
- FN is the foreign network.
- RO1 is a roaming operator, with AAA proxy aaa.roam1.com
[10.0.1.1], serving as "default route" to FN, and having a roaming
agreement with RO2.
- RO2 is another roaming operator, with AAA proxy aaa.roam2.com.
[10.1.1.1], serving domains handled by ISP and its customers.
- ISP is an ISP providing service to an enterprise, with AAA proxy
aaa.isp.com [10.1.2.1], serving domains handled by its customers.
- HN is the home network, with AAA server aaa.bigcompany.com
[10.1.3.1], and serving requests for users in the bigcompany.com
domain.
The following DNS names point to the listed addresses:
gr-radius.bigcompany.com 10.1.3.1
gr-up.bigcompany.com 10.1.2.1
gr-radius.isp.com 10.1.2.1
gr-up.isp.com 10.1.1.1
The following "reverse DNS" entries also exist:
1.2.1.10.in-addr.arpa. aaa.isp.com.
When user@bigcompany.com tries to authenticate with FN, the
following happens:
1. FN only has a relationship with RO1. It "default routes" the
request to RO1.
2. RO1 looks up gr-radius.bigcompany.com, and finds the IP address
10.1.3.1 [aaa.bigcompany.com]. That address does not appear in its
peer table.
Caron Informational - Expires October 2002 5
INTERNET-DRAFT DNS-based roaming April 2002
3. RO1 then looks up gr-up.bigcompany.com, and finds the IP
address 10.1.2.1 [aaa.isp.com]. That address does not exist either
in its peer table.
4. RO1 then looks up the reverse DNS entry for 10.1.2.1 and finds
aaa.isp.com.
5. RO1 then looks up gr-radius.isp.com, and finds 10.1.2.1 again,
which still isn't present in its peer table.
6. RO1 then looks up gr-up.isp.com, and finds 10.1.1.1, which it
finds in its peer table.
7. RO1 then sends the request to that node.
8. RO2 looks up gr-radius.bigcompany.com, and finds the IP address
10.1.3.1 [aaa.bigcompany.com]. That address does not appear in its
peer table.
9. RO2 then looks up gr-up.bigcompany.com, and finds the IP
address 10.1.2.1 [aaa.isp.com]. That address is present in its peer
table, and it forwards the request to it.
10. ISP looks up gr-radius.bigcompany.com, and finds the IP address
10.1.3.1 [aaa.bigcompany.com]. The address is present in its peer
table, and it forwards the request to it.
11. HN receives the request, and recognizes it as local, and
handles it appropriately.
8 Security Considerations
This document assumes that DNS zones are properly secured using
mechanisms described in [].
Caron Informational - Expires October 2002 6
INTERNET-DRAFT DNS-based roaming April 2002
9 References
1 <draft-caron-public-wlan-roaming-issues-00.txt>, J. Caron,
"Public WLAN Roaming Issues", work in progress, February 2002.
2 RFC 2194 B. Aboba, Lu, J., Alsop, J., Ding, J., Wang, W., "Review
of Roaming Implementations.", RFC 2194, September 1997
3 RFC 2486, B. Aboba, Beadles, M., "The Network Access Identifier",
RFC 2486, January 1999.
4 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
5 RFC 2865, C. Rigney, Willens, S., Rubens, A., Simpson, W., "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
6 RFC 2866, C. Rigney, "RADIUS Accounting", RFC 2866, June 2000.
7 RFC 2869, C. Rigney, Willats, W., Calhoun, P., "RADIUS
Extensions", RFC 2869, June 2000.
8 <draft-ietf-aaa-diameter-10-2.txt>, P. Calhoun, Arkko, J.,
Guttman, E., Zorn, G., Louhhney, J., "Diameter Base Protocol",
work in progress, April 2002.
Caron Informational - Expires October 2002 7
INTERNET-DRAFT DNS-based roaming April 2002
10 Author's Addresses
Jacques Caron
IP Sector Technologies
Ecluse 36c
2000 Neuchatel
Switzerland
Phone: +41 79 699 8389
Email: jcaron@ipsector.com
Caron Informational - Expires October 2002 8