idnits 2.17.1 draft-ietf-weirds-bootstrap-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: This method relies on the fact that RDAP clients are fetching the IANA registries to then find the servers locally. Clients SHOULD not fetch every time the registry. Clients SHOULD cache the registry, but use underlying protocol signalling, such as HTTP Expires header field [RFC7234], to identify when it is time to refresh the cached registry. -- The document date (June 23, 2014) is 3595 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) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-14) exists of draft-ietf-weirds-json-response-07 == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-10 == Outdated reference: A later version (-04) exists of draft-ietf-weirds-redirects-03 == Outdated reference: A later version (-15) exists of draft-ietf-weirds-using-http-08 -- 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 (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Standards Track June 23, 2014 5 Expires: December 25, 2014 7 Finding the Authoritative Registration Data (RDAP) Service 8 draft-ietf-weirds-bootstrap-02.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 December 25, 2014. 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 . . . . . . . . . . . . . 3 55 5. Internet Numbers RDAP Bootstrap Registries . . . . . . . . . 4 56 5.1. IPv4 Address Space RDAP Bootstrap Registry . . . . . . . 5 57 5.2. IPv6 Address Space RDAP Registry . . . . . . . . . . . . 5 58 5.3. Autonomous Systems RDAP Bootstrap Registry . . . . . . . 6 59 6. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Non-existent Entries or RDAP URL Values . . . . . . . . . . . 7 61 8. Deployment and Implementation Considerations . . . . . . . . 7 62 9. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 66 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 68 13.2. Non-Normative References . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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-q 75 uery][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 that allocation data for domain 81 names and IP addresses are maintained by IANA, are publicly available 82 and are in a structured format. The mechanism assumes some data 83 structure within these registries and request IANA to create these 84 registries for the specific purpose of RDAP use, herein named RDAP 85 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 implemented as JSON [RFC7159] 99 objects. A registry starts with metadata such as a version id 100 identified as a timestamp of the publication date of the registry and 101 some defaults values. Then follows an array of arrays. Each second 102 level array lists all the entries available by the same template 103 method. There is no assumption of sorting at the first or second 104 level arrays. An example structure of a JSON RDAP Bootstrap Registry 105 is illustrated: 107 "rdap.bootstrap": { 108 "version": "YYYY-MM-DDTHH:MM:SSZ", 109 "proto": [ https http ], 111 "services": [ 112 ["entry1", "entry2", "entry3"]: { 113 "template": "{proto}://registry.example.com/myrdap/{resource}", 114 "proto": [ https ], 115 }, 116 ["entry4"]: { 117 "template": "{proto}://example.org/{resource}", 118 }, 119 ], 120 } 122 The syntax of "version" value conforms to the Internet date/time 123 format [RFC3339]. The "proto" object is an array of transport 124 protocols used to access the resource. The RDAP bootstrap client 125 SHOULD try the transport protocols in the order they are presented in 126 the array. The "proto" object can be overriden in the specific 127 entries. Per [RFC7258], the secure version of the transport protocol 128 SHOULD be first. 130 4. Domain Name RDAP Bootstrap Registry 132 This registry contains domain labels entries attached to the root, 133 grouped by templates, as shown in this example. 135 "rdap.bootstrap": { 136 "version": "YYYY-MM-DDTHH:MM:SSZ", 137 "proto": [ "https", "http" ], 139 "services": [ 140 ["net", "com"]: { 141 "template": "https://registry.example.com/myrdap/{resource}", 142 }, 143 ["org", "mytld"]: { 144 "template": "{proto}://example.org/{resource}", 145 }, 146 ], 147 ["mytld2"]: { 148 "template": "{proto}://example.net/rdapmytld2/{resource}", 149 "proto": [ "http", "https"], 150 }, 151 ], 152 } 154 The domain names authoritative registration data service is found by 155 doing the longest match of the target domain name with the domain 156 values in the arrays in the IANA Domain Name RDAP Bootstrap Registry. 157 This is a string search of the longest match starting from the end of 158 the target name and the end of each value in the arrays. The value 159 of the corresponding "template" object is the base RDAP URL as 160 described in [I-D.ietf-weirds-rdap-query]. 162 For example, a domain RDAP query for a.b.example.com matches the com 163 entry in one of the arrays of the registry. Following the example 164 above, the base RDAP URL for this query is 165 "https://registry.example.com/myrdap/". The {resource} specified in 166 [I-D.ietf-weirds-rdap-query] is then appended to the base URL to 167 complete the query. The complete query is then 168 "https://registry.example.com/myrdap/domain/a.b.example.com". This 169 example is not normative. 171 5. Internet Numbers RDAP Bootstrap Registries 173 This section discusses IPv4 and IPv6 address space and autonomous 174 system numbers. 176 For IP address space, the authoritative registration data service is 177 found by doing a longest match of the target address with the values 178 of the arrays in the corresponding Address Space RDAP Bootstrap 179 registry. The longest match is done the same way as for routing: the 180 addresses are converted in binary form and then the binary strings 181 are compared to find the longest match. The value of the template 182 object is the base RDAP url as described in 184 [I-D.ietf-weirds-rdap-query]. The longest match method enables 185 covering prefixes of a larger address space pointing to one RDAP 186 template while more specific prefixes within the covering prefix 187 being served by another RDAP template. 189 5.1. IPv4 Address Space RDAP Bootstrap Registry 191 This registry contains IPv4 prefix entries, specified in CIDR format 192 and grouped by templates, as shown in this example. 194 "rdap.bootstrap": { 195 "version": "YYYY-MM-DDTHH:MM:SSZ", 196 "proto": [ "https", "http" ], 198 "services": [ 199 ["1.0.0.0/8", "192.0.0.0/8"]: { 200 "template": "https://rir1.example.com/myrdap/{resource}", 201 }, 202 ["28.2.0.0/16", "192.0.2.0/24"]: { 203 "template": "{proto}://example.org/{resource}", 204 }, 205 ], 206 ["28.3.0.0/16"]: { 207 "template": "{proto}://example.net/rdaprir2/{resource}", 208 "proto": [ "http", "https"], 209 }, 210 ], 211 } 213 For example, a query for "192.0.2.0/24" matches the "192.0.0.0/8" 214 entry and the "192.0.2.0/24" entry in the example registry above. 215 The latter is chosen by the client given the longest match. The base 216 RDAP URL for this query is then taken from the template object and 217 expands to "{proto}://example.org/". The {resource} specified in 218 [I-D.ietf-weirds-rdap-query] is then appended to the base URL to 219 complete the query. The complete query is then "https://example.org/ 220 ip/192.0.2.0/24". This example is not normative. 222 5.2. IPv6 Address Space RDAP Registry 224 This registry contains IPv6 prefix entries, using [RFC4291] text 225 representation of address prefixes format, grouped by templates, as 226 shown in this example. 228 "rdap.bootstrap": { 229 "version": "YYYY-MM-DDTHH:MM:SSZ", 230 "proto": [ "https", "http" ], 232 "services": [ 233 ["2001:0200::/23", "2001:db8::/32"]: { 234 "template": "https://rir2.example.com/myrdap/{resource}", 235 }, 236 ["2600::/16", "2100:ffff::/32"]: { 237 "template": "{proto}://example.org/{resource}", 238 }, 239 ], 240 ["2001:0200:1000::/28"]: { 241 "template": "{proto}://example.net/rdaprir2/{resource}", 242 "proto": [ "http", "https"], 243 }, 244 ], 245 } 247 For example, a query for "2001:0200:1000::/48" matches the 248 "2001:0200::/23" entry and the "2001:0200:1000::/28" entry in the 249 example registry above. The latter is chosen by the client given the 250 longest match. The base RDAP URL for this query is then taken from 251 the template object "{proto}://example.net/rdaprir2/". The 252 {resource} specified in [I-D.ietf-weirds-rdap-query] is then appended 253 to the base URL to complete the query. The complete query is 254 therefore "https://example.net/rdaprir2/ip/2001:0200:1000::/48". 255 This example is not normative. 257 5.3. Autonomous Systems RDAP Bootstrap Registry 259 This registry contains Autonomous Systems Number Ranges entries, 260 grouped by templates, as shown in this example. Entries in the 261 arrays are either single AS numbers or ranges of AS numbers where the 262 lower appears first, then the "-" separator and then the upper 263 number. Both 16bit and 32 bit AS numbers are specified in decimal. 265 "rdap.bootstrap": { 266 "version": "YYYY-MM-DDTHH:MM:SSZ", 267 "proto": [ "https", "http" ], 269 "services": [ 270 ["2045", "20116-20117"]: { 271 "template": "https://rir2.example.com/myrdap/{resource}", 272 }, 273 ["10000-12000", "65900-66000"]: { 274 "template": "{proto}://example.org/{resource}", 275 }, 276 ], 277 ["65512-65534"]: { 278 "template": "{proto}://example.net/rdaprir2/{resource}", 279 "proto": [ "http", "https"], 280 }, 281 ], 282 } 284 For example, a query for AS 65411 matches the "64512-65534" entry in 285 the example registry above. The base RDAP URL for this query is then 286 taken from the template object "{proto}://example.net/rdaprir2/". 287 The {resource} specified in [I-D.ietf-weirds-rdap-query] is then 288 appended to the base URL to complete the query. The complete query 289 is therefore "https://example.net/rdaprir2/autnum/65411". This 290 example is not normative. 292 6. Entity 294 Since there is no global namespace for entities, this document does 295 not describe how to find the authoritative RDAP server for entities. 296 It is possible however that, if the entity identifier was received 297 from a previous query, the same RDAP server could be queried for that 298 entity or the entity identifier itself is a fully referenced URL that 299 can be queried. 301 7. Non-existent Entries or RDAP URL Values 303 The registries may not contain the requested value or the RDAP URL 304 value may be empty. In these cases, there is no known RDAP server 305 for that requested value and the client SHOULD provide an appropriate 306 error message to the user. 308 8. Deployment and Implementation Considerations 310 This method relies on the fact that RDAP clients are fetching the 311 IANA registries to then find the servers locally. Clients SHOULD not 312 fetch every time the registry. Clients SHOULD cache the registry, 313 but use underlying protocol signalling, such as HTTP Expires header 314 field [RFC7234], to identify when it is time to refresh the cached 315 registry. 317 If the query data does not match any entry in the client cached 318 registry, then the client may implement various methods, such as the 319 following: 321 o In the case of a domain object to be RDAP queried, the client may 322 first query the DNS to see if the respective entry has been 323 delegated or if it is a mistyped information by the user. The DNS 324 query could be to fetch the NS records for the TLD domain. If the 325 DNS answer is negative, then there is no need to fetch the new 326 version of the registry. However, if the DNS answer is positive, 327 this may mean that the currently cached registry is no more 328 current. The client could then fetch the registry, parse and then 329 do the normal matching as specified above. This method may not 330 work for all types of RDAP objects. 332 o If the client knows the existence of a RDAP aggregator or 333 redirector and trust that service, then it could send the query to 334 the redirector, which would redirect the client if it knows the 335 authoritative server that client has not found. 337 IANA should make sure that the service of those registries is able to 338 cope with a larger demand and should take appropriate measures such 339 as caching and load balancing. 341 This specification does not assume while not prohibiting how some 342 authorities of registration data may work together on sharing their 343 information for a common service, including mutual 344 redirection[I-D.ietf-weirds-redirects]. 346 9. Limitations 348 This method does not provide a direct way to find authoritative RDAP 349 servers: 351 o for entities 353 o for queries using search patterns that do not contain a 354 terminating string that matches some entries in the registries 356 10. Security Considerations 358 By providing a bootstrap method to find RDAP servers, this document 359 helps making sure that the end-users will get the RDAP data from 360 authoritative source, instead of from rogue sources. The method 361 itself has the same security properties as the RDAP protocols 362 themselves. The transport used to access the registries could be 363 more secure by using TLS [RFC5246] if IANA supports it. 365 11. IANA Considerations 367 IANA is requested to do the following: 369 o Create a new registry "IPv4 Address Space RDAP Bootstrap Service" 370 in the JSON format, as shown above. 372 o Create a new registry "IPv6 Address Space RDAP Bootstrap Service" 373 in the JSON format, as shown above. 375 o Create a new registry "Autonomous System Number Space RDAP 376 Bootstrap Service" in the JSON format, as shown above. 378 o Create a new registry "Domain Name Space RDAP Bootstrap Service" 379 in the JSON format, as shown above. 381 It is envisionned that these new registries will have similar entries 382 than the corresponding IANA allocation registries, such as 383 [ipv4reg],[ipv6reg],[asreg], [domainreg], and possibly similar 384 registration policies. However, the registration policies for the 385 new registries of this document are left to IANA. 387 The registries may be maintained in IANA own format, such as XML. 388 However, the registry should be available in the JSON format, and 389 optionally in other formats such as XML. 391 12. Acknowledgements 393 The weirds working group had multiple discussions on this topic, 394 including a session during IETF 84, where various methods such as in- 395 DNS and others were debated. The idea of using IANA registries was 396 discovered by the editor during discussions with his colleagues as 397 well as by a comment from Andy Newton. All the people involved in 398 these discussions are herein acknowledged. Linlin Zhou, Jean- 399 Philippe Dionne, John Levine, Kim Davies, Ernie Dainow, Scott 400 Hollenbeck, Arturo Servin, Andy Newton, Murray Kucherawy have 401 provided input and suggestions to this document. 403 13. References 404 13.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 410 Internet: Timestamps", RFC 3339, July 2002. 412 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 413 Architecture", RFC 4291, February 2006. 415 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 416 Interchange Format", RFC 7159, March 2014. 418 13.2. Non-Normative References 420 [I-D.ietf-weirds-json-response] 421 Newton, A. and S. Hollenbeck, "JSON Responses for the 422 Registration Data Access Protocol (RDAP)", draft-ietf- 423 weirds-json-response-07 (work in progress), April 2014. 425 [I-D.ietf-weirds-rdap-query] 426 Newton, A. and S. Hollenbeck, "Registration Data Access 427 Protocol Query Format", draft-ietf-weirds-rdap-query-10 428 (work in progress), February 2014. 430 [I-D.ietf-weirds-redirects] 431 Martinez, C., Zhou, L., and G. Rada, "Redirection Service 432 for Registration Data Access Protocol", draft-ietf-weirds- 433 redirects-03 (work in progress), February 2014. 435 [I-D.ietf-weirds-using-http] 436 Newton, A., Ellacott, B., and N. Kong, "HTTP usage in the 437 Registration Data Access Protocol (RDAP)", draft-ietf- 438 weirds-using-http-08 (work in progress), February 2014. 440 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 441 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 443 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 444 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 445 2014. 447 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 448 Attack", BCP 188, RFC 7258, May 2014. 450 [asreg] Internet Assigned Numbers Authority(IANA), , "Autonomous 451 System (AS) Numbers", . 454 [domainreg] 455 Internet Assigned Numbers Authority(IANA), , "Root Zone 456 Database", . 458 [ipv4reg] Internet Assigned Numbers Authority(IANA), , "IPv4 Address 459 Space", . 462 [ipv6reg] Internet Assigned Numbers Authority(IANA), , "IPv6 Global 463 Unicast Address Assignments", 464 . 467 [ipv6regparent] 468 Internet Assigned Numbers Authority(IANA), , "Internet 469 Protocol Version 6 Address Space", 470 . 473 Author's Address 475 Marc Blanchet 476 Viagenie 477 246 Aberdeen 478 Quebec, QC G1R 2E1 479 Canada 481 Email: Marc.Blanchet@viagenie.ca 482 URI: http://www.viagenie.ca