idnits 2.17.1 draft-ietf-weirds-bootstrap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 4, 2014) is 3515 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) -- Looks like a reference, but probably isn't: '2045' on line 347 -- Looks like a reference, but probably isn't: '64512' on line 369 -- Looks like a reference, but probably isn't: '65534' on line 369 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-14) exists of draft-ietf-weirds-json-response-08 == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-13 == Outdated reference: A later version (-15) exists of draft-ietf-weirds-using-http-10 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft G. Leclanche 4 Intended status: Standards Track Viagenie 5 Expires: March 8, 2015 September 4, 2014 7 Finding the Authoritative Registration Data (RDAP) Service 8 draft-ietf-weirds-bootstrap-06.txt 10 Abstract 12 This document specifies a method to find which Registration Data 13 Access Protocol (RDAP) server is authoritative to answer queries for 14 a requested scope, such as domain names, IP addresses or Autonomous 15 System numbers. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 8, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used In This Document . . . . . . . . . . . . . . 2 53 3. Structure of RDAP Bootstrap Registries . . . . . . . . . . . 3 54 4. Domain Name RDAP Bootstrap Registry . . . . . . . . . . . . . 4 55 5. Internet Numbers RDAP Bootstrap Registries . . . . . . . . . 6 56 5.1. IPv4 Address Space RDAP Bootstrap Registry . . . . . . . 6 57 5.2. IPv6 Address Space RDAP Registry . . . . . . . . . . . . 7 58 5.3. Autonomous Systems RDAP Bootstrap Registry . . . . . . . 8 59 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 10 61 8. Deployment and Implementation Considerations . . . . . . . . 10 62 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 68 13.2. Non-Normative References . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Introduction 73 Querying and retrieving registration data from registries are defined 74 in the Registration Data Access Protocol(RDAP) [I-D.ietf-weirds-rdap- 75 query][I-D.ietf-weirds-using-http][I-D.ietf-weirds-json-response]. 76 These documents do not specify where to send the queries. This 77 document specifies a method to find which server is authoritative to 78 answer queries for the requested scope. 80 The proposed mechanism is based on the fact that allocation data for 81 domain names and IP addresses are maintained by IANA, are publicly 82 available and are in a structured format. The mechanism assumes some 83 data structure within these registries and request IANA to create 84 these registries for the specific purpose of RDAP use, herein named 85 RDAP Bootstrap registries. An RDAP client fetches the RDAP Bootstrap 86 registries, extract the data and then do a match with the query data 87 to find the authoritative registration data server and appropriate 88 query base URL. 90 2. Conventions Used In This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Structure of RDAP Bootstrap Registries 98 The RDAP Bootstrap Registries are made available as JSON [RFC7159] 99 objects. The JSON registry output starts with metadata such as a 100 version id identified as a timestamp of the publication date of the 101 registry and some defaults values. Then the "services" element is an 102 array of arrays. Each second level array contains two elements, each 103 of them being an array (third-level arrays). The first third-level 104 array contains all entries that have the same set of base RDAP URLs, 105 as strings, arrays, or integers. The second third-level array 106 contains the list of base RDAP URLs usable for the entries found in 107 the first third-level array. There is no assumption of sorting at 108 the first-level arrays. The two arrays found in each second-level 109 array MUST appear in the correct order: array of entries first, then 110 array of base RDAP URLs. An example structure of the JSON output of 111 a RDAP Bootstrap Registry is illustrated: 113 { 114 "rdap_bootstrap": { 115 "version": "1.0", 116 "publication": "YYYY-MM-DDTHH:MM:SSZ", 117 "description": "RDAP Bootstrap file for example registries.", 119 "services": [ 120 [ 121 ["entry1", "entry2", "entry3"], 122 [ 123 "https://registry.example.com/myrdap/", 124 "http://registry.example.com/myrdap/" 125 ] 126 ], 127 [ 128 ["entry4"], 129 [ 130 "http://example.org/" 131 ] 132 ] 133 ] 134 } 135 } 137 The "version" corresponds to the format version of the registry. 138 This specification defines "1.0". 140 The syntax of "publication" value conforms to the Internet date/time 141 format [RFC3339]. 143 The optional "description" string can contain a comment regarding the 144 content of the bootstrap object. 146 Per [RFC7258], in each array of base RDAP URLs, the secure version of 147 the transport protocol SHOULD be first. Base RDAP URLs MUST have a 148 trailing "/" character because they are concatenated to the various 149 segments defined in [I-D.ietf-weirds-rdap-query]. 151 JSON names MUST follow format recommendations of 152 [I-D.ietf-weirds-using-http]. Any unknown or unspecified JSON object 153 properties or values should be ignored by implementers. 155 Internationalized Domain Names labels used as keys or base RDAP URLs 156 in the registries defined in this document MUST be only represented 157 using their A-Label form as defined in [RFC5890]. 159 All Domain Names labels used as keys or base RDAP URLs in the 160 registries defined in this document MUST be only represented in 161 lowercase. 163 4. Domain Name RDAP Bootstrap Registry 165 The JSON output of this registry contains domain labels entries 166 attached to the root, grouped by base RDAP URLs, as shown in this 167 example. 169 { 170 "rdap_bootstrap": { 171 "version": "1.0", 172 "publication": "YYYY-MM-DDTHH:MM:SSZ", 174 "services": [ 175 [ 176 ["net", "com"], 177 [ 178 "https://registry.example.com/myrdap/" 179 ] 180 ], 181 [ 182 ["org", "mytld"], 183 [ 184 "http://example.org/" 185 ] 186 ], 187 [ 188 ["xn--zckzah"], 189 [ 190 "https://example.net/rdapxn--zckzah/", 191 "http://example.net/rdapxn--zckzah/" 192 ] 193 ] 194 ] 195 } 196 } 198 The domain names authoritative registration data service is found by 199 doing the longest match of the target domain name with the domain 200 values in the arrays in the IANA Domain Name RDAP Bootstrap Registry. 201 This is a string search of the longest match starting from the end of 202 the target name and the end of each value in the arrays. The values 203 contained in the second element of the array are the valid base RDAP 204 URLs as described in [I-D.ietf-weirds-rdap-query]. 206 For example, a domain RDAP query for a.b.example.com matches the com 207 entry in one of the arrays of the registry. The base RDAP URL for 208 this query is then taken from the second element of the array, which 209 is an array of base RDAP URLs valid for this entry. The client 210 chooses one of the base URLs from this array; in this example it 211 chooses the only one available, "https://registry.example.com/ 212 myrdap/". The segment specified in [I-D.ietf-weirds-rdap-query] is 213 then appended to the base URL to complete the query. The complete 214 query is then "https://registry.example.com/myrdap/domain/ 215 a.b.example.com". This example is not normative. 217 5. Internet Numbers RDAP Bootstrap Registries 219 This section discusses IPv4 and IPv6 address space and autonomous 220 system numbers. 222 For IP address space, the authoritative registration data service is 223 found by doing a longest match of the target address with the values 224 of the arrays in the corresponding Address Space RDAP Bootstrap 225 registry. The longest match is done the same way as for routing: the 226 addresses are converted in binary form and then the binary strings 227 are compared to find the longest match. The values contained in the 228 second element of the array are the base RDAP URLs as described in 229 [I-D.ietf-weirds-rdap-query]. The longest match method enables 230 covering prefixes of a larger address space pointing to one base RDAP 231 URL while more specific prefixes within the covering prefix being 232 served by another base RDAP URL. 234 5.1. IPv4 Address Space RDAP Bootstrap Registry 236 The JSON output of this registry contains IPv4 prefix entries, 237 specified in CIDR format and grouped by RDAP URLs, as shown in this 238 example. 240 { 241 "rdap_bootstrap": { 242 "version": "1.0", 243 "publication": "YYYY-MM-DDTHH:MM:SSZ", 245 "services": [ 246 [ 247 ["1.0.0.0/8", "192.0.0.0/8"], 248 [ 249 "https://rir1.example.com/myrdap/" 250 ] 251 ], 252 [ 253 ["28.2.0.0/16", "192.0.2.0/24"], 254 [ 255 "http://example.org/" 256 ] 257 ], 258 [ 259 ["28.3.0.0/16"], 260 [ 261 "https://example.net/rdaprir2/", 262 "http://example.net/rdaprir2/" 263 ] 264 ] 265 ] 266 } 267 } 269 For example, a query for "192.0.2.0/24" matches the "192.0.0.0/8" 270 entry and the "192.0.2.0/24" entry in the example registry above. 271 The latter is chosen by the client given the longest match. The base 272 RDAP URL for this query is then taken from the second element of the 273 array, which is an array of base RDAP URLs valid for this entry. The 274 client chooses one of the base URLs from this array; in this example 275 it chooses the only one available, "http://example.org/". The 276 {resource} specified in [I-D.ietf-weirds-rdap-query] is then appended 277 to the base URL to complete the query. The complete query is then 278 "https://example.org/ip/192.0.2.0/24". This example is not 279 normative. 281 5.2. IPv6 Address Space RDAP Registry 283 The JSON output of this registry contains IPv6 prefix entries, using 284 [RFC4291] text representation of address prefixes format, grouped by 285 base RDAP URLs, as shown in this example. 287 { 288 "rdap_bootstrap": { 289 "version": "1.0", 290 "publication": "YYYY-MM-DDTHH:MM:SSZ", 292 "services": [ 293 [ 294 ["2001:0200::/23", "2001:db8::/32"], 295 [ 296 "https://rir2.example.com/myrdap/" 297 ] 298 ], 299 [ 300 ["2600::/16", "2100:ffff::/32"], 301 [ 302 "http://example.org/" 303 ] 304 ], 305 [ 306 ["2001:0200:1000::/28"], 307 [ 308 "https://example.net/rdaprir2/", 309 "http://example.net/rdaprir2/" 310 ] 311 ] 312 ] 313 } 314 } 316 For example, a query for "2001:0200:1000::/48" matches the 317 "2001:0200::/23" entry and the "2001:0200:1000::/28" entry in the 318 example registry above. The latter is chosen by the client given the 319 longest match. The base RDAP URL for this query is then taken from 320 the second element of the array, which is an array of base RDAP URLs 321 valid for this entry. The client chooses one of the base URLs from 322 this array; in this example it chooses "https://example.net/ 323 rdaprir2/" because it's the secure version of the protocol. The 324 segment specified in [I-D.ietf-weirds-rdap-query] is then appended to 325 the base URL to complete the query. The complete query is therefore 326 "https://example.net/rdaprir2/ip/2001:0200:1000::/48". If the server 327 does not answer, the client can then use another URL prefix from the 328 array. This example is not normative. 330 5.3. Autonomous Systems RDAP Bootstrap Registry 332 The JSON output of this contains Autonomous Systems Number Ranges 333 entries, grouped by base RDAP URLs, as shown in this example. The 334 first element of each second-level array is an array containing the 335 list of AS numbers served by the base RDAP URLs found in the second 336 element. When an element of the AS Numbers array is an array with 337 two AS numbers, then it represents the range of AS Numbers between 338 the two elements of this array. 340 { 341 "rdap_bootstrap": { 342 "version": "1.0", 343 "publication": "YYYY-MM-DDTHH:MM:SSZ", 345 "services": [ 346 [ 347 [2045], 348 [ 349 "https://rir3.example.com/myrdap/" 350 ] 351 ], 352 [ 353 [[10000, 12000], [300000, 400000]], 354 [ 355 "http://example.org/" 356 ] 357 ], 358 [ 359 [[64512, 65534]], 360 [ 361 "http://example.net/rdaprir2/", 362 "https://example.net/rdaprir2/" 363 ] 364 ] 365 ] 366 } 367 } 369 For example, a query for AS 65411 matches the [64512, 65534] entry in 370 the example registry above. The base RDAP URL for this query is then 371 taken from the second element of the array, which is an array of base 372 RDAP URLs valid for this entry. The client chooses one of the base 373 URLs from this array; in this example it chooses 374 "https://example.net/rdaprir2/". The segment specified in 375 [I-D.ietf-weirds-rdap-query] is then appended to the base URL to 376 complete the query. The complete query is therefore 377 "https://example.net/rdaprir2/autnum/65411". If the server does not 378 answer, the client can then use another URL prefix from the array. 379 This example is not normative. 381 6. Entity 383 Since there is no global namespace for entities, this document does 384 not describe how to find the authoritative RDAP server for entities. 385 It is possible however that, if the entity identifier was received 386 from a previous query, the same RDAP server could be queried for that 387 entity or the entity identifier itself is a fully referenced URL that 388 can be queried. 390 7. Non-existent Entries or RDAP URL Values 392 The registries may not contain the requested value or the base RDAP 393 URL value may be empty. In these cases, there is no known RDAP 394 server for that requested value and the client SHOULD provide an 395 appropriate error message to the user. 397 8. Deployment and Implementation Considerations 399 This method relies on the fact that RDAP clients are fetching the 400 IANA registries to then find the servers locally. Clients SHOULD NOT 401 fetch the registry every time. Clients SHOULD cache the registry, 402 but use underlying protocol signalling, such as HTTP Expires header 403 field [RFC7234], to identify when it is time to refresh the cached 404 registry. 406 If the query data does not match any entry in the client cached 407 registry, then the client may implement various methods, such as the 408 following: 410 o In the case of a domain object to be RDAP queried, the client may 411 first query the DNS to see if the respective entry has been 412 delegated or if it is a mistyped information by the user. The DNS 413 query could be to fetch the NS records for the TLD domain. If the 414 DNS answer is negative, then there is no need to fetch the new 415 version of the registry. However, if the DNS answer is positive, 416 this may mean that the currently cached registry is no more 417 current. The client could then fetch the registry, parse and then 418 do the normal matching as specified above. This method may not 419 work for all types of RDAP objects. 421 o If the client knows the existence of a RDAP aggregator or 422 redirector and trusts that service, then it could send the query 423 to the redirector, which would redirect the client if it knows the 424 authoritative server that client has not found. 426 This specification does not assume while not prohibiting how some 427 authorities of registration data may work together on sharing their 428 information for a common service, including mutual redirection 429 [I-D.ietf-weirds-redirects]. 431 When a new object is allocated, such as a new AS range, a new TLD or 432 a new IP address range, there is no garantee that this new object 433 will have an entry in the corresponding bootstrap rdap registry, 434 since the setup of the RDAP server for this new entry may become live 435 and registered later. Therefore, the clients should expect that even 436 if an object, such as TLD, IP address range or AS range is allocated, 437 the existence of the entry in the corresponding bootstrap registry is 438 not garanteed. 440 9. Limitations 442 This method does not provide a direct way to find authoritative RDAP 443 servers for any other objects than the ones described in this 444 document. In particular, the following objects are not bootstrapped 445 with the method described in this document: 447 o for entities 449 o for queries using search patterns that do not contain a 450 terminating string that matches some entries in the registries 452 o for nameservers 454 o for help 456 10. Security Considerations 458 By providing a bootstrap method to find RDAP servers, this document 459 helps making sure that the end-users will get the RDAP data from 460 authoritative source, instead of from rogue sources. The method 461 itself has the same security properties as the RDAP protocols 462 themselves. The transport used to access the registries could be 463 more secure by using TLS [RFC5246] if IANA supports it. 465 11. IANA Considerations 467 IANA is requested to do the following: 469 o Create a new registry "IPv4 Address Space RDAP Bootstrap Service" 470 and make it available in the JSON format, as shown above. 472 o Create a new registry "IPv6 Address Space RDAP Bootstrap Service" 473 and make it available in the JSON format, as shown above. 475 o Create a new registry "Autonomous System Number Space RDAP 476 Bootstrap Service" and make it available in the JSON format, as 477 shown above. 479 o Create a new registry "Domain Name Space RDAP Bootstrap Service" 480 and make it available in the JSON format, as shown above. 482 It is envisioned that these new registries will have similar entries 483 than the corresponding IANA allocation registries, such as [ipv4reg], 484 [ipv6reg], [asreg], [domainreg], and possibly similar registration 485 policies. Given that the data required by RDAP clients is limited 486 compared to the content of the existing corresponding registries, and 487 given that this data has to be made available in a JSON format using 488 a specific key/value structure, this document is not defining an 489 extension of the existing IANA allocation registries. The 490 registration policies for the new registries of this document are 491 left to IANA. 493 The registries may be maintained in IANA own format, such as XML. 494 However, each registry MUST be available in the JSON format defined 495 in this document, and optionally in other formats such as XML. 497 IANA should make sure that the service of those registries is able to 498 cope with a larger demand and should take appropriate measures such 499 as caching, load balancing and redundancy. 501 The base URL of these registries is not defined in this document and 502 is left to IANA. 504 The HTTP Content-Type returned to clients accessing the JSON output 505 of the registries MUST be "application/json" as defined in [RFC7159]. 507 12. Acknowledgements 509 The weirds working group had multiple discussions on this topic, 510 including a session during IETF 84, where various methods such as in- 511 DNS and others were debated. The idea of using IANA registries was 512 discovered by the editor during discussions with his colleagues as 513 well as by a comment from Andy Newton. All the people involved in 514 these discussions are herein acknowledged. Linlin Zhou, Jean- 515 Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott 516 Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy, Tom 517 Harrison, Naoki Kambe have provided input and suggestions to this 518 document. 520 13. References 522 13.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 528 Internet: Timestamps", RFC 3339, July 2002. 530 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 531 Architecture", RFC 4291, February 2006. 533 [RFC5890] Klensin, J., "Internationalized Domain Names for 534 Applications (IDNA): Definitions and Document Framework", 535 RFC 5890, August 2010. 537 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 538 Interchange Format", RFC 7159, March 2014. 540 13.2. Non-Normative References 542 [I-D.ietf-weirds-json-response] 543 Newton, A. and S. Hollenbeck, "JSON Responses for the 544 Registration Data Access Protocol (RDAP)", draft-ietf- 545 weirds-json-response-08 (work in progress), August 2014. 547 [I-D.ietf-weirds-rdap-query] 548 Newton, A. and S. Hollenbeck, "Registration Data Access 549 Protocol Query Format", draft-ietf-weirds-rdap-query-13 550 (work in progress), August 2014. 552 [I-D.ietf-weirds-redirects] 553 Martinez, C., Zhou, L., and G. Rada, "Redirection Service 554 for Registration Data Access Protocol", draft-ietf-weirds- 555 redirects-04 (work in progress), July 2014. 557 [I-D.ietf-weirds-using-http] 558 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 559 Registration Data Access Protocol (RDAP)", draft-ietf- 560 weirds-using-http-10 (work in progress), August 2014. 562 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 563 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 565 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 566 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 567 2014. 569 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 570 Attack", BCP 188, RFC 7258, May 2014. 572 [asreg] Internet Assigned Numbers Authority(IANA), , "Autonomous 573 System (AS) Numbers", . 576 [domainreg] 577 Internet Assigned Numbers Authority(IANA), , "Root Zone 578 Database", . 580 [ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address 581 Space", . 584 [ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global 585 Unicast Address Assignments", 586 . 589 Authors' Addresses 591 Marc Blanchet 592 Viagenie 593 246 Aberdeen 594 Quebec, QC G1R 2E1 595 Canada 597 Email: Marc.Blanchet@viagenie.ca 598 URI: http://viagenie.ca 600 Guillaume Leclanche 601 Viagenie 602 246 Aberdeen 603 Quebec, QC G1R 2E1 604 Canada 606 Email: Guillaume.Leclanche@viagenie.ca 607 URI: http://viagenie.ca