Jacques Caron INTERNET-DRAFT IP Sector Technologies Expires: October 2002 April 2002 DNS-based roaming 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.." in the DNS, where 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.." 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 , 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 , 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