idnits 2.17.1 draft-mcd-identifier-access-authority-00.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 (December 25, 2019) is 1578 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4291' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC5890' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC7071' is defined on line 391, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-08) exists of draft-ma-identifier-access-http-00 == Outdated reference: A later version (-08) exists of draft-mcd-identifier-access-security-00 == Outdated reference: A later version (-08) exists of draft-mcd-identifier-access-query-00 == Outdated reference: A later version (-08) exists of draft-mcd-identifier-access-responce-00 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Ma 2 Internet Draft J. Chen 3 Intended status: Experimental X. Fan 4 Expires: June 25, 2020 M. Chen 5 Z. Li 6 China Academy of Information and Communications Technology 7 December 25, 2019 9 Finding the Authoritative Registration Data (IIIDAP) Service 10 draft-mcd-identifier-access-authority-00 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on June 25, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 This document specifies a method to find which Industrial Internet 53 Identifier Data Access Protocol (IIIDAP) server is authoritative to 54 answer queries for a request of identifier data. 56 Table of Contents 58 1. Introduction ................................................ 2 59 2. Conventions used in this document............................ 3 60 2.1. Acronyms and Abbreviations.............................. 3 61 3. Structure of the IIIDAP Bootstrap Service Registry........... 3 62 4. Entity ...................................................... 5 63 5. Non-existent Entries or IIIDAP URL Values.................... 5 64 6. Deployment and Implementation Considerations................. 6 65 7. Limitations ................................................. 6 66 8. Formal Definition ........................................... 6 67 8.1. Imported JSON Terms..................................... 7 68 8.2. Registry Syntax......................................... 7 69 9. Security Considerations...................................... 8 70 10. IANA Considerations......................................... 8 71 11. References ................................................. 8 72 11.1. Normative References................................... 8 73 11.2. Informative References................................. 9 75 1. Introduction 77 Querying and retrieving identifier data from registry are defined in 78 Industrial Internet Identifier Data Access Protocol (IIIDAP) 79 [IDENTIFIER-HTTP] [IDENTIFIER-QUERY] [IDENTIFIER-RESPONSES]. These 80 documents do not specify where to send the queries. This document 81 specifies a method to find which server is authoritative to answer 82 queries for a request of identifier data. 84 Identifier data of Enterprise-Level Nodes (ELN) are delegated by 85 SLN, and identifier data of Second-Level Nodes (SLN) are also stored 86 in SLN. Thus, the bootstrap information needed by IIIDAP clients is 87 best generated from data and processes already maintained by SLN; 89 Per this document, Top-Level Node (TLN) SHOULD create a registry 90 based on a JSON format specified in this document, herein named 91 IIIDAP Bootstrap Service Registry. TLN will create and update IIIDAP 92 Bootstrap Services Registry as the registry is updated. TLN has 93 provided a mechanism for collecting the IIIDAP server information. 94 The IIIDAP Bootstrap Services Registry will start empty and will be 95 gradually populated as registrants of identifiers and address spaces 96 provide IIIDAP server information to TLN. An IIIDAP client fetches 97 the IIIDAP Bootstrap Service Registry, extracts the data, and then 98 performs a match with the query data to find the authoritative 99 identifier data server and appropriate query base URL. 101 Entries in this registry contain at least the following: 103 o an identifier of SLN of ELN. 105 o one or more URLs that provide the IIIDAP service regarding this 106 registration. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2.1. Acronyms and Abbreviations 116 IIIDAP: Industrial Internet Identifier Data Access Protocol 118 TLN: Top-Level Nodes 120 SLN: Second-Level Nodes 122 ELN: Enterprise-Level Nodes 124 3. Structure of the IIIDAP Bootstrap Service Registry 126 The IIIDAP Bootstrap Service Registry, as specified below, have been 127 made available as JSON [RFC7159] objects, which can be retrieved via 128 HTTP from locations specified by TLN. The JSON object for each 129 registry contains a series of members containing metadata about the 130 registry such as a version identifier, a timestamp of the 131 publication date of the registry, and a description. Additionally, a 132 "services" member contains the registry items themselves, as an 133 array. Each item of the array contains a second- level array, with 134 two elements, each of them being a third-level array. 136 Each element of the Services Array is a second-level array with two 137 elements: in order, an Entry Array and a Service URL Array. 139 The Entry Array contains all entries that have the same set of base 140 IIIDAP URLs. The Service URL Array contains the list of base IIIDAP 141 URLs usable for the entries found in the Entry Array. Elements 142 within these two arrays are not sorted in any way. 144 The JSON output of identifier registry, grouped by base IIIDAP URLs, 145 as shown in this example. 147 { 148 "version": "1.0", 149 "publication": "YYYY-MM-DDTHH:MM:SSZ", 150 "description": "Some text", 151 "services": [ 152 [ 153 ["86.100", "86.100.1"], 154 [ 155 "https://registry.example.com/myiiidap/" 156 ] 157 ], 158 [ 159 ["86.101"], 160 [ 161 "http://example.org/" 162 ] 163 ] 164 ] 165 } 167 The "version" corresponds to the format version of the registry. 168 This specification defines version "1.0". 170 The syntax of the "publication" value conforms to the Internet date/ 171 time format [RFC3339]. The value is the latest update date of the 172 registry by IANA. 174 The optional "description" string can contain a comment regarding 175 the content of the bootstrap object. 177 Per [RFC7258], in each array of base IIIDAP URLs, the secure 178 versions of the transport protocol SHOULD be preferred and tried 179 first. For example, if the base IIIDAP URLs array contains both 180 HTTPS and HTTP URLs, the bootstrap client SHOULD try the HTTPS 181 version first. 183 Base IIIDAP URLs MUST have a trailing "/" character because they are 184 concatenated to the various segments defined in [IDENTIFIER-QUERY]. 186 JSON names MUST follow the format recommendations of [IDENTIFIER- 187 HTTP]. Any unrecognized JSON object properties or values MUST be 188 ignored by implementations. 190 All labels used as entries or base IIIDAP URLs in the registry 191 defined in this document MUST be only represented in lowercase. 193 Authoritative identifier data service is found by doing the label- 194 wise longest match of the target identifier with the identifier 195 values in the Entry Arrays in the TLN Bootstrap Service Registry. 196 The match is done per label, from right to left. If the longest 197 match results in multiple entries, then those entries are considered 198 equivalent. The values contained in the Service URL Array of the 199 matching second-level array are the valid base IIIDAP URLs as 200 described in [IDENTIFIER-QUERY]. 202 For example, an identifier IIIDAP query for 86.100.1 matches the 203 86.100 entry in one of the arrays of the registry. The base IIIDAP 204 URL for this query is then taken from the second element of the 205 array, which is an array of base IIIDAP URLs valid for this entry. 206 The client chooses one of the base URLs from this array; in this 207 example, it chooses the only one available, 208 "https://registry.example.com/myiiidap/". The segment specified in 209 [IDENTIFIER-QUERY] is then appended to the base URL to complete the 210 query. The complete query is then 211 "https://registry.example.com/myiiidap/identifier/86.100". 213 If a domain IIIDAP query for 86.100.1 matches both 86.100 and 214 86.100.1 entries in the registry, then the longest match applies and 215 the 86.100.1 entry is used by the client. 217 4. Entity 219 Names of identifier nodes can be queried by handle as described in 220 [IDENTIFIER-QUERY], since there is no global namespace for names, 221 this document does not describe how to find the authoritative IIIDAP 222 server for names. However, it is possible that, if an identifier was 223 received from a previous query, the same IIIDAP server could be 224 queried by its name. 226 5. Non-existent Entries or IIIDAP URL Values 228 The registry may not contain the requested value. In these cases, 229 there is no known IIIDAP server for that requested value, and the 230 client SHOULD provide an appropriate error message to the user. 232 6. Deployment and Implementation Considerations 234 This method relies on the fact that IIIDAP clients are fetching the 235 TLN registry to then find the servers locally. Clients SHOULD NOT 236 fetch the registry on every IIIDAP request. Clients SHOULD cache the 237 registry, but use underlying protocol signaling, such as the HTTP 238 Expires header field [RFC7234], to identify when it is time to 239 refresh the cached registry. It is important for that header field 240 to be properly set to provide timely information as the registry 241 change, while maintaining a reasonable load on the IANA servers. The 242 HTTP Content-Type returned to clients accessing these JSON- 243 formatted registry MUST be "application/json", as defined in 244 [RFC7159]. 246 If the query data does not match any entry in the client cached 247 registry, then the client may implement various methods. For 248 example, if the client knows the existence of an IIIDAP aggregator 249 or redirector and its associated base URL, and trusts that service, 250 then it could send the query to the redirector, which would redirect 251 the client if it knows the authoritative server that client has not 252 found. 254 Some authorities of identifier data may work together on sharing 255 their information for a common service, including mutual redirection 256 [REDIRECT-IIIDAP]. 258 When a new object is allocated, there is no guarantee that this new 259 object will have an entry in the corresponding bootstrap IIIDAP 260 registry, since the setup of the IIIDAP server for this new entry 261 may become live and registered later. 263 7. Limitations 265 In particular, the following objects are not bootstrapped with the 266 method described in this document: 268 o queries using search patterns that do not contain a terminating 269 string that matches the identifiers in the registry 271 o names 273 o help 275 8. Formal Definition 277 This section is the formal definition of the registry. The structure 278 of JSON objects and arrays using a set of primitive elements is 279 defined in [RFC7159]. Those elements are used to describe the JSON 280 structure of the registry. 282 8.1. Imported JSON Terms 284 o OBJECT: a JSON object, defined in Section 4 of [RFC7159] 286 o MEMBER: a member of a JSON object, defined in Section 4 of 287 [RFC7159] 289 o MEMBER-NAME: the name of a MEMBER, defined as a "string" in 290 Section 4 of [RFC7159] 292 o MEMBER-VALUE: the value of a MEMBER, defined as a "value" in 293 Section 4 of [RFC7159] 295 o ARRAY: an array, defined in Section 5 of [RFC7159] 297 o ARRAY-VALUE: an element of an ARRAY, defined in Section 5 of 298 [RFC7159] 300 o STRING: a "string", as defined in Section 7 of [RFC7159] 302 8.2. Registry Syntax 304 Using the above terms for the JSON structures, the syntax of a 305 registry is defined as follows: 307 o iiidap-bootstrap-registry: an OBJECT containing a MEMBER version 308 and a MEMBER publication, an optional MEMBER description, and a 309 MEMBER services-list 311 o version: a MEMBER with MEMBER-NAME "version" and MEMBER-VALUE a 312 STRING 314 o publication: a MEMBER with MEMBER-NAME "publication" and MEMBER- 315 VALUE a STRING 317 o description: a MEMBER with MEMBER-NAME "description" and MEMBER- 318 VALUE a STRING 320 o services-list: a MEMBER with MEMBER-NAME "services" and MEMBER- 321 VALUE a services-array 323 o services-array: an ARRAY, where each ARRAY-VALUE is a service 324 o service: an ARRAY of 2 elements, where the first ARRAY-VALUE is 325 an entry-list and the second ARRAY-VALUE is a service-uri-list 327 o entry-list: an ARRAY, where each ARRAY-VALUE is an entry 329 o entry: a STRING 331 o service-uri-list: an ARRAY, where each ARRAY-VALUE is a service- 332 uri 334 o service-uri: a STRING 336 9. Security Considerations 338 By providing a bootstrap method to find IIIDAP servers, this 339 document helps to ensure that the end users will get the IIIDAP data 340 from an authoritative source, instead of from rogue sources. The 341 method has the same security properties as the IIIDAP protocols 342 themselves. The transport used to access the registry can be more 343 secure by using TLS [RFC5246], which IANA supports. 345 Additional considerations on using IIIDAP are described in 346 [IDENTIFIER-SECURITY]. 348 10. IANA Considerations 350 11. References 352 11.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 358 Timestamps", RFC 3339, July 2002, 359 . 361 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 362 Architecture", RFC 4291, February 2006, 363 . 365 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 366 (CIDR): The Internet Address Assignment and Aggregation 367 Plan", BCP 122, RFC 4632, August 2006, 368 . 370 [RFC5890] Klensin, J., "Internationalized Domain Names for 371 Applications (IDNA): Definitions and Document Framework", 372 RFC 5890, August 2010, 373 . 375 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 376 Interchange Format", RFC 7159, March 2014, 377 . 379 11.2. Informative References 381 [REDIRECT-IIIDAP] 382 Martinez, C., Zhou, L., and G. Rada, "Redirection Service 383 for Industrial Internet Identifier Data Access Protocol", 384 Work in Progress, draft-ietf-weirds-redirects-04, July 385 2014. 387 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 388 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 389 . 391 [RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for 392 Reputation Interchange", RFC 7071, November 2013, 393 . 395 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 396 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 397 RFC 7234, June 2014, 398 . 400 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 401 Attack", BCP 188, RFC 7258, May 2014, 402 . 404 [asreg] IANA, "Autonomous System (AS) Numbers", 405 . 407 [domainreg] 408 IANA, "Root Zone Database", 409 . 411 [ipv4reg] IANA, "IPv4 Address Space Registry", 412 . 414 [ipv6reg] IANA, "IPv6 Global Unicast Address Assignments", 415 . 418 [IDENTIFIER-HTTP] 419 Ma, C., "HTTP Usage in the Industrial Internet Identifier 420 Data Access Protocol (IIIDAP)", Work in Progress, draft- 421 ma-identifier-access-http-00, December 2019. 423 [IDENTIFIER-SECURITY] 424 Ma, C., "Security Services for the Industrial Internet 425 Identifier Data Access Protocol (IIIDAP)", Work in 426 Progress, draft-mcd-identifier-access-security-00, 427 December 2019. 429 [IDENTIFIER-QUERY] 430 Ma, C., "Industrial Internet Identifier Data Access 431 Protocol (IIIDAP) Query Format", Work in Progress, draft- 432 mcd-identifier-access-query-00, December 2019. 434 [IDENTIFIER-RESPONSES] 435 Ma, C., "JSON Responses for the Industrial Internet 436 Identifier Data Access Protocol (IIIDAP)", Work in 437 Progress, draft-mcd-identifier-access-responce-00, 438 December 2019. 440 Authors' Addresses 442 Chendi Ma 443 CAICT 444 No.52 Huayuan North Road, Haidian District 445 Beijing, Beijing, 100191 446 China 448 Phone: +86 177 1090 9864 449 Email: machendi@caict.ac.cn 451 Chen Jian 452 CAICT 453 No.52 Huayuan North Road, Haidian District 454 Beijing, Beijing, 100191 455 China 457 Phone: +86 138 1103 3332 458 Email: chenjian3@caict.ac.cn 460 Xiaotian Fan 461 CAICT 462 No.52 Huayuan North Road, Haidian District 463 Beijing, Beijing, 100191 464 China 466 Phone: +86 134 0108 6945 467 Email: fanxiaotian@caict.ac.cn 469 Meilan Chen 470 CAICT 471 No.52 Huayuan North Road, Haidian District 472 Beijing, Beijing, 100191 473 China 475 Phone: +86 139 1143 7301 476 Email: chenmeilan@caict.ac.cn 477 Zhiping Li 478 CAICT 479 No.52 Huayuan North Road, Haidian District 480 Beijing, Beijing, 100191 481 China 483 Phone: +86 185 1107 1386 484 Email: lizhiping@caict.ac.cn