idnits 2.17.1 draft-ietf-roamops-dnsrr-01.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 15 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 15 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 275 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 418 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 130: '... MUST This word, or the ad...' RFC 2119 keyword, line 134: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 137: '... SHOULD This word, or the adjec...' RFC 2119 keyword, line 143: '... SHOULD NOT...' RFC 2119 keyword, line 150: '... MAY This word, or the adjec...' (7 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...' == (270 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 (1 March 1997) is 9916 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 690, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 694, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 708, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 711, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 715, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 719, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 722, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 730, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 742, 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 (~~), 24 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 1 March 1997 7 The Roaming Relationship (RR) 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 1, 1997. Please 28 send comments to the authors. 30 2. Abstract 32 This document describes the use of the Roaming Relationship (RR) 33 record in the DNS for the description of roaming relationships. In the 34 absence of DNS security, RR records may be used for determining the 35 existence of a roaming relationship path between the local ISP and the 36 user's home domain, as well as the location of an appropriate account- 37 ing agent. However, since the RR records are not secured, other meth- 38 ods (such as hierarchical authentication routing) must be used in 39 order to validate the roaming relationship path. When DNS security is 40 implemented, the roaming relationship path is authenticated via digi- 41 tal signatures, and as a result, additional services may be provided, 42 such as non-repudiation of proxied authentications and signed receipts 43 for accounting record transfers. 45 3. Introduction 47 Considerable interest has arisen recently in a set of features that 48 fit within the general category of "roaming capability" for dialup 49 Internet users. Interested parties have included: 51 Regional Internet Service Providers (ISPs) operating within a 52 particular state or province, looking to combine their efforts 53 with those of other regional providers to offer dialup service 54 over a wider area. 56 National ISPs wishing to combine their operations with those of 57 one or more ISPs in another nation to offer more comprehensive 58 dialup service in a group of countries or on a continent. 60 Businesses desiring to offer their employees a comprehensive 61 package of dialup services on a global basis. Those services may 62 include Internet access as well as secure access to corporate 63 intranets via a Virtual Private Network (VPN), enabled by tunnel- 64 ing protocols such as PPTP, L2F, or L2TP. 66 This document describes the use of the Roaming Relationship (RR) 67 record in the DNS for the description of inter-domain roaming rela- 68 tionships, as required for enabling of roaming and other inter- 69 provider services. In the absence of DNS security, RR records may be 70 used for determining the existence of a roaming relationship between 71 the local ISP and the user's home domain, as well as the location of 72 an appropriate accounting agent. However, since the RR records are not 73 secured, other methods (such as hierarchical authentication routing) 74 must be used in order to validate the roaming relationship path. When 75 DNS security is implemented as described in [13], the roaming rela- 76 tionship path is authenticated via digital signatures, and as a 77 result, additional services may be provided, such as non-repudiation 78 of proxied authentications and signed receipts for accounting record 79 transfers. The latter capability is described in references [5] - 80 [11]. 82 3.1. Terminology 84 This document frequently uses the following terms: 86 roaming relationship path 87 The roaming relationship path is the series of roaming rela- 88 tionships that link together a local ISP and user's home 89 domain. The roaming relationship path may or may not be the 90 same as the authentication route, depending on whether the 91 local proxy is able to directly contact the home authentica- 92 tion server. 94 authentication route 95 The route that an authentication will take in traveling 96 between the local ISP's authentication proxy and the home 97 authentication server. Where RADIUS proxy authentication is 98 used, the authentication route follows the roaming relation- 99 ship path. 101 Network Access Server 102 The Network Access Server (NAS) is the device that clients 103 dial in order to get access to the network. 105 RADIUS server 106 This is a server which provides for authentication/autho- 107 rization via the protocol described in [3], and for account- 108 ing as described in [4]. 110 RADIUS proxy 111 In order to provide for the routing of RADIUS authentication 112 and accounting requests, a RADIUS proxy may employed. To the 113 NAS, the RADIUS proxy appears to act as a RADIUS server, and 114 to the RADIUS server, the proxy appears to act as a RADIUS 115 client. 117 RADIUS domain 118 In order to provide for the routing of RADIUS authentication 119 and accounting requests, the userID field used in PPP and in 120 the subsequent RADIUS authentication and accounting 121 requests, may contain structure. This structure provides a 122 means by which the RADIUS proxy will locate the RADIUS 123 server that is to receive the request. 125 3.2. Requirements language 127 This specification uses the same words as [14] for defining the sig- 128 nificance of each particular requirement. These words are: 130 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 131 that the definition is an absolute requirement of the speci- 132 fication. 134 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 135 nition is an absolute prohibition of the specification. 137 SHOULD This word, or the adjective "RECOMMENDED", means that there 138 may exist valid reasons in particular circumstances to 139 ignore a particular item, but the full implications must be 140 understood and carefully weighed before choosing a different 141 course. 143 SHOULD NOT 144 This phrase means that there may exist valid reasons in par- 145 ticular circumstances when the particular behavior is 146 acceptable or even useful, but the full implications should 147 be understood and the case carefully weighed before imple- 148 menting any behavior described with this label. 150 MAY This word, or the adjective "OPTIONAL", means that an item 151 is truly optional. One vendor may choose to include the 152 item because a particular marketplace requires it or because 153 the vendor feels that it enhances the product while another 154 vendor may omit the same item. An implementation which does 155 not include a particular option MUST be prepared to interop- 156 erate with another implementation which does include the 157 option, though perhaps with reduced functionality. In the 158 same vein an implementation which does include a particular 159 option MUST be prepared to interoperate with another imple- 160 mentation which does not include the option.(except, of 161 course, for the feature the option provides) 163 An implementation is not compliant if it fails to satisfy one or more 164 of the must or must not requirements for the protocols it implements. 165 An implementation that satisfies all the must, must not, should and 166 should not requirements for its protocols is said to be "uncondition- 167 ally compliant"; one that satisfies all the must and must not require- 168 ments but not all the should or should not requirements for its proto- 169 cols is said to be "conditionally compliant." 171 4. The Roaming Relationship (RR) Record 173 In order to enable roaming, it is necessary for a local provider to be 174 able to determine whether a roaming relationship path exists between 175 itself and the user's home domain, so as to enable the local provider 176 to be paid for the use of its resources. These roaming relationships 177 are typically of two types: the relationship between a firm and a 178 provider, in which the firm delegates roaming authority to the 179 provider; or the relationship between a provider and a roaming associ- 180 ation, in which the provider agrees to allow members of the consortium 181 to access its network resources, in exchange for compensation. How- 182 ever, it is also possible for a company or even an individual to form 183 a direct relationship with a roaming consortia, or for consortia to 184 form a relationship with another consortia. 186 Inter-domain roaming relationships may extend to several levels. For 187 example, BIGCO may delegate roaming authority to ISPA, who may in turn 188 join roaming association ISPGROUP. When Fred dials into ISPB and 189 attempts to authenticate as fred@bigco.com, it is necessary for ISPB 190 to determine whether it has a means for being paid for the resources 191 consumed by Fred. This is accomplished by tracing the web of roaming 192 relationships backwards from the bigco.com domain, in order to deter- 193 mine whether a path of roaming relationships exists between ISPB and 194 BIGCO. 196 Please note that the task of determining the path of roaming relation- 197 ships is orthogonal to the issue of authentication routing. Where 198 authentication proxy chaining is used, authentication routing is 199 required in order to improve scalability. However, when public key 200 authentication is available, it is possible for an authentication 201 proxy to directly contact a home authentication server. However, 202 regardless of how the authentication is routed, it is still necessary 203 for the local ISP to determine the path of roaming relationships so 204 that it can determine whether it can be paid for the transaction. 206 The purpose of the Roaming Relationship (RR) record is to document 207 inter-domain roaming relationships. Where DNS Security is enabled, it 208 is possible for these relationships to be authenticated via use of the 209 KEY and SIG RRs. In order to authenticate the existence of a roaming 210 relationship, the domain to which roaming authority has been delegated 211 signs the KEY RR of the domain which has done the delegation. The sig- 212 nature includes an expiration date, as well as the KEY RR itself, and 213 it is expected that the expiration dates SHOULD NOT be far in the 214 future. As a result, it is expected that the roaming authority will 215 update the SIG RR periodically in order to enable the relationship to 216 continue. 218 Please note that Roaming Relationship (RR) records may be retrieved in 219 a variety of ways. When hierarchical authentication routing is being 220 used, RR records are typically retrieved by the local ISP's authenti- 221 cation proxy, and used both for the determination of a roaming rela- 222 tionship, and for use in authentication routing. When public key 223 authentication, IPSEC and DNS security are available, then it is pos- 224 sible for the local ISP's authentication proxy to contact the home 225 domain's authentication server directly. In this case, hierarchical 226 authentication routing is not necessary, and it is possible for the 227 home domain's authentication server to return signed Roaming Relation- 228 ship resource records to the local ISP's authentication proxy as 229 attributes within the authentication reply. If this is done, then the 230 local ISP's authentication proxy may not need to look up any Roaming 231 Relationship resource records itself, and as a result, the total time 232 required for the authentication will be decreased. This will lessen 233 the probability of a timeout. 235 4.1. Roaming Relationship resource record RDATA format 237 The RDATA for a Roaming Relationship resource record is as follows: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Preference | Flags | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 / / 245 / Domain / 246 / / 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 4.1.1. Preference 251 The Preference field, which is two octets, specifies the preference 252 given to this record versus other records of the same type and owner. 253 Lower values are preferred. 255 4.1.2. Flags 257 The flags field, which is two octets, is as follows: 258 0 1 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 |U P C S I F H R R R R R R R R R| 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 U = User. If U=1, then the Roaming Relationship record represents an 265 individual user or account. The user name is represented the same way 266 as in the SOA or RP resource records. As a result, fred@bigco.com will 267 be represented as fred.bigco.com. Since the DNS was not intended for 268 use as a user database, it is expected that this flag will only be set 269 on rare occasions. 271 P = Provider. If P=1, then the Roaming Relationship record represents 272 delegation of roaming authority from a non-ISP to an ISP or a roaming 273 consortia. 275 C = Consortia. If C=1, then the Roaming Relationship record represents 276 delegation of roaming authority from an ISP to a roaming consortia. 278 S = Accounting agent. If S=1, then a accounting agent exists within 279 the domain. 281 I = Internet access. If I=1, then the Roaming Relationship record may 282 be used for provisioning of Internet access. In roaming applications 283 this bit MUST be set. 285 F = Fax. If F=1, then the Roaming Relationship record may be used for 286 provisioning of Internet fax. 288 H = H.323. If H=1, then the Roaming Relationship may be used for pro- 289 visioning of H.323 conferencing. 291 R = Reserved. 293 4.1.3. Domain 295 The domain field represents the domain name to which roaming authority 296 has been delegated by the owner name. 298 4.2. Use of the Roaming Relationship (RR) Record 300 The Roaming Relationship (RR) record uses semantics similar to that of 301 the Mail Exchange (MX) record, in that it includes a priority as well 302 as the domain to which roaming authority has been delegated. The RR 303 record is of the form: 305 bigco.com. IN RR 306 10 ;priority 307 P I ;flags. P = Provider, I = Internet Access 308 ispa.com. ;domain with roaming authority 310 Here 10 refers to the priority of the RR record, and ispa.com is the 311 domain to which BIGCO has delegated roaming responsibilities. The use 312 of a priority field allows multiple relationships to be represented, 313 with authenticating ISPs checking the relationships in ascending order 314 of priority. Thus, an RR record of priority 10 would be checked before 315 a record of priority 20. As described in the previous section, letters 316 are used to denote flag bits. 318 Routes for a given domain SHOULD be given different priorities, so as 319 to allow for predictable behavior. Since routes at the same priority 320 will be round-robined, this will result in alternation of routes. 321 Unless there is a good reason for balancing the load this way, this 322 approach SHOULD NOT be used. 324 5. Examples 326 5.1. Example One 328 Let us assume that Fred is an employee of BIGCO, who has established 329 roaming relationships with ISPA and ISPC, both of which are members of 330 roaming consortia ISPGROUP1. BIGCO also has a relationship with clear- 331 ing houses ISPGROUP2 and ISPGROUP3. ISPB is a member of the ISPGROUP1 332 roaming consortia. 334 The Roaming Relationship records for BIGCO appear as follows: 336 bigco.com. IN RR 10 P I ispa.com. 337 bigco.com. IN RR 20 P I ispc.com. 338 bigco.com. IN RR 30 P I ispgroup3.com. 339 bigco.com. IN RR 40 P I ispgroup2.com. 341 The RR records for ISPA, ISPB, ISPC, ISPGROUP1, ISPGROUP2 and ISP- 342 GROUP3 appear as follows: 344 ispa.com. IN RR 10 C I ispgroup1.com. 346 ispb.com. IN RR 10 C I ispgroup1.com. 348 ispc.com. IN RR 10 C I ispgroup1.com. 350 ispgroup1.com. IN RR 10 C I S ispgroup1.com. 352 ispgroup2.com. IN RR 10 C I S ispgroup2.com. 354 ispgroup3.com. IN RR 10 C I S ispgroup3.com. 356 5.1.1. Sequence of events 358 Fred logs into ISPB as fred@bigco.com; as a result the ISPB authenti- 359 cation proxy receives this NAI. ISPB's authentication proxy first 360 checks for the presence of a user record for fred.bigco.com. If so, 361 then it retrieves the RR resource records for the domain to whom Fred 362 has delegated roaming authority. If there is no user record, then it 363 checks its configuration files to see whether bigco.com is one of the 364 domains with whom it has a direct roaming relationship. This check 365 will fail since BIGCO has no direct roaming relationship with ISPB. As 366 a result, ISPB's authentication proxy will need to retrieve resource 367 records either from its own cache or from the bigco.com zone. 369 Assuming that ISPB's authentication proxy does not support public key 370 authentication and IPSEC, then hierarchical authentication routing 371 will be used. In this case, ISPB's authentication proxy will need to 372 retrieve RR resource records from the bigco.com zone. If ISPB's 373 authentication proxy supports public key authentication and ISPEC, 374 then rather than immediately retrieving RR resource records, it will 375 retrieve the SRV, KEY and SIG resource records for the bigco.com zone. 376 Using the SRV resource record, ISPB's authentication proxy can locate 377 the authentication proxy for the bigco.com domain. The SIG resource 378 records for the bigco.com zone can then be retrieved in order to 379 determine whether the bigco.com authentication server supports IPSEC. 380 If so, then ISPB's authentication proxy may contact the bigco.com 381 authentication server directly. In this case, only the IPSEC AH header 382 need be used, since only authentication services are required. In its 383 authentication reply, the bigco.com authentication server may return 384 the RR records for its zone as well as those of the zones to which it 385 has delegated roaming authority, in the form of attributes within the 386 Access-Reply. If so, then ISPB's authentication proxy will be saved 387 the work of having to retrieve these resource records itself prior to 388 forwarding the authentication reply on to the NAS. 390 Once the RR resource records have been retrieved by one mechanism or 391 another, a depth first search is performed in order to select the 392 roaming relationship path. In this case, ISPB determines whether it 393 has a direct roaming relationship with ISPA (priority 10 record from 394 the bigco.com zone). If not, then it looks at the RR records for the 395 ispa.com domain, and determines whether it has a direct roaming rela- 396 tionship with any of the domains to whom ISPA has delegated roaming 397 responsibility. In this case, ISPB determines that it has a direct 398 roaming relationship with ISPGROUP1 (priority 10 record from the 399 ispa.com zone). As a result, the roaming relationship path 400 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 401 operates a accounting agent within its domain, accounting records for 402 the transaction will be sent to ISPGROUP1's accounting agent. 404 If ISPA had not been a member of the ISPGROUP1 roaming consortia, then 405 the depth-first search would have terminated, and ISPB would proceed 406 to check for a business relationship on the branch represented by the 407 priority 20 record in the bigco.com zone (ispc.com). In this case the 408 roaming relationship path bigco.com/ispc.com/ispgroup1.com/ispb.com 409 would have been selected. 411 If ISPB were a member of the ISPGROUP3 roaming consortia, and not a 412 member of the ISPGROUP1 or ISPGROUP2 consortia, then the breadth-first 413 search would fail on both the priority 10 and 20 branches of the 414 bigco.com tree. In this case, the business relationship path 415 bigco.com/ispgroup3.com/ispb.com would have been selected. 417 5.2. Example Two 419 Let us assume that BIGCO has branch offices in multiple locations. The 420 BIGCO branch office in Illinois has a contract with ISPA, which is a 421 member of ISPGROUP1 while the branch office in Israel has a contract 422 with ISPC, which is a member of ISPGROUP2. As a result, it is desired 423 that Fred be able to login either from Illinois or from Israel, with 424 the authentication being done by the appropriate ISP. When logging in 425 from Illinois, Fred uses the POPs of ISPB, while in Israel, he uses 426 the POPs of ISPD. 428 In this case, the RR records for BIGCO will appear as follows: 430 bigco.com. IN RR 10 P I ispa.com. 431 bigco.com. IN RR 20 P I ispc.com. 433 The records for ISPA, ISPB, ISPC, ISPD, ISPGROUP1 and ISPGROUP2 appear 434 as follows: 436 ispa.com. IN RR 10 C I ispgroup1.com. 438 ispb.com. IN RR 10 C I ispgroup1.com. 440 ispc.com. IN RR 10 C I ispgroup2.com. 442 ispd.com. IN RR 10 C I ispgroup2.com. 444 ispgroup1.com. IN RR 10 C I S ispgroup1.com. 446 ispgroup2.com. IN RR 10 C I S ispgroup2.com. 448 5.2.1. Sequence of events 450 While in the United States, Fred logs into ISPB as fred@bigco.com; as 451 a result the ISPB authentication proxy receives this NAI. ISPB's 452 authentication proxy first checks for the presence of a user record 453 for fred.bigco.com. If so, then it retrieves the RR resource records 454 for the domain to whom Fred has delegated roaming authority. If there 455 is no user record, then it checks its configuration files to see 456 whether bigco.com is one of the domains with whom it has a direct 457 roaming relationship. This check will fail since BIGCO has no direct 458 roaming relationship with ISPB. As a result, ISPB's authentication 459 proxy will need to retrieve resource records either from its own cache 460 or from the bigco.com zone. 462 Once the RR resource records have been retrieved by one mechanism or 463 another, a depth first search is performed in order to select the 464 roaming relationship path. In this case, ISPB determines whether it 465 has a direct roaming relationship with ISPA (priority 10 record from 466 the bigco.com zone). If not, then it looks at the RR records for the 467 ispa.com domain, and determines whether it has a direct roaming rela- 468 tionship with any of the domains to whom ISPA has delegated roaming 469 responsibility. In this case, ISPB determines that it has a direct 470 roaming relationship with ISPGROUP1 (priority 10 record from the 471 ispa.com zone). As a result, the roaming relationship path 472 bigco.com/ispa.com/ispgroup1.com/ispb.com is selected. Since ISPGROUP1 473 operates a accounting agent within its domain, accounting records for 474 the transaction will be sent to ISPGROUP1's accounting agent. 476 While in Israel, Fred logs into ISPD as fred@bigco.com; as a result, 477 the ISPD authentication proxy receives this NAI. ISPD's authentication 478 proxy then checks its configuration files to see whether bigco.com is 479 one of the domains with whom it has a direct roaming relationship. 480 This check will fail since BIGCO has no direct roaming relationship 481 with ISPD. As a result, ISPD's authentication proxy will need to 482 retrieve resource records either from its own cache or from the 483 bigco.com zone. 485 Once the Roaming Relationship resource records have been retrieved by 486 one mechanism or another, a depth first search is performed in order 487 to select the roaming relationship path. In this case, ISPD determines 488 whether it has a direct roaming relationship with ISPA (priority 10 489 record from the bigco.com zone). If not, then it looks at the RR 490 records for the ispa.com domain, and etermines whether it has a direct 491 roaming relationship with any of the domains to whom ISPA has dele- 492 gated roaming responsibility. In this case, ISPD determines that no 493 roaming relationship path exists going through ISPA. 495 As a result, ISPD checks for a roaming relationship on the ISPC branch 496 (priority 20 record from the bigco.com zone). First, it determines 497 whether there is a direct roaming relationship between ISPD and ISPC 498 (there is not). Then it looks at the RR records for the ispc.com 499 domain, and determines whether it has a direct roaming relationship 500 with any of the domains to whom ISPC has delegated roaming responsi- 501 bility. In this case, ISPD determines that it has a direct roaming 502 relationship with ISPGROUP2 (priority 10 record from the ispc.com 503 zone). As a result, the roaming relationship path 504 bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. Since ISPGROUP2 505 operates a accounting agent within its domain, accounting records for 506 the transaction will be sent to ISPGROUP2's accounting agent. 508 5.3. Example Three 510 Let us assume that Fred wishes to travel to a country which is not 511 served by the roaming consortia that BIGCO's provider ISPA has joined. 512 In this case, Fred will wish to make use of the user roaming relation- 513 ship resource record. 515 In this case, the RR records for BIGCO will appear as follows: 517 bigco.com. IN RR 10 P I ispa.com. 518 fred.bigco.com. IN RR 10 U I ispe.com. 520 The records for ISPA, ISPB, ISPD, ISPGROUP1 and ISPGROUP2 appear as 521 follows: 523 ispa.com. IN RR 10 C I ispgroup1.com. 525 ispb.com. IN RR 10 C I ispgroup1.com. 526 ispb.com. IN RR 10 C I ispgroup2.com. 528 ispe.com. IN RR 10 C I ispgroup2.com. 530 ispgroup1.com. IN RR 10 C I S ispgroup1.com. 532 ispgroup2.com. IN RR 10 C I S ispgroup2.com. 534 5.3.1. Sequence of events 536 While traveling, Fred logs into ISPB as fred@bigco.com; as a result 537 the ISPB authentication proxy receives this NAI. ISPB's authentication 538 proxy first checks for the presence of a user record for 539 fred.bigco.com. If so, then it retrieves the RR resource records for 540 the domain to whom Fred has delegated roaming authority. In this case, 541 a user record exists for fred@bigco.com, so that the authentication 542 proxy determines whether it has a direct roaming relationship with 543 ISPE (priority 10 record from the fred.bigco.com zone). If not, then 544 it looks at the RR records for the ispe.com domain, and determines 545 whether it has a direct roaming relationship with any of the domains 546 to whom ISPE has delegated roaming responsibility. In this case, ISPB 547 determines that it has a direct roaming relationship with ISPGROUP2 548 (priority 10 record from the ispe.com zone). As a result, the roaming 549 relationship path fred.bigco.com/ispe.com/ispgroup2.com/ispb.com is 550 selected. Since ISPGROUP2 operates a accounting agent within its 551 domain, accounting records for the transaction will be sent to ISP- 552 GROUP2's accounting agent. 554 Please note that even though Fred has a user Roaming Relationship 555 record, the authentication conversation will still be conducted 556 between ISPB's authentication proxy and BIGCO's authentication server. 558 6. Prevention of looping topologies 560 Since it is possible to create looping topologies using Roaming Rela- 561 tionship records, a mechanism must be provided to prevent endless 562 loops. As a result, it is recommended that authentication proxies be 563 configured with a default maximum of four hops. This would support the 564 scenario of an authentication passing from a NAS to an authentication 565 proxy, from the proxy to ISPGROUP, from ISPGROUP to ISPA, and from 566 ISPA to BIGCO. 568 7. Use of the RR Record Without DNS Security 570 When Roaming Relationship resource records are utilized without DNS 571 security, no assurance can be provided as to the authenticity of the 572 roaming relationships represented by these records. As a result, it is 573 necessary to verify the validity of the roaming relationship path by 574 another means. This can be accomplished by causing the authentication 575 to be routed along the roaming relationship path. 577 As an example, let us assume that the roaming relationship path 578 bigco.com/ispc.com/ispgroup2.com/ispd.com is selected. If this path 579 has not been authenticated via DNS Security, then ISPD's authentica- 580 tion proxy will forward it's authentication request to ISPGROUP2, 581 including the business relationship path as a source route. ISPGROUP2 582 will then in turn forward the authentication to ISPC, who will forward 583 it to BIGCO. At each step of the way, a pre-existing relationship will 584 need to exist between hops in order for this authentication forwarding 585 to proceed. As a result, the act of authenticating Fred via the roam- 586 ing relationship path acts to validate the roaming relationship as 587 determined from the RR resource records. 589 Note that such hop by hop forwarding is required even if IPSEC and 590 public key authentication is available for use between the local ISP's 591 authentication proxy and the home authentication server, as long as 592 the roaming relationship path has not been authenticated via DNS Secu- 593 rity. This is because while the authentication end-points might be 594 able to communicate securely without need for hierarchical authentica- 595 tion routing, the local ISP still needs to validate the roaming rela- 596 tionship path. 598 Please also note that DNS Security will also typically be used in 599 order to enable signed receipts to be returned by the accounting agent 600 in response to receipt of digitally signed accounting record bundles. 601 Accounting agent support for MIME Security Multiparts is indicated via 602 use of the Email bit within the KEY resource record flag field. DNS 603 Security may also be used to indicate that a home authentication 604 server supports IPSEC. This is indicated via use of the IPSEC bit 605 within the KEY resource record flag field. 607 8. Use of the RR Record With DNS Security 609 When used in concert with DNS Security, RR resource records may be 610 authenticated. When used along with IPSEC, this permits direct commu- 611 nication between the local ISP's authentication proxy and the home 612 authentication server. In addition, support for DNS Security allows 613 for provision of additional services, such as non-repudiation of 614 authentication replies, as well as for return of signed receipts for 615 accounting record transfers. This is accomplished via use of the KEY, 616 and SIG resource records. 618 8.1. Use of KEY Resource Record 620 The KEY resource record is used in order to allow a public key to be 621 associated with a zone. 623 8.1.1. Flag Field 625 No additional flags need to be defined for use in roaming. When used 626 to secure Roaming Relationship resource records, bit 0 of the Key 627 resource record flag field MUST be cleared, indicating that use of the 628 key is allowed for authentication. Bit 1 may or may not be set to 629 indicate use for confidentiality. If the Roaming Relationship record 630 is for a user, then bit 5 will be set, indicating the use of the KEY 631 for a user or account. Bits 6 and 7 (none-zone entity and zone bits) 632 may or may not be set. If the KEY resource record is for an authenti- 633 cation server supporting IPSEC, then bit 8 will be set. If the KEY 634 resource record is for a accounting server supporting MIME Security 635 Multiparts, then bit 9 will be set. Bits 12-15, the signatory bits, 636 may or may not be set. 638 8.1.2. Protocol field 640 When used to secure Roaming Relationship resource records, the value 641 192 will be used in the protocol octet, in order to denote experimen- 642 tal use. Should roaming technology be deployed on a widespread basis, 643 then a value between 1 and 191 will be assigned by IANA. 645 8.2. Use of the SIG Resource Record 647 Since the Roaming Relationship record is signed by the zone to whom 648 roaming authority has been delegated, rather than the parent zone, a 649 zone that has delegated roaming responsibility will typically have at 650 least two SIG records, one signed by the superzone, and at least one 651 additional SIG record, signed by the provider(s) to who roaming 652 authority has been delegated. 654 The SIG resource record used for roaming will have a type covered of 655 RR. It will also contain a signature expiration date and the time when 656 the record was signed. Since the roaming relationship will be assumed 657 to be in force until the signature expiration, ISPs or roaming consor- 658 tia will typically only sign records for short periods of time. 659 Finally, the SIG resource record will contain the domain to whom roam- 660 ing responsibility has been delegated, and will be signed by that 661 domain. 663 8.2.1. Example 665 BIGCO delegates roaming authority to ISPA. As a result, ISPA provides 666 the following SIG resource record in the bigco.com zone: 668 bigco.com. SIG RR 1 2 (; type-cov=RR, alg=1, labels=2 669 1997040102030405 ; signature expiration 670 1997030112130408 ; time signed 671 31273 ; key footprint 672 ispa.com. ; signer 673 Z2fWBj8L=wevdKjOwJbakr2s4Ns=/Mox32X1rQntZPud1Fws/yIpbj7WBtIBug2w5ZrN 674 2sWgTDnrOZd9=/U94gor9k8XCsV5gOr1+2SuGnU/ ;signature (640 bits) 676 In order to secure the bigco.com zone, there will also be other SIG 677 resource records. Given the size of these records, it is possible that 678 the resource records will exceed the maximum DNS UDP packet size, and 679 a TCP transfer will be required to return all of the associated zone 680 records. 682 9. Acknowledgements 684 Thanks to Glen Zorn of Microsoft, Pat Calhoun of USR, and Michael 685 Robinson of Global One for many useful discussions of this problem 686 space. 688 10. References 690 [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- 691 tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass 692 Alliance, Asiainfo, January, 1997. 694 [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." draft-ietf- 695 roamops-roamreq-02.txt, Microsoft, January, 1997. 697 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 698 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 699 Daydreamer, January, 1997. 701 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 702 1997. 704 [5] R. Fajman. "An Extensible Message Format for Message Disposition 705 Notifications." draft-ietf-receipt-mdn-02.txt, National Institute of 706 Health, November, 1996. 708 [6] M. Elkins. "MIME Security with Pretty Good Privacy (PGP)." RFC 709 2015, The Aerospace Corporation, October, 1996. 711 [7] G. Vaudreuil. "The Multipart/Report Content Type for the Reporting 712 of Mail System Administrative Messages." RFC 1892, Octel Network Ser- 713 vices, January, 1996. 715 [8] J. Galvin., et al. "Security Multiparts for MIME: Multipart/Signed 716 and Multipart/Encrypted." RFC 1847, Trusted Information Systems, Octo- 717 ber, 1995. 719 [9] D. Crocker. "MIME Encapsulation of EDI Objects." RFC 1767, Bran- 720 denburg Consulting, March, 1995. 722 [10] M. Jansson, C. Shih, N. Turaj, R. Drummond. "MIME-based Secure 723 EDI." draft-ietf-ediint-as1-02.txt, LiNK, Actra, Mitre Corp, Drummond 724 Group, November, 1996. 726 [11] C. Shih, M. Jansson, R. Drummond, L. Yarbrough. "Requirements for 727 Inter-operable Internet EDI." draft-ietf-ediint-req-01.txt, Actra, 728 LiNK, Drummond Group, May, 1995. 730 [12] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location 731 of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- 732 prises, October 1996. 734 [13] D. Eastlake, 3rd, C. W. Kaufman. "Domain Name System Security 735 Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August, 736 1996. 738 [14] S. Bradner. "Key words for use in RFCs to Indicate Requirement 739 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 740 1996. 742 [15] C. Malmud, M. Rose. "Principles of Operation for the TPC.INT 743 Subdomain: General Principles and Policy." RFC 1530, Internet Multi- 744 casting Service, Dover Beach Consulting, Inc., October, 1993. 746 11. Authors' Addresses 748 Bernard Aboba 749 Microsoft Corporation 750 One Microsoft Way 751 Redmond, WA 98052 753 Phone: 206-936-6605 754 EMail: bernarda@microsoft.com