idnits 2.17.1 draft-ietf-crisp-firs-asn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([FIRS-CORE], [FIRS-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2003) is 7553 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2798' is mentioned on line 217, but not defined == Unused Reference: 'RFC2247' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC2251' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC2252' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC2254' is defined on line 390, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2254 (Obsoleted by RFC 4510, RFC 4515) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-ietf-crisp-firs-asn-03.txt August 2003 4 Expires: March, 2004 5 Category: Experimental 7 Defining and Locating Autonomous System Numbers 8 in the Federated Internet Registry Service 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document defines LDAP schema and searching rules for 39 autonomous system numbers, in support of the Federated Internet 40 Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. 42 Table of Contents 44 1. Introduction...............................................2 45 2. Prerequisites and Terminology..............................2 46 3. Naming Syntax..............................................3 47 4. Object Classes and Attributes..............................3 48 5. Query Processing Rules.....................................6 49 5.1. Query Pre-Processing....................................6 50 5.2. LDAP Matching...........................................7 51 5.3. Example Query...........................................8 52 6. Security Considerations....................................8 53 7. IANA Considerations........................................9 54 8. Normative References.......................................9 55 9. Changes from Previous Versions............................10 56 10. Author's Address..........................................11 57 11. Acknowledgments...........................................11 58 12. Full Copyright Statement..................................11 60 1. Introduction 62 This specification defines the naming syntax, object classes, 63 attributes, matching filters, and query processing rules for 64 storing and locating Autonomous System Numbers (ASNs) in the FIRS 65 service. Refer to [FIRS-ARCH] for information on the FIRS 66 architecture and [FIRS-CORE] for the schema definitions and rules 67 which govern the FIRS service as a whole. 69 The definitions in this specification are intended to be used with 70 FIRS. Their usage outside of FIRS is not prohibited, but any such 71 usage is beyond this specification's scope of authority. 73 2. Prerequisites and Terminology 75 The complete set of specifications in the FIRS collection 76 cumulative define a structured and distributed information service 77 using LDAPv3 for the data-formatting and transport functions. This 78 specification should be read in the context of that set, which 79 currently includes [FIRS-ARCH], [FIRS-CORE], [FIRS-DNS], 80 [FIRS-DNSRR], [FIRS-CONTCT], [FIRS-IPV4] and [FIRS-IPV6]. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 83 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 84 in this document are to be interpreted as described in RFC 2119. 86 3. Naming Syntax 88 The naming syntax for ASN entries in FIRS MUST follow the form of 89 "cn=,cn=inetResources,", where 90 is the Autonomous System Number resource, and 91 where is a sequence of domainComponent relative 92 distinguished names which identifies the scope of authority for 93 the selected directory partition. 95 Entries which use the inetAsNumberSyntax rules use the decimal 96 equivalent of a 16-bit autonomous system number, with the non- 97 affective leading zeroes removed. 99 An augmented BNF for this syntax is as follows: 101 inetAsNumberSyntax = decimal value between "0" and "65535" 102 inclusive, with the non-affective leading zeroes removed 104 The schema definition for inetAsNumberSyntax is as follows: 106 inetAsNumberSyntax 107 ( 1.3.6.1.4.1.7161.1.7.0 108 NAME 'inetAsNumberSyntax' 109 DESC 'An autonomous system number.' ) 111 For example, an entry for ASN "1" in the "dc=arin,dc=net" 112 partition would be "cn=1,cn=inetResources,dc=arin,dc=net", while 113 an entry for AS number "65535" in the same partition would be 114 "cn=65535,cn=inetResources,dc=arin,dc=net". 116 4. Object Classes and Attributes 118 ASN-specific entries in FIRS MUST use the inetAsNumber object 119 class, in addition to the mandatory object classes defined in 120 [FIRS-CORE]. ASN entries MUST be treated as containers capable of 121 holding subordinate entries. 123 If an entry exists as a referral source, the entry MUST be defined 124 with the referral object class, in addition to the other object 125 classes defined above. Referral sources MUST NOT contain 126 subordinate entries. Refer to section 3.5 of [FIRS-CORE] for more 127 information on referral entries in FIRS. 129 The inetAsNumber object class is a structural object class which 130 is subordinate to the inetResources object class. The inetAsNumber 131 object class has no mandatory attributes, although it does have 132 several optional attributes. The inetAsNumber object class also 133 inherits the attributes defined in the inetResources object class, 134 including the "cn" naming attribute. 136 The schema definition for the inetAsNumber object class is as 137 follows: 139 inetAsNumber 140 ( 1.3.6.1.4.1.7161.1.7.1 141 NAME 'inetAsNumber' 142 DESC 'Autonomous system attributes.' 143 SUP inetResources 144 STRUCTURAL 145 MAY ( inetAsnDelegationStatus $ inetAsnDelegationDate $ 146 inetAsnRegistrar $ inetAsnRegistry $ inetAsnContacts $ 147 inetAsnRoutingContacts ) ) 149 The attributes from the inetAsNumber object class are described 150 below: 152 inetAsnContacts 153 ( 1.3.6.1.4.1.7161.1.7.2 154 NAME 'inetAsnContacts' 155 DESC 'Contacts for general administrative issues 156 concerning this ASN.' 157 EQUALITY caseIgnoreMatch 158 SYNTAX 1.3.6.1.4.1.7161.1.4.0 ) 160 inetAsnDelegationDate 161 ( 1.3.6.1.4.1.7161.1.7.3 162 NAME 'inetAsnDelegationDate' 163 DESC 'Date this ASN was delegated.' 164 EQUALITY generalizedTimeMatch 165 ORDERING generalizedTimeOrderingMatch 166 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 167 SINGLE-VALUE ) 169 inetAsnDelegationStatus 170 ( 1.3.6.1.4.1.7161.1.7.4 171 NAME 'inetAsnDelegationStatus' 172 DESC 'Delegation status for this AS number.' 173 EQUALITY numericStringMatch 174 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{2} 175 SINGLE-VALUE ) 176 NOTE: In an effort to facilitate internationalization and 177 programmatic processing, the current status of a delegation 178 is identified by a 16-bit integer. The values and status 179 mapping is as follows: 181 0 Reserved delegation (permanently inactive) 182 1 Assigned and active (normal state) 183 2 Assigned but not yet active (new delegation) 184 3 Assigned but on hold (disputed) 185 4 Assignment revoked (database purge pending) 187 Additional values are reserved for future use, and are to 188 be administered by IANA. 190 Note that there is no status code for "unassigned"; 191 unassigned entries SHOULD NOT exist, and SHOULD NOT be 192 returned as answers. 194 inetAsnRegistrar 195 ( 1.3.6.1.4.1.7161.1.7.5 196 NAME 'inetAsnRegistrar' 197 DESC 'Registrar or sub-registry who delegated this ASN.' 198 EQUALITY caseExactMatch 199 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 201 NOTE: The inetAsnRegistrar attribute uses a URL to indicate 202 the registrar who delegated the ASN. The attribute 203 structure is identical to the labeledURI attribute, as 204 defined in [RFC2798], including the URL and textual 205 comments. The data can refer to any valid URL. 207 inetAsnRegistry 208 ( 1.3.6.1.4.1.7161.1.7.6 209 NAME 'inetAsnRegistry' 210 DESC 'Regional registry where this ASN is managed.' 211 EQUALITY caseExactMatch 212 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 214 NOTE: The inetAsnRegistry attribute uses a URL to indicate 215 the registry who is ultimately responsible for the ASN. The 216 attribute structure is identical to the labeledURI 217 attribute, as defined in [RFC2798], including the URL and 218 textual comments. The data can refer to any valid URL. 220 inetAsnRoutingContacts 221 ( 1.3.6.1.4.1.7161.1.7.7 222 NAME 'inetAsnRoutingContacts' 223 DESC 'Contacts for routing-related problems with this 224 ASN.' 225 EQUALITY caseIgnoreMatch 226 SYNTAX 1.3.6.1.4.1.7161.1.4.0 ) 228 An example of an inetAsNumber entry is shown in Figure 1 below. 229 The example includes attributes from the inetAsNumber, 230 inetResources, and inetAssociatedResources object classes. 232 cn=65535,cn=inetResources,dc=asn,dc=net 233 [top object class] 234 [inetResources object class] 235 [inetAsNumber object class] 236 [inetAssociatedResources object class] 237 | 238 +-attribute: description 239 | value: "Example Hosting's autonomous system" 240 | 241 +-attribute: inetAsnContacts 242 | value: "hostmaster@example.net" 243 | 244 +-attribute: inetAssociatedIpv4Networks 245 value: "192.0.2.0/24" 247 Figure 1: The entry for ASN 65535 in the dc=arin,dc=net partition. 249 5. Query Processing Rules 251 Queries for ASNs have several special requirements, as discussed 252 in the following sections. 254 Refer to [FIRS-CORE] for general information about FIRS queries. 256 5.1. Query Pre-Processing 258 FIRS clients MUST use the targeted bootstrap model by default for 259 ASN queries, using the "asn.arpa" zone as the seed domain for the 260 initial query. 262 FIRS clients MAY use the top-down bootstrap model for queries if 263 necessary or desirable. Due to the lack of any public DNS 264 delegation mapping service, there is no practical reason for FIRS 265 clients to use the bottom-up model with ASN queries. 267 There are no pre-existing mechanisms for mapping ASNs to domain 268 names. As such, there are no pre-existing mechanisms for mapping 269 ASNs to authoritative LDAP partitions. In order to facilitate 270 interoperability, FIRS queries for ASN resources MUST use 271 "dc=asn,dc=arpa" as the authoritative partition, and MUST use 272 "cn=inetResources,dc=asn,dc=arpa" for the search base. It is 273 expected that FIRS-compliant LDAP servers will be established to 274 serve this directory partition, with these servers providing 275 entry-specific referrals to registrar-specific servers. 277 5.2. LDAP Matching 279 If the server advertises the inetAsNumber object class and the 280 inetAsNumberMatch matching filter in the inetResourcesControl 281 server control, FIRS clients MUST use the inetAsNumberMatch 282 matching filter in LDAP searches for contact entries. 284 The inetAsNumberMatch filter provides an identifier and search 285 string format which collectively inform a queried server that a 286 specific ASN value should be searched for, and that any 287 inetAsNumber object class entries which match the assertion value 288 should be returned. 290 The inetAsNumberMatch filter is defined as follows: 292 inetAsNumberMatch 293 ( 1.3.6.1.4.1.7161.1.7.0.1 294 NAME 'inetAsNumberMatch' 295 SYNTAX 1.3.6.1.4.1.7161.1.7.0 ) 297 Clients MUST ensure that the query input is normalized according 298 to the rules specified in section 3 before the input is used as 299 the assertion value to the resulting LDAP query. 301 A FIRS server MUST compare the assertion value against the 302 distinguished name of all entries within and beneath the container 303 specified by the search base of the query. Any entry in that 304 hierarchy with an object class of inetAsNumber and a distinguished 305 name component that is equal to the assertion value MUST be 306 returned to the client (this specifically includes any child 307 entries, such as referral stubs). Entries which do not have an 308 object class of inetAsNumber MUST NOT be returned. 310 The matching filters defined in this specification MUST be 311 supported by FIRS clients and servers. FIRS servers MAY support 312 additional matching filters, although FIRS clients MUST NOT expect 313 any additional filters to be available. 315 If the server does not advertise support for the inetAsNumberMatch 316 matching filter in the inetResourcesControl server control, the 317 client MAY choose to emulate the matching filter through the use 318 of locally-constructed equalityMatch filters. However, this 319 process can result in incomplete answers in some cases, so if the 320 server advertises support for the inetAsNumberMatch matching 321 filter in the inetResourcesControl control, the client MUST use 322 it. 324 5.3. Example Query 326 The following example assumes that the user has specified "65535" 327 as the query value: 329 a. Normalize the input, which is "65535" in this case. 331 b. Determine the authoritative partition, which is always " 332 dc=asn,dc=arpa" in the case of ASNs. 334 c. Determine the search base for the query, which is always 335 "cn=inetResources,dc=asn,dc=arpa" in the case of ASNs. 337 d. Initiate a DNS lookup for the SRV resource records 338 associated with "_ldap._tcp.asn.arpa." For the purpose of 339 this example, assume that this lookup succeeds, with the 340 DNS response message indicating that "firs.iana.org" is the 341 preferred LDAP server. 343 e. Submit an LDAPv3 query to the specified server, using 344 "(1.3.6.1.4.1.7161.1.7.0.1:=65535)" as the matching filter, 345 "cn=inetResources,dc=asn,dc=arpa" as the search base, and 346 the global query defaults defined in [FIRS-CORE]. 348 f. Assume that no referrals are received. Display the answer 349 data which has been received and exit the query. 351 6. Security Considerations 353 Security considerations are discussed in [FIRS-ARCH]. 355 7. IANA Considerations 357 ASNs are not currently represented in the global DNS, and there 358 are no simple mechanisms for mapping ASNs to authoritative 359 partitions using the public DNS. This specification uses the 360 "asn.arpa" zone for this mapping function, with the expectation 361 that this zone will be created by IANA. It is also expected that 362 authoritative LDAP partitions will be mapped to that zone, and 363 that FIRS-capable LDAP servers will be established to service this 364 partition, with this partition containing ASN-specific entries 365 which will provide referrals to the appropriate RIR partitions. It 366 is further expected that IANA will oversee the creation and 367 management of the asn.arpa domain's LDAP SRV resource records, the 368 "dc=asn,dc=arpa" LDAP partition, and the necessary LDAP servers. 370 The inetAsnDelegationStatus attribute uses numeric code values. It 371 is expected that IANA will manage the assignment of these values. 373 Additional IANA considerations are discussed in [FIRS-ARCH]. 375 8. Normative References 377 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., 378 and Sataluri, S. "Using Domains in LDAP/X.500 379 DNs", RFC 2247, January 1998. 381 [RFC2251] Wahl, M., Howes, T., and Kille, S. 382 "Lightweight Directory Access Protocol (v3)", 383 RFC 2251, December 1997. 385 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, 386 S. "Lightweight Directory Access Protocol 387 (v3): Attribute Syntax Definitions", RFC 2252, 388 December 1997. 390 [RFC2254] Howes, T. "The String Representation of LDAP 391 Search Filters", RFC 2254, December 1997. 393 [FIRS-ARCH] Hall, E. "The Federated Internet Registry 394 Service: Architecture and Implementation 395 Guide", draft-ietf-crisp-firs-arch-03, August 396 2003. 398 [FIRS-CONTCT] Hall, E. "Defining and Locating Contact 399 Persons in the Federated Internet Registry 400 Service", draft-ietf-crisp-firs-contact-03, 401 August 2003. 403 [FIRS-CORE] Hall, E. "The Federated Internet Registry 404 Service: Core Elements", draft-ietf-crisp- 405 firs-core-03, August 2003. 407 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in 408 the Federated Internet Registry Service", 409 draft-ietf-crisp-firs-dns-03, August 2003. 411 [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource 412 Records in the Federated Internet Registry 413 Service", draft-ietf-crisp-firs-dnsrr-02, July 414 2003. 416 [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address 417 Blocks in the Federated Internet Registry 418 Service", draft-ietf-crisp-firs-ipv4-03, 419 August 2003. 421 [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address 422 Blocks in the Federated Internet Registry 423 Service", draft-ietf-crisp-firs-ipv6-03, 424 August 2003. 426 9. Changes from Previous Versions 428 draft-ietf-crisp-firs-asn-03: 430 * Several clarifications and corrections have been made. 432 * The inetAsNumberMatch matching filter was defined. The use 433 of equalityMatch and extensibleMatch has been deprecated. 435 draft-ietf-crisp-firs-asn-02: 437 * Several clarifications and corrections have been made. 439 * Changed the default bootstrap model to use targeted 440 queries, with "asn.arpa" as the default zone and 441 "dc=asn,dc=arpa" as the default partition. 443 * Several attributes had their OIDs changed. NOTE THAT THIS 444 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 445 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 447 draft-ietf-crisp-firs-asn-01: 449 * Several clarifications and corrections have been made. 451 draft-ietf-crisp-firs-asn-00: 453 * Restructured the document set. 455 * "Attribute references" have been eliminated from the 456 specification. All referential attributes now provide 457 actual data instead of URL pointers to data. Clients that 458 wish to retrieve these values will need to start new 459 queries using the data values instead of URLs. 461 * The attribute-specific operational attributes have been 462 eliminated as unnecessary. 464 * The inetAsnRegistrar and inetAsnRegistry attributes were 465 added. 467 * Several attributes had their OIDs changed. NOTE THAT THIS 468 IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO 469 ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. 471 * Several typographical errors have been fixed. 473 * Some unnecessary text has been removed. 475 10. Author's Address 477 Eric A. Hall 478 ehall@ehsco.com 480 11. Acknowledgments 482 Funding for the RFC editor function is currently provided by the 483 Internet Society. 485 Portions of this document were funded by VeriSign Labs. 487 The first version of this specification was co-authored by Andrew 488 Newton of VeriSign Labs, and subsequent versions continue to be 489 developed with his active participation. Edward Lewis also 490 contributed significant feedback to this specification in the 491 later stages of its developments. 493 12. Full Copyright Statement 495 Copyright (C) The Internet Society (2003). All Rights Reserved. 497 This document and translations of it may be copied and furnished 498 to others, and derivative works that comment on or otherwise 499 explain it or assist in its implementation may be prepared, 500 copied, published and distributed, in whole or in part, without 501 restriction of any kind, provided that the above copyright notice 502 and this paragraph are included on all such copies and derivative 503 works. However, this document itself may not be modified in any 504 way, such as by removing the copyright notice or references to the 505 Internet Society or other Internet organizations, except as needed 506 for the purpose of developing Internet standards in which case the 507 procedures for copyrights defined in the Internet Standards 508 process must be followed, or as required to translate it into 509 languages other than English. 511 The limited permissions granted above are perpetual and will not 512 be revoked by the Internet Society or its successors or assigns. 514 This document and the information contained herein is provided on 515 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 516 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 517 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 518 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 519 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.