ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
                         The Network Access Identifier
     1.  Status of this Memo
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing 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  mate-
     rial or to cite them other than as ``work in progress.''
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   (US  East  Coast),
     (Europe), (US West Coast), or (Pacific Rim).
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-roamops-nai.txt> and  expires June 1, 1997.  Please send comments
     to the authors.
     2.  Abstract
     This document describes issues relating to user identification in pro-
     vision of "roaming capability" for dialup  Internet  users.   "Roaming
     capability"  may  be  loosely defined as the ability to use any one of
     multiple Internet service providers (ISPs), while maintaining  a  for-
     mal,  customer-vendor  relationship  with only one.  Examples of cases
     where roaming capability might be  required  include  ISP  "confedera-
     tions" and ISP-provided corporate network access support.
     3.  Introduction
     Considerable  interest  has  arisen recently in a set of features that
     fit within the general category of  "roaming  capability"  for  dialup
     Internet users.  Interested parties have included:
          Regional  Internet  Service  Providers  (ISPs) operating within a
          particular state or province, looking to  combine  their  efforts
          with  those  of  other regional providers to offer dialup service
          over a wider area.
          National ISPs wishing to combine their operations with  those  of
          one  or  more  ISPs in another nation to offer more comprehensive
     Aboba                                                         [Page 1]

     INTERNET-DRAFT                                        26 November 1996
          dialup service in a group of countries or on a continent.
          Businesses desiring to  offer  their  employees  a  comprehensive
          package of dialup services on a global basis.  Those services may
          include Internet access as well as  secure  access  to  corporate
          intranets via a Virtual Private Network (VPN), enabled by tunnel-
          ing protocols such as PPTP and L2TP.
     This document focuses on issues of  user  identification  for  use  in
     roaming  services.   However,  since roaming and tunneling are closely
     related, it is believed that the considerations  described  here  will
     also be of interest to those working on tunneling.
     3.1.  Terminology
     This document frequently uses the following terms:
     Network Access Identifier
               The  Network Access Identifier (NAI) is the userID submitted
               by the client during the PPP negotiation.  In  roaming,  the
               purpose  of  the  NAI  is to identify the user as well as to
               assist in the routing  of  the  authentication  request.  As
               such,  the  NAI  may  be  presented either in the form of an
               authentication route, or a pointer to such a  route.  Please
               note  that  the  NAI  may not necessarily be the same as the
               user's e-mail address or the userID submitted in an applica-
               tion  layer  authentication  (i.e.  HTTP authentication). In
               order to avoid confusion on  this  point,  a  new  term  was
     Network Access Server
               The  Network  Access Server (NAS) is the device that clients
               dial in order to get access to the network. In  PPTP  termi-
               nology  this  is referred to as the PPTP Access Concentrator
               (PAC), and in L2TP terminology, it is  referred  to  as  the
               L2TP Access Concentrator (LAC).
     RADIUS server
               This   is   a   server   which   provides   for  authentica-
               tion/authorization via the protocol described  in  [3],  and
               for accounting as described in [4].
     RADIUS proxy
               In order to provide for the routing of RADIUS authentication
               and accounting requests, a RADIUS proxy may employed. To the
               NAS,  the  RADIUS  proxy acts as a RADIUS server, and to the
               RADIUS server, the proxy acts as a RADIUS client.
     3.2.  Purpose
     As described in reference [1], there are now at  least  four  services
     implementing  dialup  roaming,  and  the  number  of  Internet Service
     Aboba                                                         [Page 2]

     INTERNET-DRAFT                                        26 November 1996
     Providers involved in roaming consortia is increasing rapidly.
     In order to be able to offer roaming capability, one of  the  require-
     ments  is to be able to identify the user and route the authentication
     request to the user's home RADIUS server. These functions  are  accom-
     plished  via  the  NAI submitted by the user to the NAS in the initial
     PPP authentication.
     This document proposes  syntax  and  semantics  for  the  NAI.  It  is
     expected  that this will be of interest for support of roaming as well
     as tunneling.  For example, references [5] and [6] refer to use of the
     NAI  in  determining the tunnel endpoint. However, these references do
     not provide guidelines for how RADIUS  or  tunnel  routing  is  to  be
     accomplished.  In  order  to  avoid the possibility of conflicting and
     non-interoperable implementations, references [7] and [8] describe how
     RADIUS  and  tunneling protocols may be integrated. This document pro-
     vides guidance in the use of the NAI that  is  relevant  to  both  the
     roaming and tunneling communities.
     4.  Requirements for roaming authentication
     What  requirements  must a roaming authentication scheme satisfy to be
     successful? These include:
     Scalability requirements
               As described in [2], it is highly desirable that  a  roaming
               implementation  be scalable so as to accommodate at least 40
               members within a roaming consortia, each serving at least 10
               corporate  clients. It is also desired than a roaming imple-
               mentation be able to handle an unlimited number of users.
     Ease of administration
               It is desirable that the chosen  NAI  approach  be  easy  to
               administer.  This  means that the number of table entries or
               zone files maintained by service providers  or  corporations
               should be kept to a minimum. It also means that users should
               be forced to change their NAIs only on very rare  occasions.
     Security  The NAI approach taken must be secure, in that it must guard
               against attacks which could result in theft of  service,  or
               submission  of  fraudulent  charges.  In particular, the NAI
               approach must provide for secure determination of the  loca-
               tion of the settlement agent.
     Chain of trust
               A  successful  roaming authentication scheme must be able to
               establish a chain of trust between remote  NAS  devices  and
               home  ISP servers. This can be accomplished via a variety of
               methods, including (in  the  case  of  RADIUS)  hierarchical
               authentication  routing,  or (in the case of certificates) a
               Web of trust. In either case, it is  necessary  that  it  be
               possible  to construct the hierarchical authentication route
     Aboba                                                         [Page 3]

     INTERNET-DRAFT                                        26 November 1996
               or trust Web based on the NAI.  This  does  not  necessarily
               imply  that the NAI is itself a representation of an authen-
               tication route or trust web.
     4.1.  Alternatives for authentication of roaming users
     In order to authenticate roaming users, it is necessary to be able  to
     route  the authentication requests from the NAS of the remote ISP to a
     server maintained by the home ISP. Since the RADIUS protocol  is  com-
     monly  implemented  both by NAS vendors as well as by ISPs, it is pro-
     posed that RADIUS be used as the mechanism for roaming authentication.
     Although  the  choice of RADIUS is expedient, it has significant draw-
     backs.  In particular, routing of RADIUS  authentication/authorization
     messages  is  complicated  by  the security architecture of the RADIUS
     protocol. The RADIUS protocol requires the  maintenance  of  a  shared
     secret between the NAS and the RADIUS server or proxy. Therefore, were
     RADIUS authentication requests to be routed directly, the result would
     be  a  requirement for maintenance of shared secrets between every NAS
     device and every RADIUS server.  This  would  get  out  of  hand  very
     quickly.  As  a  result,  hierarchical  authentication  routing  is  a
     requirement for scalable authentication of roaming users via RADIUS.
     Authentication routes can be maintained by a number of means,  includ-
     ing propagation of configuration files, and as described in this docu-
     ment, use of DNS. Note that even if DNS is used,  configuration  files
     are still necessary, since they provide the RADIUS proxy with the list
     of shared secrets. This list of shared secrets is also a list of  sys-
     tems  whose  owners  have a business relationship with the configuring
     Note that hierarchical authentication routing would not necessarily be
     required  if  an  authentication protocol supporting certificates were
     used. This is because shared secrets would no longer be  necessary  in
     order  for the two authentication endpoints to engage in a secure con-
     versation. Thus a NAS server would be able to  contact  the  home  ISP
     server directly.
     This  is not necessarily as desirable as it seems at first glance. For
     one thing, direct contact between the NAS and the  home  ISP  has  the
     potential  to  exacerbate  interoperability problems since it implies,
     for example, that the  two  end  systems  must  be  running  the  same
     accounting  protocol  and  that  the home ISP's server must be able to
     return configuration attributes that the remote NAS understands.  Thus
     RADIUS proxies are useful for more than just authentication routing.
     Moreover,  even  with  certificates  it is still necessary for the two
     parties to determine whether they have a  business  relationship  with
     each  other.  This is equivalent to verifying the validity of the cer-
     tificate within the web or hierarchy of trust used by the roaming con-
     Aboba                                                         [Page 4]

     INTERNET-DRAFT                                        26 November 1996
     Thus while certificates may provide a way of automating the configura-
     tion process, they do not eliminate it entirely.  In  effect,  use  of
     certificates substitute verification of the chain of trust for routing
     of RADIUS authentication requests.
     Since certificates are not a panacea and we do not yet have a certifi-
     cate  infrastructure  in place, it is recommended that in the short to
     medium term, RADIUS authentication forwarding be used for  authentica-
     tion of roaming users.
     4.2.  Hierarchical authentication routing
     Hierarchical  authentication  routing  is implemented via a multi-tier
     RADIUS proxy system, with individual ISPs running their  own  proxies,
     and  allowing  authentication  requests  to be routed directly only to
     other members of the roaming consortium. This allows ISPs to  maintain
     shared secrets only with the other consortium members, as well as with
     customers with whom they have a direct business relationship.
     For example, let us assume that we have n members of a roaming consor-
     tia,  each of which have m distinct corporate customers whom they wish
     to provide access for.  These corporate  customers  wish  to  maintain
     their  own  RADIUS servers so as to be able to manage their users more
     efficiently. Thus we have n * m corporate entities that wish to  allow
     their  users  to  have access to the facilities of the roaming consor-
     If the RADIUS proxy of a given ISP were to contact each RADIUS  server
     directly,  each  RADIUS  proxy  would  need  to maintain n * m + n - 1
     shared proxy secrets. This is  a  shared  secret  for  each  corporate
     entity,  plus  a  shared secret for each member of the roaming consor-
     tium. For the case of 40 roaming consortia members, each with 10  cor-
     porate  customers, this translates to 439 shared secrets per ISP. This
     would be unmanageable.
     On the other hand,  let  us  assume  that  we  implement  hierarchical
     authentication  routing. In this case, the RADIUS proxy of a given ISP
     would only need to contact the RADIUS proxies of  the  other  ISPs  in
     ISPGROUP as well as the RADIUS servers of its own corporate customers.
     To do this, it would only need to maintain n-1+m shared  secrets.  For
     the  case of 40 roaming consortia members, each with 10 corporate cus-
     tomers, this translates to 49  shared  secrets  per  ISP,  a  dramatic
     5.  Authentication routing
     Given  that  hierarchical  authentication  routing  appears  to  be  a
     requirement, how can this be implemented? Several approaches have been
     suggested. These include:
     Hierarchical naming
     Authentication and Accounting Route (AR) records
     Aboba                                                         [Page 5]

     INTERNET-DRAFT                                        26 November 1996
     We will explore each of these alternatives in turn.
     5.1.  Hierarchical naming
     In  hierarchical naming, a combination of the authentication route and
     the username is used as the NAI. As a result, a RADIUS proxy acquiring
     an  NAI  will  be able to determine the next hop by examination of the
     authentication route. Since an authentication route may have an  arbi-
     trary  number  of hops, the syntax for description of such routes must
     not be limited in the number of hops it can represent.
     While many syntaxes may be used to used to  denote  an  authentication
     route,  in  this  document  it  is proposed that the the "/" separator
     character be used to separate the elements of an authentication route.
     Therefore,  an  authentication route that passed from the roaming con-
     sortium ISPGROUP1 to ISPA  to  BIGCO  would  be  represented  as  ISP-
     GROUP1.COM/ISPA.COM/BIGCO.COM/,   and  the  full  NAI  would  be  ISP-
     This approach has the advantage of being simple. Since the authentica-
     tion  route  is  embedded  within the NAI, no indirection is needed to
     retrieve the route. Since such indirection typically depends on propa-
     gation  of  a  file  or  a lookup in the DNS, it is likely that use of
     indirection will increase code complexity, as well as  introduce  sev-
     eral new error conditions.
     This  approach  also  has several disadvantages. The first of these is
     that if BIGCO changes their ISP relationships, then it  will  need  to
     change  the  NAIs  of its users. In practice it is to be expected that
     corporations will reevaluate their ISP  relationships  on  a  periodic
     basis,  and  that  ISPs will join and leave roaming consortia, so that
     this is likely to be a considerable problem, particularly for ISPs and
     corporations with large numbers of users.
     The second disadvantage is that this representation of the NAI is sub-
     stantially different from a typical e-mail address, which  is  of  the
     form  It also may be possible that BIGCO has multiple
     ISP relationships. This may occur for example, if the ISPGROUP1  roam-
     ing consortia does not cover all of the countries that BIGCO's employ-
     ees wish to visit. In this case, BIGCO may also establish a  relation-
     ship  with  another ISP that is a member of a consortia ISPGROUP2 that
     covers the desired countries. As a  result,  a  single  authentication
     route  embedded  in  the NAI is not adequate to describe the ISP rela-
     tionships of BIGCO.
     In addition, the embedding of a route within the NAI may  not  provide
     information  on  the  settlement  agent  to use for a given route. For
     example, it may be possible that ISPA and  ISPB  are  members  of  two
     roaming  consortia.  In  this case, the route ISPA.COM/BIGCO.COM/ does
     not identify which consortia's billing policies are to  be  in  effect
     for  the length of the call, and which settlement server to submit the
     accounting record to when the session is complete.
     Aboba                                                         [Page 6]

     INTERNET-DRAFT                                        26 November 1996
     As a result, it is believed that the hierarchical naming  approach  is
     not sufficient to handle all the requirements.
     5.2.  Authentication and Accounting Route (AR) records
     One  way  to  support hierarchical routing as well as to provide addi-
     tional flexibility, is to allow for indirection in  the  determination
     of  authentication and accounting routes. When this approach is taken,
     the NAI is used to embed a pointer to an authentication and accounting
     route,  rather  than  embedding  the route itself. For the purposes of
     this specification, the convention user@domain syntax  is  used,  with
     the  domain  portion of the NAI being used to retrieve the authentica-
     tion and accounting route via DNS.
     5.2.1.  Definition of the Authentication  and  Accounting  Route  (AR)
     The  Authentication  and  Accounting  Route (AR) record uses semantics
     similar to that of the Mail Exchange (MX) record, in that it  includes
     a  priority  as well as the authentication  route. The AR record is of
     the form:
   IN AR 10
     Here   10   refers   to   the   priority   of   the  AR  record,  isp- is the authentication route,  and  isp-  represents the domain of the settlement agent. The use of
     a priority field allows multiple relationships to be represented, with
     authenticating  ISPs  checking the relationships in ascending order of
     priority. Thus, an AR record of priority 10 would be checked before  a
     record of priority 20.
     Routes  for a given domain SHOULD be given different priorities, so as
     to allow for predictable behavior. Since routes at the  same  priority
     will  be  round-robined,  this  will  result in alternation of routes.
     Unless there is a good reason for balancing the load  this  way,  this
     approach should be avoided.
     5.2.2.  Example One
     Let  us  say Fred is an employee of BIGCO, who has established account
     relationships with ISPA and ISPC, both of which are members of roaming
     consortia ISPGROUP. BIGCO also has a relationship with clearing houses
     Fred is now traveling, and logs into ISPB as The  ISPB
     RADIUS proxy receives this NAI. ISPB then checks in its list
     of firms with whom it has a direct business relationship.  This  check
     will  fail since BIGCO is not a direct customer of ISPB, and is not an
     ISP or roaming consortia.
     Aboba                                                         [Page 7]

     INTERNET-DRAFT                                        26 November 1996
     ISPB now looks up the Authentication and Accounting Route  Record  for, and receives the following reply:
  IN AR  10 IN AR  20 IN AR  30 IN AR  40
     The  ISPB  RADIUS proxy now checks the AR records in order of priority
     so as to determine whether it has a business relationship with any  of
     the  domains  listed in the returned AR records. The RADIUS proxy will
     select the first record in which there is a valid  business  relation-
     In  this  case, ISPB's RADIUS proxy discovers that ISPA is a member of
     the ISPGROUP  roaming  consortia.  As  a  result,  the  authentication
     request is forwarded to the authentication proxy operated by ISPA.COM.
     The method by which this authentication server is determined, and  the
     method  by  which  ISPB  verifies  ISPA's  membership  in  ISPGROUP is
     described in a subsequent section.
     If ISPA was not a member of the  ISPGROUP  roaming  consortia,  ISPB's
     proxy would continue down the list. For example, if ISPC were a member
     of ISPGROUP, then it  would  forward  the  authentication  request  to
     ISPC's  RADIUS  proxy.  If ISPB had no relationship with ISPC, then it
     would check to see if it had a business relationship  with  ISPGROUP2.
     In  the case where a business relationship existed, the authentication
     would be  forwarded  to  the  authentication  proxy  within  the  isp- domain. If no business relationship existed with ISPGROUP2,
     then ISPB's proxy would check for a relationship with  ISPGROUP1,  and
     failing that, would send a RADIUS Access-Reject message.
     Let  us  assume  that  ISPA  has received the forwarded authentication
     request. It will then check the domain portion of the NAI  (
     to  see  if there is a direct business relationship. Since this is the
     case, ISPA will then retrieve the location of  BIGCO's  authentication
     server  and  forward  the authentication request to that server. After
     the session is over, ISPB's RADIUS proxy  will  route  the  accounting
     record to the settlement agent identified in the AR record.
     5.2.3.  Example Two
     Let us assume that BIGCO has branch offices in multiple locations. The
     BIGCO branch office in Illinois has a contract with ISPA, which  is  a
     member  of  ISPGROUP1 while the branch office in Israel has a contract
     with ISPC, which is a member of ISPGROUP2. As a result, it is  desired
     that  Fred  be able to login either from Illinois or from Israel, with
     the authentication being done by the appropriate ISP.
     In this case, the AR records for BIGCO will appear as follows:
  IN AR 10 IN AR 20
     Aboba                                                         [Page 8]

     INTERNET-DRAFT                                        26 November 1996
     As a result, when Fred attempts to authenticate with ISPB while in the
     United  States,  the  authentication  request  will be routed to ISPA,
     assuming that ISPB has a business  relationship  with  ISPA.  In  this
     case, the accounting record will be submitted to ISPGROUP1 for settle-
     ment. When Fred travels to Israel, and dials into ISPD, it  will  also
     check  the authentication routes, and presumably will find that it has
     a relationship with ISPC, but not with ISPA. As a result, the  authen-
     tication  request  will be forwarded to ISPC rather than ISPA, and the
     accounting record will be submitted to ISPGROUP2 for settlement.
     6.  Accounting Issues
     Since billing rates may differ between roaming consortia, it is neces-
     sary  that  the accounting records include the relevant authentication
     route and settlement agent. Since it is possible that  ISPB  and  ISPA
     may both be members of more than one roaming consortia, an authentica-
     tion route of does  not  uniquely  determine  the
     consortia  to  whom the accounting record should be submitted for set-
     In the case of hierarchical naming, including the authentication route
     in  the accounting record is as simple as including the NAI within the
     accounting record, since in this case the route is embedded within the
     NAI.  However,  using the hierarchical naming approach, information on
     the settlement agent is not available. As a result,  ISPs  using  this
     naming approach will need to ensure that their RADIUS proxies are con-
     figured with information on the relevant settlement agents.
     For the case where a DNS AR record is used, the situation is more com-
     plicated.  In  this  case, the RADIUS proxy needs to keep a forwarding
     table mapping RADIUS domains to authentication routes  and  settlement
     agents.  When  the  proxy receives a RADIUS Accounting-Request message
     (START or STOP), it will find the authentication route and  settlement
     agent  corresponding  to  the  NAI  in  the forwarding table, and will
     insert this in the accounting record for the session.
     The forwarding table is filled in as  DNS  AR  records  are  received.
     Ordinarily an AR record is kept in the forwarding table until it times
     out. This implies that the forwarding table will typically remain con-
     stant  between  the time that the authentication is processed and when
     the accounting records are generated.
     The possible exceptions to this behavior are when the TTL  expires  in
     mid-session  or  if  the  RADIUS  proxy server is restarted, causing a
     rebuilding of the forwarding table. In these cases if  the  AR  record
     has changed it is possible that the existing sessions may be accounted
     for incorrectly. To avoid this, the RADIUS proxy MUST NOT  modify  the
     forwarding table entry for a domain with a session in progress.
     Aboba                                                         [Page 9]

     INTERNET-DRAFT                                        26 November 1996
     7.  Security issues
     So  far,  we  have  not described how ISPB determines whether it has a
     valid business relationship with ISPA, ISPC, ISPGROUP1, or  ISPGROUP2.
     We  also  have not discussed how ISPB verifies the authenticity of the
     authentication route or settlement agent domain that it  obtains  from
     the DNS.
     7.1.  Verification of business relationships
     RADIUS proxies typically require a configuration file listing the sys-
     tems with which they can communicate, and the shared secrets  used  in
     that communication. Proxies will typically check this list in order to
     make choices among the routes included in the DNS response.
     7.2.  Verification of authentication and accounting routes
     Were an attack on the DNS to be successful, it would  be  possible  to
     insert authentication and accounting route records, to change the pri-
     ority of existing authentication and accounting route records,  or  to
     change SRV records. We discuss the effects of each of these attacks in
     7.2.1.  Insertion of authentication and accounting route records
     By insertion of authentication and accounting route records, it  would
     be  possible  for an attacker to deny service. However, as long as the
     RADIUS proxy performed a proper check on  the  business  relationships
     between  itself  and  the domains indicated in the AR record, it would
     not forward authentications to the indicated domains. In addition, the
     use of mutual authentication in the accounting record transfer process
     means that the attacker would  also  have  to  steal  the  appropriate
     shared  secrets or private keys in order to be able to masquerade as a
     legitimate settlement agent.
     7.2.2.  Changing the priority of existing authentication and  account-
     ing route records
     Since  changing  the  priority  of existing records does not result in
     denial of service, or require the theft of shared secrets  or  private
     keys,  it  is  the  subtlest form of attack. The result of this attack
     would be a shift in business toward the ISPs or consortia  that  would
     be  moved  up  in priority. This constitutes a theft, but would not be
     detectable without the use of secure DNS.
     7.2.3.  Changing of SRV records
     Were an attacker to change the RADIUS SRV records, it would be  possi-
     ble  to  divert  forwarded authentications to a bogus server. However,
     Aboba                                                        [Page 10]

     INTERNET-DRAFT                                        26 November 1996
     unless the attacker had also stolen the  shared  secrets,  the  result
     would be denial rather than theft of service.
     8.  Formal Definition of the NAI
     As  proposed  in  this specification, the Network Access Identifer may
     represent either an authentication route,  or  a  pointer  to  such  a
     route. In order to clearly distinguish the two formats, the route form
     of the NAI uses the "/" character as a separator,  while  the  pointer
     form  of  the  NAI uses a user@domain or user:domain format, where the
     domain is a fully qualified domain name (FQDN).  Where  a  pointer  is
     used, the domain portion of the NAI is then used to retrieve the route
     via DNS lookup. A new DNS record, the  Authentication  and  Accounting
     Route (AR) record is used for this purpose.
     8.1.  BNF for the NAI
     The  grammar for the NAI is given below, using the augmented BNF nota-
     tion described in reference [9].
     NAI = (ROUTE  [REALM "/"] USERNAME) | (USERNAME ("@" | ":") FQDN)
     ROUTE = *[FQDN "/"]
     FQDN =    token "."  token *[ "." token ]
     REALM = token
     USERNAME = token
     As defined above, the route may consist of zero or more  fully  quali-
     fied  domain  names (FQDNs), separated by a "/" character. Examples of
     valid routes include:

     Examples of invalid routes include:

     Examples of valid embedded-route NAIs include:

     Examples of valid Authentication  and  Acounting  Route  (AR)  records
       IN  AR 10      IN  AR 10  IN  AR 10
     Aboba                                                        [Page 11]

     INTERNET-DRAFT                                        26 November 1996
     9.  Resolution of authentication server addresses
     In  order to make use of the authentication routes, it is necessary to
     be able to resolve the location of a  domain's  RADIUS  authentication
     server,  given  the  fully qualified domain name.  The DNS SRV record,
     defined in [10] is used for this purpose. This SRV  record  uses  type
     When  used to provide information on the location of the RADIUS server
     within a given domain, the SRV records will be of the following form:
       IN   SRV 10 0 1645      IN   SRV 20 0 1645      IN   SRV 10 0 1646      IN   SRV 20 0 1646
     Here radiusauth  denotes  the  RADIUS  authentication  service,  while
     radiusacct denotes RADIUS accounting. Since the authentication service
     typically runs on port 1645 while  the  accounting  service  typically
     runs  on  port  1646, two SRV records are required to allow them to be
     resolved. Within each service, two records are used so as  to  provide
     backup  capabilities. Thus if the server is not avail-
     able (priority 10), the server should be used  (prior-
     ity 20). The weight is used in load balancing records of the same pri-
     ority level, and is set to zero when there is only  one  record  at  a
     given  priority  level.  Further  details on the SRV record format are
     available in [10].
     10.  Resolution of settlement agent addresses
     SRV records will also be used for resolution of the settlement  domain
     (included  in  the  AR record) to an IP address and port number.  When
     used to provide information on the location of the  settlement  server
     within a given domain, the SRV records will be of the following form:
       IN   SRV 10 0 1648      IN   SRV 20 0 1648
     Here  roamacct  denotes  the  roaming  accounting service. The port of
     1648, as well as the TCP transfer method are used purely for illustra-
     tion,  since we do not yet have a proposal for the accounting transfer
     11.  Acknowledgements
     Thanks to Glen Zorn and Gurdeep Singh Pall of Microsoft, Richard Perl-
     man of Pacific Bell, Pat Calhoun of USR, Michael Robinson of Asiainfo,
     and Ian Duncan of Newbridge Networks, for many useful  discussions  of
     this problem space.
     Aboba                                                        [Page 12]

     INTERNET-DRAFT                                        26 November 1996
     12.  References
     [1]   B.  Aboba, L. Liu, J. Alsop, J. Ding.  "Review of Roaming Imple-
     mentations." draft-ietf-roamops-imprev-00.txt, Microsoft,  Aimnet,  i-
     Pass Alliance, Asiainfo, September, 1996.
     [2]   B.  Aboba,  G. Zorn.  "Dialup Roaming Requirements." draft-ietf-
     roamops-roamreq-00.txt, Microsoft, October, 1996.
     [3]  C. Rigney, A. Rubens, W. A. Simpson, S. Willens.  "Remote Authen-
     tication   Dial   In   User   Service   (RADIUS)."  draft-ietf-radius-
     radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
     [4]    C.    Rigney.     "RADIUS    Accounting."    draft-ietf-radius-
     accounting-05.txt, Livingston, July 1996.
     [5]  K.  Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J.
     Valencia, W. Verthein.  "Layer Two Tunneling Protocol -- L2TP." draft-
     ietf-pppext-l2tp-00.txt, Ascend Communications, August, 1996.
     [6]  K.  Hamzeh,  G.  S.  Pall,  J. Taarud, W. Verthein, W. A. Little.
     "Point-to-Point  Tunneling  Protocol  --   PPTP."   draft-ietf-pppext-
     pptp-00.txt, Ascend Communications, June, 1996.
     [7]  G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support." draft-
     zorn-radius-tunnel-auth-00.txt, Microsoft Corporation, October,  1996.
     [8]  B.  Aboba.   "Implementation  of Mandatory Tunneling via RADIUS."
     draft-aboba-radius-tunnel-imp-01.txt, Microsoft Corporation,  October,
     [9]  R.  Fielding,  et  al.  "Hypertext Transfer Protocol - HTTP/1.1."
     draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
     [10] A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying the  location
     of  services  (DNS  SRV)."  RFC 2052, Troll Technologies, Vixie Enter-
     prises, October 1996.
     13.  Authors' Addresses
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     Phone: 206-936-6605
     Aboba                                                        [Page 13]