home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-dnsrr-03.txt < prev    next >
Text File  |  1997-03-10  |  37KB  |  859 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.      ROAMOPS Working Group                                    Bernard Aboba
  8.      INTERNET-DRAFT                                   Microsoft Corporation
  9.      <draft-ietf-roamops-dnsrr-03.txt >
  10.      7 March 1997
  11.  
  12.  
  13.            The Roaming Relationship (REL) Resource Record in the DNS
  14.  
  15.  
  16.      1.  Status of this Memo
  17.  
  18.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  19.      ments of the Internet Engineering Task Force (IETF),  its  areas,  and
  20.      its  working groups.  Note that other groups may also distribute work-
  21.      ing documents as Internet-Drafts.
  22.  
  23.      Internet-Drafts are draft documents valid for a maximum of six  months
  24.      and  may  be updated, replaced, or obsoleted by other documents at any
  25.      time.  It is inappropriate to use Internet-Drafts as  reference  mate-
  26.      rial or to cite them other than as ``work in progress.''
  27.  
  28.      To  learn  the  current status of any Internet-Draft, please check the
  29.      ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
  30.      Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
  31.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  32.  
  33.      The  distribution  of  this memo is unlimited.  It is filed as <draft-
  34.      ietf-roamops-dnsrr-03.txt>, and  expires September 15,  1997.   Please
  35.      send comments to the authors.
  36.  
  37.  
  38.      2.  Abstract
  39.  
  40.      This  document  describes  the  use  of the Roaming Relationship (REL)
  41.      record in the DNS for the description of  roaming  relationships.  REL
  42.      resource  records may be used for determining the existence of a roam-
  43.      ing relationship path between  the  local  ISP  and  the  user's  home
  44.      domain,  as  well  as the location of an appropriate accounting agent.
  45.      However, unless the roaming relationship path is authenticated by some
  46.      method  (such  as  via  tokens  or  certificates  returned by the home
  47.      authentication server), hierarchical authentication  routing  must  be
  48.      used in order to validate the path.
  49.  
  50.  
  51.      3.  Introduction
  52.  
  53.      Considerable  interest  has  arisen recently in a set of features that
  54.      fit within the general category of  "roaming  capability"  for  dialup
  55.      Internet users.  Interested parties have included:
  56.  
  57.           Regional  Internet  Service  Providers  (ISPs) operating within a
  58.           particular state or province, looking to  combine  their  efforts
  59.           with  those  of  other regional providers to offer dialup service
  60.           over a wider area.
  61.  
  62.  
  63.  
  64.      Aboba                                                         [Page 1]
  65.  
  66.  
  67.  
  68.  
  69.  
  70.      INTERNET-DRAFT                                            7 March 1997
  71.  
  72.  
  73.           National ISPs wishing to combine their operations with  those  of
  74.           one  or  more  ISPs in another nation to offer more comprehensive
  75.           dialup service in a group of countries or on a continent.
  76.  
  77.           Businesses desiring to  offer  their  employees  a  comprehensive
  78.           package of dialup services on a global basis.  Those services may
  79.           include Internet access as well as  secure  access  to  corporate
  80.           intranets via a Virtual Private Network (VPN), enabled by tunnel-
  81.           ing protocols such as PPTP, L2F, or L2TP.
  82.  
  83.      This document describes the use  of  the  Roaming  Relationship  (REL)
  84.      record  in  the  DNS for the description of roaming relationships. REL
  85.      resource records may be used for determining the existence of a  roam-
  86.      ing  relationship  path  between  the  local  ISP  and the user's home
  87.      domain, as well as the location of an  appropriate  accounting  agent.
  88.      However, unless the roaming relationship path is authenticated by some
  89.      method (such as via  tokens  or  certificates  returned  by  the  home
  90.      authentication  server),  hierarchical  authentication routing must be
  91.      used in order to validate the path.
  92.  
  93.  
  94.      3.1.  Terminology
  95.  
  96.      This document frequently uses the following terms:
  97.  
  98.      roaming relationship path
  99.                The roaming relationship path is the series of roaming rela-
  100.                tionships  that  link  together  a local ISP and user's home
  101.                domain. The roaming relationship path may or may not be  the
  102.                same  as  the authentication route, depending on whether the
  103.                local proxy is able to directly contact the home authentica-
  104.                tion server.
  105.  
  106.      authentication route
  107.                The  route  that  an  authentication  will take in traveling
  108.                between the local ISP's authentication proxy  and  the  home
  109.                authentication  server. Where RADIUS proxy authentication is
  110.                used, the authentication route follows the roaming relation-
  111.                ship path.
  112.  
  113.      Network Access Server
  114.                The  Network  Access Server (NAS) is the device that clients
  115.                dial in order to get access to the network.
  116.  
  117.      RADIUS server
  118.                This is a server which  provides  for  authentication/autho-
  119.                rization via the protocol described in [3], and for account-
  120.                ing as described in [4].
  121.  
  122.      RADIUS proxy
  123.                In order to provide for the routing of RADIUS authentication
  124.                and accounting requests, a RADIUS proxy may employed. To the
  125.                NAS, the RADIUS proxy appears to act as a RADIUS server, and
  126.                to  the  RADIUS server, the proxy appears to act as a RADIUS
  127.  
  128.  
  129.  
  130.      Aboba                                                         [Page 2]
  131.  
  132.  
  133.  
  134.  
  135.  
  136.      INTERNET-DRAFT                                            7 March 1997
  137.  
  138.  
  139.                client.
  140.  
  141.      RADIUS domain
  142.                In order to provide for the routing of RADIUS authentication
  143.                and accounting requests, the userID field used in PPP and in
  144.                the  subsequent   RADIUS   authentication   and   accounting
  145.                requests,  may  contain structure. This structure provides a
  146.                means by which the  RADIUS  proxy  will  locate  the  RADIUS
  147.                server that is to receive the request.
  148.  
  149.  
  150.      3.2.  Requirements language
  151.  
  152.      This  specification  uses the same words as [14] for defining the sig-
  153.      nificance of each particular requirement.  These words are:
  154.  
  155.  
  156.      MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
  157.                that the definition is an absolute requirement of the speci-
  158.                fication.
  159.  
  160.      MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
  161.                nition is an absolute prohibition of the specification.
  162.  
  163.      SHOULD    This  word, or the adjective "RECOMMENDED", means that there
  164.                may exist  valid  reasons  in  particular  circumstances  to
  165.                ignore  a particular item, but the full implications must be
  166.                understood and carefully weighed before choosing a different
  167.                course.
  168.  
  169.      SHOULD NOT
  170.                This phrase means that there may exist valid reasons in par-
  171.                ticular  circumstances  when  the  particular  behavior   is
  172.                acceptable  or even useful, but the full implications should
  173.                be understood and the case carefully weighed  before  imple-
  174.                menting any behavior described with this label.
  175.  
  176.      MAY       This  word,  or the adjective "OPTIONAL", means that an item
  177.                is truly optional.  One vendor may  choose  to  include  the
  178.                item because a particular marketplace requires it or because
  179.                the vendor feels that it enhances the product while  another
  180.                vendor may omit the same item.  An implementation which does
  181.                not include a particular option MUST be prepared to interop-
  182.                erate  with  another  implementation  which does include the
  183.                option, though perhaps with reduced  functionality.  In  the
  184.                same  vein an implementation which does include a particular
  185.                option MUST be prepared to interoperate with another  imple-
  186.                mentation  which  does  not  include  the option.(except, of
  187.                course, for the feature the option provides)
  188.  
  189.      An implementation is not compliant if it fails to satisfy one or  more
  190.      of  the must or must not requirements for the protocols it implements.
  191.      An implementation that satisfies all the must, must  not,  should  and
  192.      should   not   requirements   for   its   protocols   is  said  to  be
  193.  
  194.  
  195.  
  196.      Aboba                                                         [Page 3]
  197.  
  198.  
  199.  
  200.  
  201.  
  202.      INTERNET-DRAFT                                            7 March 1997
  203.  
  204.  
  205.      "unconditionally compliant"; one that satisfies all the must and  must
  206.      not requirements but not all the should or should not requirements for
  207.      its protocols is said to be "conditionally compliant."
  208.  
  209.  
  210.      4.  The Roaming Relationship (REL) Record
  211.  
  212.      In order to enable roaming, it is necessary for a local provider to be
  213.      able  to  determine whether a roaming relationship path exists between
  214.      itself and the user's home domain, so as to enable the local  provider
  215.      to  be  paid for the use of its resources. These roaming relationships
  216.      are typically of two types: the relationship  between  a  firm  and  a
  217.      provider,  in  which  the  firm  delegates  roaming  authority  to the
  218.      provider; or the relationship between a provider and a roaming associ-
  219.      ation, in which the provider agrees to allow members of the consortium
  220.      to access its network resources, in exchange  for  compensation.  How-
  221.      ever,  it is also possible for a company or even an individual to form
  222.      a direct relationship with a roaming consortia, or  for  consortia  to
  223.      form a relationship with another consortia.
  224.  
  225.      Inter-domain  roaming  relationships may extend to several levels. For
  226.      example, BIGCO may delegate roaming authority to ISPA, who may in turn
  227.      join  roaming  association  ISPGROUP.   When  Fred dials into ISPB and
  228.      attempts to authenticate as fred@bigco.com, it is necessary  for  ISPB
  229.      to  determine  whether it has a means for being paid for the resources
  230.      consumed by Fred. This is accomplished by tracing the web  of  roaming
  231.      relationships  backwards from the bigco.com domain, in order to deter-
  232.      mine whether a path of roaming relationships exists between  ISPB  and
  233.      BIGCO.
  234.  
  235.      Please note that the task of determining the path of roaming relation-
  236.      ships is orthogonal to the  issue  of  authentication  routing.  Where
  237.      authentication  proxy  chaining  is  used,  authentication  routing is
  238.      required in order to improve scalability.  However,  when  public  key
  239.      authentication  is  available,  it  is  possible for an authentication
  240.      proxy to directly contact  a  home  authentication  server.   However,
  241.      regardless  of how the authentication is routed, it is still necessary
  242.      for the local ISP to determine the path of  roaming  relationships  so
  243.      that it can determine whether it can be paid for the transaction.
  244.  
  245.      The  purpose  of  the Roaming Relationship (REL) resource record is to
  246.      document inter-domain roaming relationships. When hierarchical authen-
  247.      tication  routing  is  being  used, REL resource records are typically
  248.      retrieved by the local ISP's authentication proxy, and used  both  for
  249.      determination  of  the roaming relationship path as well as for use in
  250.      authentication routing. If public  key  authentication  technology  is
  251.      available, it may be possible for the local ISP's authentication proxy
  252.      to contact the home domain's authentication server directly.  In  this
  253.      case,  hierarchical  authentication  routing will not be required, and
  254.      the home authentication server may return tokens  or  certificates  in
  255.      order to validate the roaming relationship path. If this is done, then
  256.      the local ISP's authentication proxy may not need to look up  any  REL
  257.      resource  records itself, and as a result, the total time required for
  258.      the authentication will be decreased. This will lessen the probability
  259.  
  260.  
  261.  
  262.      Aboba                                                         [Page 4]
  263.  
  264.  
  265.  
  266.  
  267.  
  268.      INTERNET-DRAFT                                            7 March 1997
  269.  
  270.  
  271.      of a timeout.
  272.  
  273.  
  274.      4.1.  REL resource record RDATA format
  275.  
  276.      The RDATA for a REL resource record is as follows:
  277.  
  278.      0                   1                   2                   3
  279.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
  280.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  281.      |              Preference       |              Flags            |
  282.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  283.      /                                                               /
  284.      /                            Domain                             /
  285.      /                                                               /
  286.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  287.  
  288.  
  289.      4.1.1.  Preference
  290.  
  291.      The  Preference  field,  which is two octets, specifies the preference
  292.      given to this record versus other records of the same type and  owner.
  293.      Lower values are preferred.
  294.  
  295.  
  296.      4.1.2.  Flags
  297.  
  298.      The flags field, which is two octets, is as follows:
  299.      0                   1
  300.      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
  301.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302.      |U P C A I F H R R R R R R R R R|
  303.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  304.  
  305.      U  = User. If U=1, then the REL resource record represents an individ-
  306.      ual user or account. The user name is represented the same way  as  in
  307.      the  SOA  or  RP resource records. As a result, fred@bigco.com will be
  308.      represented as fred.bigco.com. Since the DNS was not intended for  use
  309.      as  a user database, it is expected that this flag will only be set on
  310.      rare occasions.
  311.  
  312.      P = Provider. If P=1, then the REL resource record represents  delega-
  313.      tion  of  roaming authority from a non-ISP to an ISP or a roaming con-
  314.      sortia.
  315.  
  316.      C = Consortia. If C=1, then the REL resource record represents delega-
  317.      tion of roaming authority from an ISP to a roaming consortia.
  318.  
  319.      A  =  Accounting  agent. If A=1, then a accounting agent exists within
  320.      the domain.
  321.  
  322.      I = Internet access. If I=1, then the REL resource record may be  used
  323.      for  provisioning of Internet access. In roaming applications this bit
  324.      MUST be set.
  325.  
  326.  
  327.  
  328.      Aboba                                                         [Page 5]
  329.  
  330.  
  331.  
  332.  
  333.  
  334.      INTERNET-DRAFT                                            7 March 1997
  335.  
  336.  
  337.      F = Fax. If F=1, then the REL resource record may be used  for  provi-
  338.      sioning of Internet fax.
  339.  
  340.      H = H.323. If H=1, then the REL resource record may be used for provi-
  341.      sioning of H.323 conferencing.
  342.  
  343.      R = Reserved.
  344.  
  345.  
  346.      4.1.3.  Domain
  347.  
  348.      The domain field represents the domain name to which roaming authority
  349.      has been delegated by the owner name.
  350.  
  351.  
  352.      4.2.  Use of the Roaming Relationship (REL) Resource Record
  353.  
  354.      The  Roaming Relationship (REL) resource record uses semantics similar
  355.      to that of the Mail Exchange (MX) record, in that it includes a prior-
  356.      ity  as  well  as the domain to which roaming authority has been dele-
  357.      gated. The REL resource record is of the form:
  358.  
  359.      bigco.com.  IN REL 10 (; priority
  360.                  ispa.com.  ;domain with roaming authority
  361.                  P I        ;flags. P = Provider, I = Internet Access
  362.                  )
  363.  
  364.      Here 10 refers to  the  priority  of  the  REL  resource  record,  and
  365.      ispa.com  is the domain to which BIGCO has delegated roaming responsi-
  366.      bilities. The use of a priority field allows multiple relationships to
  367.      be represented, with authenticating ISPs checking the relationships in
  368.      ascending order of priority. Thus, an REL resource record of  priority
  369.      10  would  be  checked before a REL resource record of priority 20. As
  370.      described in the previous section, letters are  used  to  denote  flag
  371.      bits.
  372.  
  373.      Routes  for a given domain SHOULD be given different priorities, so as
  374.      to allow for predictable behavior. Since routes at the  same  priority
  375.      will  be  round-robined,  this  will  result in alternation of routes.
  376.      Unless there is a good reason for balancing the load  this  way,  this
  377.      approach SHOULD NOT be used.
  378.  
  379.  
  380.      5.  Examples
  381.  
  382.  
  383.      5.1.  Example One
  384.  
  385.      Let  us  assume that Fred is an employee of BIGCO, who has established
  386.      roaming relationships with ISPA and ISPC, both of which are members of
  387.      roaming consortia ISPGROUP1. BIGCO also has a relationship with clear-
  388.      ing houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the  ISPGROUP1
  389.      roaming consortia.
  390.  
  391.  
  392.  
  393.  
  394.      Aboba                                                         [Page 6]
  395.  
  396.  
  397.  
  398.  
  399.  
  400.      INTERNET-DRAFT                                            7 March 1997
  401.  
  402.  
  403.      The REL resource records for BIGCO appear as follows:
  404.  
  405.      bigco.com. IN REL 10 ispa.com.         P I
  406.      bigco.com. IN REL 20 ispc.com.         P I
  407.      bigco.com. IN REL 30 ispgroup3.com.    P I
  408.      bigco.com. IN REL 40 ispgroup2.com.    P I
  409.  
  410.      The  REL  resource  records for ISPA, ISPB, ISPC, ISPGROUP1, ISPGROUP2
  411.      and ISPGROUP3 appear as follows:
  412.  
  413.      ispa.com. IN REL 10 ispgroup1.com.      C I
  414.  
  415.      ispb.com. IN REL 10 ispgroup1.com.      C I
  416.  
  417.      ispc.com. IN REL 10 ispgroup1.com.      C I
  418.  
  419.      ispgroup1.com. IN REL 10 ispgroup1.com. C I A
  420.  
  421.      ispgroup2.com. IN REL 10 ispgroup2.com. C I A
  422.  
  423.      ispgroup3.com. IN REL 10 ispgroup3.com. C I A
  424.  
  425.  
  426.      5.1.1.  Sequence of events
  427.  
  428.      Fred logs into ISPB as fred@bigco.com; as a result the ISPB  authenti-
  429.      cation  proxy  receives  this  NAI.  ISPB's authentication proxy first
  430.      checks for the presence of a user record for  fred.bigco.com.  If  so,
  431.      then it retrieves the REL resource records for the domain to whom Fred
  432.      has delegated roaming authority. If there is no user record,  then  it
  433.      checks  its configuration files to see whether bigco.com is one of the
  434.      domains with whom it has a direct  roaming  relationship.  This  check
  435.      will fail since BIGCO has no direct roaming relationship with ISPB. As
  436.      a result, ISPB's  authentication  proxy  will  need  to  retrieve  REL
  437.      resource records either from its own cache or from the bigco.com zone.
  438.  
  439.      Assuming that ISPB's authentication proxy does not support public  key
  440.      authentication, then hierarchical authentication routing will be used.
  441.      In this case, ISPB's authentication proxy will need  to  retrieve  REL
  442.      resource  records  from  the bigco.com zone.  If ISPB's authentication
  443.      proxy supports public key authentication and ISPEC, then  rather  than
  444.      immediately retrieving REL resource records, it will retrieve the SRV,
  445.      KEY and SIG resource records for the bigco.com  zone.  Using  the  SRV
  446.      resource  record, ISPB's authentication proxy can locate the authenti-
  447.      cation proxy for the bigco.com domain. The SIG  resource  records  for
  448.      the bigco.com zone can then be retrieved in order to determine whether
  449.      the bigco.com authentication server supports  public  key  authentica-
  450.      tion.  If  so,  then  ISPB's  authentication  proxy  may  contact  the
  451.      bigco.com authentication server directly. In its authentication reply,
  452.      the  bigco.com  authentication  server  may  return  the  REL resource
  453.      records for its zone as well as those of the zones  to  which  it  has
  454.      delegated  roaming  authority,  in  the  form of attributes within the
  455.      Access-Reply. If so, then ISPB's authentication proxy  will  be  saved
  456.      the  work of having to retrieve these resource records itself prior to
  457.  
  458.  
  459.  
  460.      Aboba                                                         [Page 7]
  461.  
  462.  
  463.  
  464.  
  465.  
  466.      INTERNET-DRAFT                                            7 March 1997
  467.  
  468.  
  469.      forwarding the authentication reply on to the NAS.
  470.  
  471.      Once the REL resource records have been retrieved by one mechanism  or
  472.      another,  a  depth  first  search  is performed in order to select the
  473.      roaming relationship path. In this case, ISPB  determines  whether  it
  474.      has  a  direct roaming relationship with ISPA (priority 10 record from
  475.      the bigco.com zone). If not, then it looks at the REL resource records
  476.      for  the ispa.com domain, and determines whether it has a direct roam-
  477.      ing relationship with any of the domains to whom  ISPA  has  delegated
  478.      roaming  responsibility.  In  this case, ISPB determines that it has a
  479.      direct roaming relationship with ISPGROUP1 (priority  10  record  from
  480.      the  ispa.com  zone).  As  a  result,  the  roaming  relationship path
  481.      bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1
  482.      operates an accounting agent within its domain, accounting records for
  483.      the transaction will be sent to ISPGROUP1's accounting agent.
  484.  
  485.      If ISPA had not been a member of the ISPGROUP1 roaming consortia, then
  486.      the  depth-first  search would have terminated, and ISPB would proceed
  487.      to check for a business relationship on the branch represented by  the
  488.      priority  20  REL resource record in the bigco.com zone (ispc.com). In
  489.      this  case  the  roaming  relationship  path   bigco.com/ispc.com/isp-
  490.      group1.com/ispb.com would have been selected.
  491.  
  492.      If  ISPB  were  a member of the ISPGROUP3 roaming consortia, and not a
  493.      member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first
  494.      search  would  fail  on  both  the  priority 10 and 20 branches of the
  495.      bigco.com  tree.  In  this  case,  the  business   relationship   path
  496.      bigco.com/ispgroup3.com/ispb.com would have been selected.
  497.  
  498.  
  499.      5.2.  Example Two
  500.  
  501.      Let us assume that BIGCO has branch offices in multiple locations. The
  502.      BIGCO branch office in Illinois has a contract with ISPA, which  is  a
  503.      member  of  ISPGROUP1.  However,  ISPGROUP1  does not have coverage in
  504.      Israel. As a result, the  branch office in Israel has a contract  with
  505.      ISPC,  which  is  a  member  of ISPGROUP2, which does have coverage in
  506.      Israel. It is desired that Fred be able to login either from  Illinois
  507.      or  from Israel, with the authentication being done by the appropriate
  508.      ISP. When logging in from Illinois, Fred uses the POPs of ISPB,  while
  509.      in  Israel, he uses the POPs of ISPD. It should be noted that ISPA and
  510.      ISPC can be located anywhere; they  need  not  necessarily  reside  in
  511.      Illinois or Israel.
  512.  
  513.      In this case, the REL records for BIGCO will appear as follows:
  514.  
  515.      bigco.com. IN REL 10 ispa.com.        P I
  516.      bigco.com. IN REL 20 ispc.com.        P I
  517.  
  518.      The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear
  519.      as follows:
  520.  
  521.      ispa.com.  IN REL 10 ispgroup1.com.        C I
  522.  
  523.  
  524.  
  525.  
  526.      Aboba                                                         [Page 8]
  527.  
  528.  
  529.  
  530.  
  531.  
  532.      INTERNET-DRAFT                                            7 March 1997
  533.  
  534.  
  535.      ispb.com.  IN REL 10 ispgroup1.com.        C I
  536.  
  537.      ispc.com.  IN REL 10 ispgroup2.com.        C I
  538.  
  539.      ispd.com.  IN REL 10 ispgroup2.com.        C I
  540.  
  541.      ispgroup1.com.  IN REL 10 ispgroup1.com.   C I A
  542.  
  543.      ispgroup2.com.  IN REL 10 ispgroup2.com.   C I A
  544.  
  545.  
  546.      5.2.1.  Sequence of events
  547.  
  548.      While in the United States, Fred logs into ISPB as fred@bigco.com;  as
  549.      a  result  the  ISPB  authentication  proxy  receives this NAI. ISPB's
  550.      authentication proxy first checks for the presence of  a  user  record
  551.      for  fred.bigco.com. If so, then it retrieves the REL resource records
  552.      for the domain to whom Fred has delegated roaming authority. If  there
  553.      is  no  user  record,  then  it  checks its configuration files to see
  554.      whether bigco.com is one of the domains with  whom  it  has  a  direct
  555.      roaming  relationship.  This check will fail since BIGCO has no direct
  556.      roaming relationship with ISPB. As  a  result,  ISPB's  authentication
  557.      proxy will need to retrieve resource records either from its own cache
  558.      or from the bigco.com zone.
  559.  
  560.      Once the REL resource records have been retrieved by one mechanism  or
  561.      another,  a  depth  first  search  is performed in order to select the
  562.      roaming relationship path. In this case, ISPB  determines  whether  it
  563.      has  a  direct roaming relationship with ISPA (priority 10 record from
  564.      the bigco.com zone). If not, then it looks at the REL resource records
  565.      for  the ispa.com domain, and determines whether it has a direct roam-
  566.      ing relationship with any of the domains to whom  ISPA  has  delegated
  567.      roaming  responsibility.  In  this case, ISPB determines that it has a
  568.      direct roaming relationship with ISPGROUP1 (priority  10  record  from
  569.      the  ispa.com  zone).  As  a  result,  the  roaming  relationship path
  570.      bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1
  571.      operates  a accounting agent within its domain, accounting records for
  572.      the transaction will be sent to ISPGROUP1's accounting agent.
  573.  
  574.      While in Israel, Fred logs into ISPD as fred@bigco.com; as  a  result,
  575.      the ISPD authentication proxy receives this NAI. ISPD's authentication
  576.      proxy then checks its configuration files to see whether bigco.com  is
  577.      one  of  the  domains  with whom it has a direct roaming relationship.
  578.      This check will fail since BIGCO has no  direct  roaming  relationship
  579.      with  ISPD.  As  a  result,  ISPD's  authentication proxy will need to
  580.      retrieve REL resource records either from its own cache  or  from  the
  581.      bigco.com zone.
  582.  
  583.      Once  the REL resource records have been retrieved by one mechanism or
  584.      another, a depth first search is performed  in  order  to  select  the
  585.      roaming  relationship  path.  In this case, ISPD determines whether it
  586.      has a direct roaming relationship with ISPA (priority 10  record  from
  587.      the bigco.com zone). If not, then it looks at the REL resource records
  588.      for the ispa.com domain,  and  determines  whether  it  has  a  direct
  589.  
  590.  
  591.  
  592.      Aboba                                                         [Page 9]
  593.  
  594.  
  595.  
  596.  
  597.  
  598.      INTERNET-DRAFT                                            7 March 1997
  599.  
  600.  
  601.      roaming  relationship  with  any of the domains to whom ISPA has dele-
  602.      gated roaming responsibility. In this case, ISPD  determines  that  no
  603.      roaming relationship path exists passing through ISPA.
  604.  
  605.      As  a  result, ISPD checks for a roaming relationship path on the ISPC
  606.      branch (priority 20 REL resource  record  from  the  bigco.com  zone).
  607.      First,  it  determines  whether there is a direct roaming relationship
  608.      between ISPD and ISPC (there is not). Then it looks at the REL records
  609.      for  the ispc.com domain, and determines whether it has a direct roam-
  610.      ing relationship with any of the domains to whom  ISPC  has  delegated
  611.      roaming  responsibility.  In  this case, ISPD determines that it has a
  612.      direct roaming relationship with ISPGROUP2 (priority 10  REL  resource
  613.      record  from the ispc.com zone). As a result, the roaming relationship
  614.      path bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISP-
  615.      GROUP2  operates  a  accounting  agent  within  its domain, accounting
  616.      records for the transaction will be  sent  to  ISPGROUP2's  accounting
  617.      agent.
  618.  
  619.  
  620.  
  621.      5.3.  Example Three
  622.  
  623.      Let  us  assume  that  Fred wishes to travel to a country which is not
  624.      served by the roaming consortia that BIGCO's provider ISPA has joined.
  625.      In  this  case,  Fred  will  wish to make use of the user REL resource
  626.      record.
  627.  
  628.      In this case, the REL resource records for BIGCO will appear  as  fol-
  629.      lows:
  630.  
  631.      bigco.com.      IN REL 10 ispa.com.   P I
  632.      fred.bigco.com. IN REL 10 ispe.com.   U I
  633.  
  634.      The  records  for  ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as
  635.      follows:
  636.  
  637.      ispa.com.  IN REL 10 ispgroup1.com.        C I
  638.  
  639.      ispb.com.  IN REL 10 ispgroup1.com.        C I
  640.      ispb.com.  IN REL 10 ispgroup2.com.        C I
  641.  
  642.      ispe.com.  IN REL 10 ispgroup2.com.        C I
  643.  
  644.      ispgroup1.com.  IN REL 10 ispgroup1.com.   C I A
  645.  
  646.      ispgroup2.com.  IN REL 10 ispgroup2.com.   C I A
  647.  
  648.  
  649.      5.3.1.  Sequence of events
  650.  
  651.      While traveling, Fred logs into ISPB as fred@bigco.com;  as  a  result
  652.      the ISPB authentication proxy receives this NAI. ISPB's authentication
  653.      proxy  first  checks  for  the  presence  of   a   user   record   for
  654.      fred.bigco.com.  If so, then it retrieves the REL resource records for
  655.  
  656.  
  657.  
  658.      Aboba                                                        [Page 10]
  659.  
  660.  
  661.  
  662.  
  663.  
  664.      INTERNET-DRAFT                                            7 March 1997
  665.  
  666.  
  667.      the domain to whom Fred has delegated roaming authority. In this case,
  668.      a  user  record  exists for fred@bigco.com, so that the authentication
  669.      proxy determines whether it has a  direct  roaming  relationship  with
  670.      ISPE  (priority  10 REL resource record from the fred.bigco.com zone).
  671.      If not, then it looks at the REL resource  records  for  the  ispe.com
  672.      domain,  and  determines  whether it has a direct roaming relationship
  673.      with any of the domains to whom ISPE has delegated  roaming  responsi-
  674.      bility.  In  this  case,  ISPB determines that it has a direct roaming
  675.      relationship with ISPGROUP2 (priority 10 REL resource record from  the
  676.      ispe.com   zone).   As   a   result,  the  roaming  relationship  path
  677.      fred.bigco.com/ispe.com/ispgroup2.com/ispb.com is selected. Since ISP-
  678.      GROUP2  operates  a  accounting  agent  within  its domain, accounting
  679.      records for the transaction will be  sent  to  ISPGROUP2's  accounting
  680.      agent.
  681.  
  682.      Please  note that even though Fred has a user REL resource record, the
  683.      authentication conversation will still  be  conducted  between  ISPB's
  684.      authentication proxy and BIGCO's authentication server.
  685.  
  686.  
  687.      6.  Prevention of looping topologies
  688.  
  689.      Since  it  is possible to create looping topologies using REL resource
  690.      records, a mechanism must be provided to prevent endless loops.  As  a
  691.      result,  it  is  recommended that authentication proxies be configured
  692.      with a default maximum of four hops. This would support  the  scenario
  693.      of  an  authentication  passing from a NAS to an authentication proxy,
  694.      from the proxy to ISPGROUP, from ISPGROUP to ISPA, and  from  ISPA  to
  695.      BIGCO.
  696.  
  697.  
  698.      7.  Use of the REL RR
  699.  
  700.      When  REL  resource records are utilized, no assurance can be provided
  701.      as to the authenticity of the  roaming  relationships  represented  by
  702.      these  records. As a result, it is necessary to verify the validity of
  703.      the roaming relationship path by another means.  This  can  be  accom-
  704.      plished  by  causing the authentication to be routed along the roaming
  705.      relationship path, or by verifying the authenticity of  a  certificate
  706.      or token returned by the home authentication server.
  707.  
  708.      As  an  example,  let  us  assume  that  the roaming relationship path
  709.      bigco.com/ispc.com/ispgroup2.com/ispd.com is selected.  If  this  path
  710.      has not been authenticated, then ISPD's authentication proxy will for-
  711.      ward it's authentication request to ISPGROUP2, including  the  roaming
  712.      relationship  path as a source route. ISPGROUP2 will then in turn for-
  713.      ward the authentication to ISPC, who will forward it to BIGCO. At each
  714.      step  of  the  way,  a  pre-existing  relationship  will need to exist
  715.      between hops in order for this authentication forwarding  to  proceed.
  716.      As  a result, the act of authenticating Fred via the roaming relation-
  717.      ship path acts to validate the roaming relationship as determined from
  718.      the REL resource records.
  719.  
  720.  
  721.  
  722.  
  723.  
  724.      Aboba                                                        [Page 11]
  725.  
  726.  
  727.  
  728.  
  729.  
  730.      INTERNET-DRAFT                                            7 March 1997
  731.  
  732.  
  733.      Note  that  such  hop by hop forwarding may be required even if public
  734.      key authentication is  available  for  use  between  the  local  ISP's
  735.      authentication  proxy  and  the home authentication server. As long as
  736.      the roaming relationship path has not been  authenticated,  the  local
  737.      ISP  will  still need to validate the roaming relationship path.  This
  738.      can be accomplished by forcing the authentication to follow the  roam-
  739.      ing  relationship path, validating the relationships between the prox-
  740.      ies at each hop.
  741.  
  742.      Please also note that public key authentication will also typically be
  743.      used in order to enable signed receipts to be returned by the account-
  744.      ing agent in response to receipt of digitally signed accounting record
  745.      bundles. DNS security can assist in determining what security features
  746.      are implemented at a given home authentication  server  or  accounting
  747.      agent.  Accounting agent support for MIME Security Multiparts is indi-
  748.      cated via use of the Email bit within the  KEY  resource  record  flag
  749.      field. DNS security may also be used to indicate that a home authenti-
  750.      cation server supports IPSEC. This is indicated via use of  the  IPSEC
  751.      bit within the KEY resource record flag field.
  752.  
  753.  
  754.      8.  Acknowledgements
  755.  
  756.      Thanks  to  Glen  Zorn  of  Microsoft, Pat Calhoun of USR, and Michael
  757.      Robinson of Global One for many useful  discussions  of  this  problem
  758.      space.
  759.  
  760.  
  761.      9.  References
  762.  
  763.      [1]  B. Aboba, J. Lu, J. Alsop, J. Ding.  "Review of Roaming Implemen-
  764.      tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet,  i-Pass
  765.      Alliance, Asiainfo, January, 1997.
  766.  
  767.      [2]   B.  Aboba, G. Zorn.  "Dialing Roaming Requirements." draft-ietf-
  768.      roamops-roamreq-02.txt, Microsoft, January, 1997.
  769.  
  770.      [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
  771.      cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
  772.      Daydreamer, January, 1997.
  773.  
  774.      [4]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
  775.      1997.
  776.  
  777.      [5]   R. Fajman. "An Extensible Message Format for Message Disposition
  778.      Notifications."  draft-ietf-receipt-mdn-02.txt, National Institute  of
  779.      Health, November, 1996.
  780.  
  781.      [6]  M.  Elkins.  "MIME  Security with Pretty Good Privacy (PGP)." RFC
  782.      2015, The Aerospace Corporation, October, 1996.
  783.  
  784.      [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting
  785.      of  Mail System Administrative Messages." RFC 1892, Octel Network Ser-
  786.      vices, January, 1996.
  787.  
  788.  
  789.  
  790.      Aboba                                                        [Page 12]
  791.  
  792.  
  793.  
  794.  
  795.  
  796.      INTERNET-DRAFT                                            7 March 1997
  797.  
  798.  
  799.      [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed
  800.      and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo-
  801.      ber, 1995.
  802.  
  803.      [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC  1767,  Bran-
  804.      denburg Consulting, March, 1995.
  805.  
  806.      [10]  M.  Jansson,  C. Shih, N. Turaj, R. Drummond. "MIME-based Secure
  807.      EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp,  Drummond
  808.      Group, November, 1996.
  809.  
  810.      [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for
  811.      Inter-operable  Internet  EDI."  draft-ietf-ediint-req-01.txt,  Actra,
  812.      LiNK, Drummond Group, May, 1995.
  813.  
  814.      [12]  A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying the location
  815.      of services (DNS SRV)." RFC 2052,  Troll  Technologies,  Vixie  Enter-
  816.      prises, October 1996.
  817.  
  818.      [13]  D.  Eastlake,  3rd, C. W. Kaufman.  "Domain Name System Security
  819.      Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August,
  820.      1996.
  821.  
  822.      [14]  S.  Bradner.  "Key words for use in RFCs to Indicate Requirement
  823.      Levels." draft-bradner-key-words-02.txt, Harvard  University,  August,
  824.      1996.
  825.  
  826.      [15]  C.  Malmud,  M.  Rose.  "Principles of Operation for the TPC.INT
  827.      Subdomain: General Principles and Policy."  RFC 1530, Internet  Multi-
  828.      casting Service, Dover Beach Consulting, Inc., October, 1993.
  829.  
  830.  
  831.  
  832.  
  833.      10.  Authors' Addresses
  834.  
  835.      Bernard Aboba
  836.      Microsoft Corporation
  837.      One Microsoft Way
  838.      Redmond, WA 98052
  839.  
  840.      Phone: 206-936-6605
  841.      EMail: bernarda@microsoft.com
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.      Aboba                                                        [Page 13]
  857.  
  858.  
  859.