idnits 2.17.1 draft-ietf-roamops-dnsrr-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 243 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 366 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '... MUST This word, or the adjec...' RFC 2119 keyword, line 125: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 128: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 134: '... SHOULD NOT...' RFC 2119 keyword, line 141: '... MAY This word, or the adj...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (238 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 March 1997) is 9910 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 601, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 605, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 615, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 619, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 622, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 626, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 630, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 633, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 637, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 641, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 645, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 653, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-roamops-imprev-01 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-imprev (ref. '1') == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-02 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '2') ** Obsolete normative reference: RFC 2058 (ref. '3') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '4') (Obsoleted by RFC 2139) == Outdated reference: A later version (-07) exists of draft-ietf-receipt-mdn-02 ** Obsolete normative reference: RFC 1892 (ref. '7') (Obsoleted by RFC 3462) == Outdated reference: A later version (-17) exists of draft-ietf-ediint-as1-02 == Outdated reference: A later version (-09) exists of draft-ietf-ediint-req-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ediint-req (ref. '11') ** Obsolete normative reference: RFC 2052 (ref. '12') (Obsoleted by RFC 2782) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 1530 (ref. '15') Summary: 21 errors (**), 0 flaws (~~), 27 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 5 7 March 1997 7 The Roaming Relationship (REL) Resource Record in the DNS 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires September 15, 1997. Please 28 send comments to the authors. 30 2. Abstract 32 This document describes the use of the Roaming Relationship (REL) 33 record in the DNS for the description of roaming relationships. REL 34 resource records may be used for determining the existence of a roam- 35 ing relationship path between the local ISP and the user's home 36 domain, as well as the location of an appropriate accounting agent. 37 However, unless the roaming relationship path is authenticated by some 38 method (such as via tokens or certificates returned by the home 39 authentication server), hierarchical authentication routing must be 40 used in order to validate the path. 42 3. Introduction 44 Considerable interest has arisen recently in a set of features that 45 fit within the general category of "roaming capability" for dialup 46 Internet users. Interested parties have included: 48 Regional Internet Service Providers (ISPs) operating within a 49 particular state or province, looking to combine their efforts 50 with those of other regional providers to offer dialup service 51 over a wider area. 53 National ISPs wishing to combine their operations with those of 54 one or more ISPs in another nation to offer more comprehensive 55 dialup service in a group of countries or on a continent. 57 Businesses desiring to offer their employees a comprehensive 58 package of dialup services on a global basis. Those services may 59 include Internet access as well as secure access to corporate 60 intranets via a Virtual Private Network (VPN), enabled by tunnel- 61 ing protocols such as PPTP, L2F, or L2TP. 63 This document describes the use of the Roaming Relationship (REL) 64 record in the DNS for the description of roaming relationships. REL 65 resource records may be used for determining the existence of a roam- 66 ing relationship path between the local ISP and the user's home 67 domain, as well as the location of an appropriate accounting agent. 68 However, unless the roaming relationship path is authenticated by some 69 method (such as via tokens or certificates returned by the home 70 authentication server), hierarchical authentication routing must be 71 used in order to validate the path. 73 3.1. Terminology 75 This document frequently uses the following terms: 77 roaming relationship path 78 The roaming relationship path is the series of roaming rela- 79 tionships that link together a local ISP and user's home 80 domain. The roaming relationship path may or may not be the 81 same as the authentication route, depending on whether the 82 local proxy is able to directly contact the home authentica- 83 tion server. 85 authentication route 86 The route that an authentication will take in traveling 87 between the local ISP's authentication proxy and the home 88 authentication server. Where RADIUS proxy authentication is 89 used, the authentication route follows the roaming relation- 90 ship path. 92 Network Access Server 93 The Network Access Server (NAS) is the device that clients 94 dial in order to get access to the network. 96 RADIUS server 97 This is a server which provides for authentication/autho- 98 rization via the protocol described in [3], and for account- 99 ing as described in [4]. 101 RADIUS proxy 102 In order to provide for the routing of RADIUS authentication 103 and accounting requests, a RADIUS proxy may employed. To the 104 NAS, the RADIUS proxy appears to act as a RADIUS server, and 105 to the RADIUS server, the proxy appears to act as a RADIUS 106 client. 108 RADIUS domain 109 In order to provide for the routing of RADIUS authentication 110 and accounting requests, the userID field used in PPP and in 111 the subsequent RADIUS authentication and accounting 112 requests, may contain structure. This structure provides a 113 means by which the RADIUS proxy will locate the RADIUS 114 server that is to receive the request. 116 3.2. Requirements language 118 This specification uses the same words as [14] for defining the sig- 119 nificance of each particular requirement. These words are: 121 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 122 that the definition is an absolute requirement of the speci- 123 fication. 125 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 126 nition is an absolute prohibition of the specification. 128 SHOULD This word, or the adjective "RECOMMENDED", means that there 129 may exist valid reasons in particular circumstances to 130 ignore a particular item, but the full implications must be 131 understood and carefully weighed before choosing a different 132 course. 134 SHOULD NOT 135 This phrase means that there may exist valid reasons in par- 136 ticular circumstances when the particular behavior is 137 acceptable or even useful, but the full implications should 138 be understood and the case carefully weighed before imple- 139 menting any behavior described with this label. 141 MAY This word, or the adjective "OPTIONAL", means that an item 142 is truly optional. One vendor may choose to include the 143 item because a particular marketplace requires it or because 144 the vendor feels that it enhances the product while another 145 vendor may omit the same item. An implementation which does 146 not include a particular option MUST be prepared to interop- 147 erate with another implementation which does include the 148 option, though perhaps with reduced functionality. In the 149 same vein an implementation which does include a particular 150 option MUST be prepared to interoperate with another imple- 151 mentation which does not include the option.(except, of 152 course, for the feature the option provides) 154 An implementation is not compliant if it fails to satisfy one or more 155 of the must or must not requirements for the protocols it implements. 156 An implementation that satisfies all the must, must not, should and 157 should not requirements for its protocols is said to be 158 "unconditionally compliant"; one that satisfies all the must and must 159 not requirements but not all the should or should not requirements for 160 its protocols is said to be "conditionally compliant." 162 4. The Roaming Relationship (REL) Record 164 In order to enable roaming, it is necessary for a local provider to be 165 able to determine whether a roaming relationship path exists between 166 itself and the user's home domain, so as to enable the local provider 167 to be paid for the use of its resources. These roaming relationships 168 are typically of two types: the relationship between a firm and a 169 provider, in which the firm delegates roaming authority to the 170 provider; or the relationship between a provider and a roaming associ- 171 ation, in which the provider agrees to allow members of the consortium 172 to access its network resources, in exchange for compensation. How- 173 ever, it is also possible for a company or even an individual to form 174 a direct relationship with a roaming consortia, or for consortia to 175 form a relationship with another consortia. 177 Inter-domain roaming relationships may extend to several levels. For 178 example, BIGCO may delegate roaming authority to ISPA, who may in turn 179 join roaming association ISPGROUP. When Fred dials into ISPB and 180 attempts to authenticate as fred@bigco.com, it is necessary for ISPB 181 to determine whether it has a means for being paid for the resources 182 consumed by Fred. This is accomplished by tracing the web of roaming 183 relationships backwards from the bigco.com domain, in order to deter- 184 mine whether a path of roaming relationships exists between ISPB and 185 BIGCO. 187 Please note that the task of determining the path of roaming relation- 188 ships is orthogonal to the issue of authentication routing. Where 189 authentication proxy chaining is used, authentication routing is 190 required in order to improve scalability. However, when public key 191 authentication is available, it is possible for an authentication 192 proxy to directly contact a home authentication server. However, 193 regardless of how the authentication is routed, it is still necessary 194 for the local ISP to determine the path of roaming relationships so 195 that it can determine whether it can be paid for the transaction. 197 The purpose of the Roaming Relationship (REL) resource record is to 198 document inter-domain roaming relationships. When hierarchical authen- 199 tication routing is being used, REL resource records are typically 200 retrieved by the local ISP's authentication proxy, and used both for 201 determination of the roaming relationship path as well as for use in 202 authentication routing. If public key authentication technology is 203 available, it may be possible for the local ISP's authentication proxy 204 to contact the home domain's authentication server directly. In this 205 case, hierarchical authentication routing will not be required, and 206 the home authentication server may return tokens or certificates in 207 order to validate the roaming relationship path. If this is done, then 208 the local ISP's authentication proxy may not need to look up any REL 209 resource records itself, and as a result, the total time required for 210 the authentication will be decreased. This will lessen the probability 211 of a timeout. 213 4.1. REL resource record RDATA format 215 The RDATA for a REL resource record is as follows: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Preference | Flags | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 / / 223 / Domain / 224 / / 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 4.1.1. Preference 229 The Preference field, which is two octets, specifies the preference 230 given to this record versus other records of the same type and owner. 231 Lower values are preferred. 233 4.1.2. Flags 235 The flags field, which is two octets, is as follows: 236 0 1 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |U P C A I F H R R R R R R R R R| 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 U = User. If U=1, then the REL resource record represents an individ- 243 ual user or account. The user name is represented the same way as in 244 the SOA or RP resource records. As a result, fred@bigco.com will be 245 represented as fred.bigco.com. Since the DNS was not intended for use 246 as a user database, it is expected that this flag will only be set on 247 rare occasions. 249 P = Provider. If P=1, then the REL resource record represents delega- 250 tion of roaming authority from a non-ISP to an ISP or a roaming con- 251 sortia. 253 C = Consortia. If C=1, then the REL resource record represents delega- 254 tion of roaming authority from an ISP to a roaming consortia. 256 A = Accounting agent. If A=1, then a accounting agent exists within 257 the domain. 259 I = Internet access. If I=1, then the REL resource record may be used 260 for provisioning of Internet access. In roaming applications this bit 261 MUST be set. 263 F = Fax. If F=1, then the REL resource record may be used for provi- 264 sioning of Internet fax. 266 H = H.323. If H=1, then the REL resource record may be used for provi- 267 sioning of H.323 conferencing. 269 R = Reserved. 271 4.1.3. Domain 273 The domain field represents the domain name to which roaming authority 274 has been delegated by the owner name. 276 4.2. Use of the Roaming Relationship (REL) Resource Record 278 The Roaming Relationship (REL) resource record uses semantics similar 279 to that of the Mail Exchange (MX) record, in that it includes a prior- 280 ity as well as the domain to which roaming authority has been dele- 281 gated. The REL resource record is of the form: 283 bigco.com. IN REL 10 (; priority 284 ispa.com. ;domain with roaming authority 285 P I ;flags. P = Provider, I = Internet Access 286 ) 288 Here 10 refers to the priority of the REL resource record, and 289 ispa.com is the domain to which BIGCO has delegated roaming responsi- 290 bilities. The use of a priority field allows multiple relationships to 291 be represented, with authenticating ISPs checking the relationships in 292 ascending order of priority. Thus, an REL resource record of priority 293 10 would be checked before a REL resource record of priority 20. As 294 described in the previous section, letters are used to denote flag 295 bits. 297 Routes for a given domain SHOULD be given different priorities, so as 298 to allow for predictable behavior. Since routes at the same priority 299 will be round-robined, this will result in alternation of routes. 300 Unless there is a good reason for balancing the load this way, this 301 approach SHOULD NOT be used. 303 5. Examples 305 5.1. Example One 307 Let us assume that Fred is an employee of BIGCO, who has established 308 roaming relationships with ISPA and ISPC, both of which are members of 309 roaming consortia ISPGROUP1. BIGCO also has a relationship with clear- 310 ing houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the ISPGROUP1 311 roaming consortia. 313 The REL resource records for BIGCO appear as follows: 315 bigco.com. IN REL 10 ispa.com. P I 316 bigco.com. IN REL 20 ispc.com. P I 317 bigco.com. IN REL 30 ispgroup3.com. P I 318 bigco.com. IN REL 40 ispgroup2.com. P I 320 The REL resource records for ISPA, ISPB, ISPC, ISPGROUP1, ISPGROUP2 321 and ISPGROUP3 appear as follows: 323 ispa.com. IN REL 10 ispgroup1.com. C I 325 ispb.com. IN REL 10 ispgroup1.com. C I 327 ispc.com. IN REL 10 ispgroup1.com. C I 329 ispgroup1.com. IN REL 10 ispgroup1.com. C I A 331 ispgroup2.com. IN REL 10 ispgroup2.com. C I A 333 ispgroup3.com. IN REL 10 ispgroup3.com. C I A 335 5.1.1. Sequence of events 337 Fred logs into ISPB as fred@bigco.com; as a result the ISPB authenti- 338 cation proxy receives this NAI. ISPB's authentication proxy first 339 checks for the presence of a user record for fred.bigco.com. If so, 340 then it retrieves the REL resource records for the domain to whom Fred 341 has delegated roaming authority. If there is no user record, then it 342 checks its configuration files to see whether bigco.com is one of the 343 domains with whom it has a direct roaming relationship. This check 344 will fail since BIGCO has no direct roaming relationship with ISPB. As 345 a result, ISPB's authentication proxy will need to retrieve REL 346 resource records either from its own cache or from the bigco.com zone. 348 Assuming that ISPB's authentication proxy does not support public key 349 authentication, then hierarchical authentication routing will be used. 350 In this case, ISPB's authentication proxy will need to retrieve REL 351 resource records from the bigco.com zone. If ISPB's authentication 352 proxy supports public key authentication and ISPEC, then rather than 353 immediately retrieving REL resource records, it will retrieve the SRV, 354 KEY and SIG resource records for the bigco.com zone. Using the SRV 355 resource record, ISPB's authentication proxy can locate the authenti- 356 cation proxy for the bigco.com domain. The SIG resource records for 357 the bigco.com zone can then be retrieved in order to determine whether 358 the bigco.com authentication server supports public key authentica- 359 tion. If so, then ISPB's authentication proxy may contact the 360 bigco.com authentication server directly. In its authentication reply, 361 the bigco.com authentication server may return the REL resource 362 records for its zone as well as those of the zones to which it has 363 delegated roaming authority, in the form of attributes within the 364 Access-Reply. If so, then ISPB's authentication proxy will be saved 365 the work of having to retrieve these resource records itself prior to 366 forwarding the authentication reply on to the NAS. 368 Once the REL resource records have been retrieved by one mechanism or 369 another, a depth first search is performed in order to select the 370 roaming relationship path. In this case, ISPB determines whether it 371 has a direct roaming relationship with ISPA (priority 10 record from 372 the bigco.com zone). If not, then it looks at the REL resource records 373 for the ispa.com domain, and determines whether it has a direct roam- 374 ing relationship with any of the domains to whom ISPA has delegated 375 roaming responsibility. In this case, ISPB determines that it has a 376 direct roaming relationship with ISPGROUP1 (priority 10 record from 377 the ispa.com zone). As a result, the roaming relationship path 378 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 379 operates an accounting agent within its domain, accounting records for 380 the transaction will be sent to ISPGROUP1's accounting agent. 382 If ISPA had not been a member of the ISPGROUP1 roaming consortia, then 383 the depth-first search would have terminated, and ISPB would proceed 384 to check for a business relationship on the branch represented by the 385 priority 20 REL resource record in the bigco.com zone (ispc.com). In 386 this case the roaming relationship path bigco.com/ispc.com/isp- 387 group1.com/ispb.com would have been selected. 389 If ISPB were a member of the ISPGROUP3 roaming consortia, and not a 390 member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first 391 search would fail on both the priority 10 and 20 branches of the 392 bigco.com tree. In this case, the business relationship path 393 bigco.com/ispgroup3.com/ispb.com would have been selected. 395 5.2. Example Two 397 Let us assume that BIGCO has branch offices in multiple locations. The 398 BIGCO branch office in Illinois has a contract with ISPA, which is a 399 member of ISPGROUP1. However, ISPGROUP1 does not have coverage in 400 Israel. As a result, the branch office in Israel has a contract with 401 ISPC, which is a member of ISPGROUP2, which does have coverage in 402 Israel. It is desired that Fred be able to login either from Illinois 403 or from Israel, with the authentication being done by the appropriate 404 ISP. When logging in from Illinois, Fred uses the POPs of ISPB, while 405 in Israel, he uses the POPs of ISPD. It should be noted that ISPA and 406 ISPC can be located anywhere; they need not necessarily reside in 407 Illinois or Israel. 409 In this case, the REL records for BIGCO will appear as follows: 411 bigco.com. IN REL 10 ispa.com. P I 412 bigco.com. IN REL 20 ispc.com. P I 414 The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear 415 as follows: 417 ispa.com. IN REL 10 ispgroup1.com. C I 418 ispb.com. IN REL 10 ispgroup1.com. C I 420 ispc.com. IN REL 10 ispgroup2.com. C I 422 ispd.com. IN REL 10 ispgroup2.com. C I 424 ispgroup1.com. IN REL 10 ispgroup1.com. C I A 426 ispgroup2.com. IN REL 10 ispgroup2.com. C I A 428 5.2.1. Sequence of events 430 While in the United States, Fred logs into ISPB as fred@bigco.com; as 431 a result the ISPB authentication proxy receives this NAI. ISPB's 432 authentication proxy first checks for the presence of a user record 433 for fred.bigco.com. If so, then it retrieves the REL resource records 434 for the domain to whom Fred has delegated roaming authority. If there 435 is no user record, then it checks its configuration files to see 436 whether bigco.com is one of the domains with whom it has a direct 437 roaming relationship. This check will fail since BIGCO has no direct 438 roaming relationship with ISPB. As a result, ISPB's authentication 439 proxy will need to retrieve resource records either from its own cache 440 or from the bigco.com zone. 442 Once the REL resource records have been retrieved by one mechanism or 443 another, a depth first search is performed in order to select the 444 roaming relationship path. In this case, ISPB determines whether it 445 has a direct roaming relationship with ISPA (priority 10 record from 446 the bigco.com zone). If not, then it looks at the REL resource records 447 for the ispa.com domain, and determines whether it has a direct roam- 448 ing relationship with any of the domains to whom ISPA has delegated 449 roaming responsibility. In this case, ISPB determines that it has a 450 direct roaming relationship with ISPGROUP1 (priority 10 record from 451 the ispa.com zone). As a result, the roaming relationship path 452 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 453 operates a accounting agent within its domain, accounting records for 454 the transaction will be sent to ISPGROUP1's accounting agent. 456 While in Israel, Fred logs into ISPD as fred@bigco.com; as a result, 457 the ISPD authentication proxy receives this NAI. ISPD's authentication 458 proxy then checks its configuration files to see whether bigco.com is 459 one of the domains with whom it has a direct roaming relationship. 460 This check will fail since BIGCO has no direct roaming relationship 461 with ISPD. As a result, ISPD's authentication proxy will need to 462 retrieve REL resource records either from its own cache or from the 463 bigco.com zone. 465 Once the REL resource records have been retrieved by one mechanism or 466 another, a depth first search is performed in order to select the 467 roaming relationship path. In this case, ISPD determines whether it 468 has a direct roaming relationship with ISPA (priority 10 record from 469 the bigco.com zone). If not, then it looks at the REL resource records 470 for the ispa.com domain, and determines whether it has a direct 471 roaming relationship with any of the domains to whom ISPA has dele- 472 gated roaming responsibility. In this case, ISPD determines that no 473 roaming relationship path exists passing through ISPA. 475 As a result, ISPD checks for a roaming relationship path on the ISPC 476 branch (priority 20 REL resource record from the bigco.com zone). 477 First, it determines whether there is a direct roaming relationship 478 between ISPD and ISPC (there is not). Then it looks at the REL records 479 for the ispc.com domain, and determines whether it has a direct roam- 480 ing relationship with any of the domains to whom ISPC has delegated 481 roaming responsibility. In this case, ISPD determines that it has a 482 direct roaming relationship with ISPGROUP2 (priority 10 REL resource 483 record from the ispc.com zone). As a result, the roaming relationship 484 path bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISP- 485 GROUP2 operates a accounting agent within its domain, accounting 486 records for the transaction will be sent to ISPGROUP2's accounting 487 agent. 489 5.3. Example Three 491 Let us assume that Fred wishes to travel to a country which is not 492 served by the roaming consortia that BIGCO's provider ISPA has joined. 493 In this case, Fred will wish to make use of the user REL resource 494 record. 496 In this case, the REL resource records for BIGCO will appear as fol- 497 lows: 499 bigco.com. IN REL 10 ispa.com. P I 500 fred.bigco.com. IN REL 10 ispe.com. U I 502 The records for ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as 503 follows: 505 ispa.com. IN REL 10 ispgroup1.com. C I 507 ispb.com. IN REL 10 ispgroup1.com. C I 508 ispb.com. IN REL 10 ispgroup2.com. C I 510 ispe.com. IN REL 10 ispgroup2.com. C I 512 ispgroup1.com. IN REL 10 ispgroup1.com. C I A 514 ispgroup2.com. IN REL 10 ispgroup2.com. C I A 516 5.3.1. Sequence of events 518 While traveling, Fred logs into ISPB as fred@bigco.com; as a result 519 the ISPB authentication proxy receives this NAI. ISPB's authentication 520 proxy first checks for the presence of a user record for 521 fred.bigco.com. If so, then it retrieves the REL resource records for 522 the domain to whom Fred has delegated roaming authority. In this case, 523 a user record exists for fred@bigco.com, so that the authentication 524 proxy determines whether it has a direct roaming relationship with 525 ISPE (priority 10 REL resource record from the fred.bigco.com zone). 526 If not, then it looks at the REL resource records for the ispe.com 527 domain, and determines whether it has a direct roaming relationship 528 with any of the domains to whom ISPE has delegated roaming responsi- 529 bility. In this case, ISPB determines that it has a direct roaming 530 relationship with ISPGROUP2 (priority 10 REL resource record from the 531 ispe.com zone). As a result, the roaming relationship path 532 fred.bigco.com/ispe.com/ispgroup2.com/ispb.com is selected. Since ISP- 533 GROUP2 operates a accounting agent within its domain, accounting 534 records for the transaction will be sent to ISPGROUP2's accounting 535 agent. 537 Please note that even though Fred has a user REL resource record, the 538 authentication conversation will still be conducted between ISPB's 539 authentication proxy and BIGCO's authentication server. 541 6. Prevention of looping topologies 543 Since it is possible to create looping topologies using REL resource 544 records, a mechanism must be provided to prevent endless loops. As a 545 result, it is recommended that authentication proxies be configured 546 with a default maximum of four hops. This would support the scenario 547 of an authentication passing from a NAS to an authentication proxy, 548 from the proxy to ISPGROUP, from ISPGROUP to ISPA, and from ISPA to 549 BIGCO. 551 7. Use of the REL RR 553 When REL resource records are utilized, no assurance can be provided 554 as to the authenticity of the roaming relationships represented by 555 these records. As a result, it is necessary to verify the validity of 556 the roaming relationship path by another means. This can be accom- 557 plished by causing the authentication to be routed along the roaming 558 relationship path, or by verifying the authenticity of a certificate 559 or token returned by the home authentication server. 561 As an example, let us assume that the roaming relationship path 562 bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. If this path 563 has not been authenticated, then ISPD's authentication proxy will for- 564 ward it's authentication request to ISPGROUP2, including the roaming 565 relationship path as a source route. ISPGROUP2 will then in turn for- 566 ward the authentication to ISPC, who will forward it to BIGCO. At each 567 step of the way, a pre-existing relationship will need to exist 568 between hops in order for this authentication forwarding to proceed. 569 As a result, the act of authenticating Fred via the roaming relation- 570 ship path acts to validate the roaming relationship as determined from 571 the REL resource records. 573 Note that such hop by hop forwarding may be required even if public 574 key authentication is available for use between the local ISP's 575 authentication proxy and the home authentication server. As long as 576 the roaming relationship path has not been authenticated, the local 577 ISP will still need to validate the roaming relationship path. This 578 can be accomplished by forcing the authentication to follow the roam- 579 ing relationship path, validating the relationships between the prox- 580 ies at each hop. 582 Please also note that public key authentication will also typically be 583 used in order to enable signed receipts to be returned by the account- 584 ing agent in response to receipt of digitally signed accounting record 585 bundles. DNS security can assist in determining what security features 586 are implemented at a given home authentication server or accounting 587 agent. Accounting agent support for MIME Security Multiparts is indi- 588 cated via use of the Email bit within the KEY resource record flag 589 field. DNS security may also be used to indicate that a home authenti- 590 cation server supports IPSEC. This is indicated via use of the IPSEC 591 bit within the KEY resource record flag field. 593 8. Acknowledgements 595 Thanks to Glen Zorn of Microsoft, Pat Calhoun of USR, and Michael 596 Robinson of Global One for many useful discussions of this problem 597 space. 599 9. References 601 [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- 602 tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass 603 Alliance, Asiainfo, January, 1997. 605 [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- 606 roamops-roamreq-02.txt, Microsoft, January, 1997. 608 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 609 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 610 Daydreamer, January, 1997. 612 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 613 1997. 615 [5] R. Fajman. "An Extensible Message Format for Message Disposition 616 Notifications." draft-ietf-receipt-mdn-02.txt, National Institute of 617 Health, November, 1996. 619 [6] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC 620 2015, The Aerospace Corporation, October, 1996. 622 [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting 623 of Mail System Administrative Messages." RFC 1892, Octel Network Ser- 624 vices, January, 1996. 626 [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed 627 and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo- 628 ber, 1995. 630 [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- 631 denburg Consulting, March, 1995. 633 [10] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure 634 EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp, Drummond 635 Group, November, 1996. 637 [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for 638 Inter-operable Internet EDI." draft-ietf-ediint-req-01.txt, Actra, 639 LiNK, Drummond Group, May, 1995. 641 [12] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location 642 of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- 643 prises, October 1996. 645 [13] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security 646 Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 647 1996. 649 [14] S. Bradner. "Key words for use in RFCs to Indicate Requirement 650 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 651 1996. 653 [15] C. Malmud, M. Rose. "Principles of Operation for the TPC.INT 654 Subdomain: General Principles and Policy." RFC 1530, Internet Multi- 655 casting Service, Dover Beach Consulting, Inc., October, 1993. 657 10. Authors' Addresses 659 Bernard Aboba 660 Microsoft Corporation 661 One Microsoft Way 662 Redmond, WA 98052 664 Phone: 206-936-6605 665 EMail: bernarda@microsoft.com