idnits 2.17.1 draft-ietf-crisp-lw-asn-00.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): ---------------------------------------------------------------------------- ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2002) is 7950 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 5 errors (**), 0 flaws (~~), 0 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-lw-asn-00.txt July 2002 4 Expires: January, 2003 5 Category: Experimental 7 Defining and Locating Autonomous System Numbers 8 using the Internet Resource Query 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 1. Abstract 34 This document defines LDAP schema and searching rules for 35 autonomous system numbers, in support of the Internet Resource 36 Query Service described in [ldap-whois]. 38 2. Definitions and Terminology 40 This document unites, enhances and clarifies several pre-existing 41 technologies. Readers are expected to be familiar with the 42 following specifications: 44 RFC 2247 - Using Domains in LDAP/X.500 DNs 46 RFC 2251 - Lightweight Directory Access Protocol (v3) 48 RFC 2252 - Lightweight Directory Access Protocol (v3): 49 Attribute Syntax Definitions. 51 RFC 2254 - The String Representation of LDAP Search Filters 53 [ir-dir-req] - - 54 Internet Registry Directory Requirements 56 [ldap-whois] - - The 57 Internet Resource Query Service and the Internet Resource 58 Schema 60 The following abbreviations are used throughout this document: 62 DIT (Directory Information Tree) - A DIT is a contained 63 branch of the LDAP namespace, having a root of a particular 64 distinguished name. "dc=example,dc=com" is used throughout 65 this document as one DIT, with many example entries being 66 stored in this DIT. 68 DN (Distinguished Name) - A distinguished name provides a 69 unique identifier for an entry, through the use of a multi- 70 level naming syntax. Entries are named according to their 71 location relevant to the root of their containing DIT. For 72 example, "cn=inetResources,dc=example,dc=com" is a DN which 73 uniquely identifies the "inetResources" entry within the 74 "dc=example,dc=com" DIT. 76 RDN (Relative DN) - An RDN provides a locally-scoped unique 77 identifier for an entry. A complete, globally-unique DN is 78 formed by concatenating the RDNs of an entry together. For 79 example, "cn=admins,cn=inetResources,dc=example,dc=com" 80 consists of two RDNs ("cn=admins" and "cn=inetResources") 81 within the "dc=example,dc=com" DIT. RDNs are typically only 82 referenced within their local scope. 84 OID (Object Identifier) - An OID is a globally-unique, 85 concatenated set of integers which provide a kind of 86 "serial number" to attributes, object classes, syntaxes and 87 other schema elements. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 90 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 91 in this document are to be interpreted as described in RFC 2119. 93 3. The inetAsNumber Object Class 95 The inetAsNumber object class is a structural object class which 96 provides administrative information about a specific autonomous 97 system (AS) number. AS numbers are used to identify routing 98 domains, allowing multiple discontiguous IPv4 and IPv6 network 99 blocks to be referenced with a single, globally-unique identifier. 101 3.1. Naming syntax 103 The naming syntax for AS number entries MUST follow the form of 104 "cn=,cn=inetResources,". Each AS 105 number which is managed as a discrete LDAP-WHOIS network resource 106 MUST have a dedicated entry in each of the DITs which provide 107 public LDAP-WHOIS data regarding that autonomous system. 109 The inetAsNumberSyntax component of an entry is subject to DN 110 rules, although the inetAsNumberSyntax is also used for search and 111 compare operations, and is therefore subject to specific syntax 112 rules. The AS number syntax uses the decimal equivalent of a 16- 113 bit autonomous system number, with the non-affective leading 114 zeroes removed. An augmented BNF for this syntax is as follows: 116 inetAsNumberSyntax = decimal value between "0" and "65535" 117 inclusive, with the non-affective leading zeroes removed 119 For example, an entry for AS number "1" from the "dc=arin,dc=net" 120 DIT would have a DN of "cn=1,cn=inetResources,dc=arin,dc=net", 121 while an entry for AS number "65535" from the same DIT would have 122 a DN of "cn=65535,cn=inetResources,dc=arin,dc=net". 124 3.2. Schema definition 126 AS number entries MUST exist with the top, inetResources and 127 inetAsNumber object classes defined. If an entry exists as a 128 referral, the entry MUST also be defined with the referral object 129 class, in addition to the above requirements. 131 The inetAsNumber object class is a structural object class which 132 is subordinate to the inetResources object class, and which MUST 133 be treated as a container class capable of holding additional 134 subordinate entries. The inetAsNumber object class has no 135 mandatory attributes, although it does have several optional 136 attributes. 138 The inetAsNumber object class defines attributes which are 139 specific to autonomous systems and their associated routing 140 domains, such as the delegation date, and the status of the 141 delegation. The inetAsNumber object class is subordinate to the 142 inetResources object class, so it inherits those attributes as 143 well. 145 Some of the inetAsNumber object class attributes define contact- 146 related referrals which provide LDAP URLs that refer to 147 inetOrgPerson entries, and these entries will need to be queried 148 separately if detailed information about a particular contact is 149 required. The contact attribute values follow the same rules as 150 the labeledURI attribute defined in RFC 2079, with additional 151 restrictions described in [ldap-whois]. 153 The various ModifiedBy and ModifiedDate attributes SHOULD be 154 treated as operational attributes. Their values SHOULD be filled 155 in automatically by the database management application, and 156 SHOULD NOT be returned except when explicitly requested. 158 The network-specific attributes MUST only contain network 159 addresses which are directly associated with the AS number, and 160 MUST use the largest superior prefix delegated to those networks 161 (using the inetIpv4NetworkSyntax and inetIpv6NetworkSyntax rules); 162 these attributes MUST NOT contain host or subnet addresses which 163 are subordinate to another value which is already listed, and 164 these attributes MUST NOT contain network addresses of networks 165 which are associated with any other AS number. 167 The schema definition for the inetAsNumber object class is as 168 follows: 170 inetAsNumber 171 ( 1.3.6.1.4.1.7161.1.4.0 NAME 'inetAsNumber' DESC 'Autonomous 172 system attributes.' SUP inetResources STRUCTURAL MAY ( 173 inetAsnDelegationStatus $ inetAsnDelegationDate $ 174 inetAsnDelegationModifiedDate $ 175 inetAsnDelegationModifiedBy $ inetAsnContacts $ 176 inetAsnContactsModifiedBy $ inetAsnContactsModifiedDate $ 177 inetAsnRoutingContacts $ inetAsnRoutingContactsModifiedBy 178 $ inetAsnRoutingContactsModifiedDate ) ) 180 The attributes from the inetIpv4Network object class are described 181 below: 183 inetAsnContacts 184 ( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAsnContacts' DESC 185 'Contacts for reporting problems with this routing 186 domain.' EQUALITY caseExactMatch SYNTAX 187 1.3.6.1.4.1.1466.115.121.1.15 ) 189 inetAsnContactsModifiedBy 190 ( 1.3.6.1.4.1.7161.1.4.3 NAME 'inetAsnContactsModifiedBy' 191 DESC 'Person who last modified the inetAsnContacts 192 attribute.' EQUALITY distinguishedNameMatch SYNTAX 193 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 194 distributedOperation ) 196 inetAsnContactsModifiedDate 197 ( 1.3.6.1.4.1.7161.1.4.4 NAME 'inetAsnContactsModifiedDate' 198 DESC 'Last modification date of the inetAsnContacts 199 attribute.' EQUALITY generalizedTimeMatch ORDERING 200 generalizedTimeOrderingMatch SYNTAX 201 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 202 distributedOperation ) 204 inetAsnDelegationDate 205 ( 1.3.6.1.4.1.7161.1.4.5 NAME 'inetAsnDelegationDate' DESC 206 'Date of original delegation.' EQUALITY 207 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 208 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) 209 inetAsnDelegationModifiedBy 210 ( 1.3.6.1.4.1.7161.1.4.6 NAME 'inetAsnDelegationModifiedBy' 211 DESC 'Person who last modified the inetAsnDelegationStatus 212 attribute.' EQUALITY distinguishedNameMatch SYNTAX 213 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 214 distributedOperation ) 216 inetAsnDelegationModifiedDate 217 ( 1.3.6.1.4.1.7161.1.4.7 NAME 'inetAsnDelegationModifiedDate' 218 DESC 'Last modification date of the 219 inetAsnDelegationStatus attribute.' EQUALITY 220 generalizedTimeMatch ORDERING generalizedTimeOrderingMatch 221 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 222 distributedOperation ) 224 inetAsnDelegationStatus 225 ( 1.3.6.1.4.1.7161.1.4.8 NAME 'inetAsnDelegationStatus' DESC 226 'Current delegation status code for this AS number.' 227 EQUALITY numericStringMatch SYNTAX 228 1.3.6.1.4.1.1466.115.121.1.27{2} SINGLE-VALUE ) 230 NOTE: In an effort to facilitate internationalization and 231 programmatic processing, the current status of a delegation 232 is identified by a 16-bit integer. The values and status 233 mapping is as follows: 235 0 Reserved delegation (permanently inactive) 236 1 Assigned and active (normal state) 237 2 Assigned but not yet active (new delegation) 238 3 Assigned but on hold (disputed) 239 4 Assignment revoked (database purge pending) 241 Additional values for the inetIpv6DelegationStatus 242 attribute are reserved for future use, and are to be 243 administered by IANA. Note that there is no status code for 244 "unassigned"; unassigned entries SHOULD NOT exist, and 245 SHOULD NOT be returned as answers. 247 inetAsnRoutingContacts 248 ( 1.3.6.1.4.1.7161.1.4.9 NAME 'inetAsnRoutingContacts' DESC 249 'Contacts for routing issues with this IPv4 network.' 250 EQUALITY caseExactMatch SYNTAX 251 1.3.6.1.4.1.1466.115.121.1.15 ) 252 inetAsnRoutingContactsModifiedBy 253 ( 1.3.6.1.4.1.7161.1.4.10 NAME 254 'inetAsnRoutingContactsModifiedBy' DESC 'Person who last 255 modified the inetAsnRoutingContacts attribute.' EQUALITY 256 distinguishedNameMatch SYNTAX 257 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE 258 distributedOperation ) 260 inetAsnRoutingContactsModifiedDate 261 ( 1.3.6.1.4.1.7161.1.4.11 NAME 262 'inetAsnRoutingContactsModifiedDate' DESC 'Last 263 modification date of the inetAsnRoutingContacts 264 attribute.' EQUALITY generalizedTimeMatch ORDERING 265 generalizedTimeOrderingMatch SYNTAX 266 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE 267 distributedOperation ) 269 The inetAsNumberSyntax syntax is as follows: 271 inetAsNumberSyntax 272 ( 1.3.6.1.4.1.7161.1.4.1 NAME 'inetAsNumberSyntax' DESC 'An 273 autonomous system number.' ) 275 3.3. Example 277 An example of the inetAsNumber object class is shown in Figure 1 278 below, with attributes from the inetResources object class also 279 being used to provide administrative contacts. This data is a 280 result of a query which was sent to the LDAP servers associated 281 with the "arin.net" domain. 283 cn=65535,cn=inetResources,dc=arin,dc=net 284 [top object class] 285 [inetResources object class] 286 [inetAsNumber object class] 287 | 288 +-attribute: description 289 | value: "The example.net network" 290 | 291 +-attribute: inetAsnContacts 292 | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins, 293 | dc=example,dc=net" 294 | 295 +-attribute: inetGeneralContacts 296 value: "ldap://ldap.example.com/cn=admins,ou=admins, 297 dc=example,dc=net" 299 Figure 1: The inetAsNumber delegation entry for AS 65535. 301 4. inetAsNumber equalityMatch 303 The inetAsNumber object class can be searched using relatively 304 simple equalityMatch filters. 306 In order to ensure that all of the relevant entries (including any 307 referrals) are found, the search filters for these resources MUST 308 specify two distinct elements: the object class of the resource 309 being queried, and the naming element of the resource specified as 310 a distinguished name attribute. 312 For example, a query for "(&(objectclass=inetAsNumber)(cn:dn:1))" 313 with a search base of "cn=inetResources,dc=example,dc=com" would 314 find all of the inetAsNumber object class entries associated with 315 AS number "1" in the LDAP-WHOIS branch of "dc=example,dc=com". 317 Response entries MAY be fully-developed entries, or MAY be 318 referrals generated from entries which have the referral object 319 class defined. Any attribute values which are received MUST be 320 displayed by the client. If a subordinate reference referral is 321 received, the client MUST restart the query, using the provided 322 data as the new search base. If any continuation reference 323 referrals are received, the client SHOULD start new queries for 324 each reference, and append the output of those queries to the 325 original query's output. 327 5. Security Considerations 329 This document describes an application of the LDAPv3 protocol, and 330 as such it inherits the security considerations associated with 331 LDAPv3, as described in section 7 of RFC 2251. 333 By nature, LDAP is a read-write protocol, while the legacy WHOIS 334 service has always been a read-only service. As such, there are 335 significant risks associated with allowing unintended updates by 336 unauthorized third-parties. Moreover, allowing the LDAP-WHOIS 337 service to update the underlying delegation databases could result 338 in network resources being stolen from their lawful operators. For 339 example, if the LDAP front-end had update access to a domain 340 delegation database, a malicious third-party could theoretically 341 take ownership of that domain by exploiting an authentication 342 weakness, thereby causing ownership of the domain to be changed to 343 another party. For this reason, it is imperative that the LDAP- 344 WHOIS service not be allowed to make critical modifications to 345 delegated resources without ensuring that all possible precautions 346 have been taken. 348 The query processing models described in this document make use of 349 DNS lookups in order to locate the LDAP servers associated with a 350 particular resource. DNS is susceptible to certain attacks and 351 forgeries which may be used to redirect clients to LDAP servers 352 which are not authoritative for the resource in question. 354 Some operators may choose to purposefully provide misleading or 355 erroneous information in an effort to avoid responsibility for bad 356 behavior. In addition, there are likely to be sporadic operator 357 errors which will result in confusing or erroneous answers. 359 This document provides multiple query models which will cause the 360 same query to be answered by different servers (one would be 361 processed by a delegation entity, while another would be processed 362 by an operational entity). As a result, each of the servers may 363 provide different information, depending upon the query type that 364 was originally selected. 366 For all of the reasons listed above, it is essential that 367 applications and end-users not make critical decisions based on 368 the information provided by the LDAP-WHOIS service without having 369 reason to believe the veracity of the information. Users should 370 limit unknown or untrusted information to routine purposes. 372 Finally, there are physical security issues associated with any 373 service which provides physical addressing and delivery 374 information. Although organizations are generally encouraged to 375 provide as much information as they feel comfortable with, no 376 information is required. 378 6. IANA Considerations 380 This document defines an application of the LDAPv3 protocol rather 381 than a new Internet application protocol. As such, there are no 382 protocol-related IANA considerations. 384 However, this document does define several LDAP schema elements, 385 including object classes, attributes, syntaxes and extensibleMatch 386 filters, and these elements should be assigned OID values from the 387 IANA branch, rather than being assigned from a particular 388 enterprise branch. 390 Finally, this document also describes several instances where 391 public DNS and LDAP servers are queried. It is expected that IANA 392 will establish and maintain these LDAP servers (and the necessary 393 DNS SRV domain names and resource records) required for this 394 service to operate. This includes providing SRV resource records 395 in the generic TLDs and the root domain, and also includes 396 administering the referenced LDAP servers. 398 7. Author's Addresses 400 Eric A. Hall 401 ehall@ehsco.com 403 8. References 405 RFC 2247 - Using Domains in LDAP/X.500 DNs 407 RFC 2251 - Lightweight Directory Access Protocol (v3) 409 RFC 2252 - Lightweight Directory Access Protocol (v3): 410 Attribute Syntax Definitions. 412 RFC 2254 - The String Representation of LDAP Search Filters 414 [ir-dir-req] - - 415 Internet Registry Directory Requirements 417 [ldap-whois] - - The 418 Internet Resource Query Service and the Internet Resource 419 Schema 421 9. Acknowledgments 423 Portions of this work were funded by Network Solutions, Inc.