idnits 2.17.1 draft-ietf-rps-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of too long lines in the document, the longest one being 25 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 876 has weird spacing: '... key manda...' == Line 877 has weird spacing: '...ndatory multi...' == Line 878 has weird spacing: '...th-type mand...' == Line 879 has weird spacing: '...ndatory multi...' == Line 880 has weird spacing: '...ndatory multi...' == (20 more instances...) -- 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 (May 15, 1998) is 9477 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) == Unused Reference: '7' is defined on line 1479, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2072 (ref. '3') ** Downref: Normative reference to an Unknown state RFC: RFC 1104 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1222 (ref. '5') ** Downref: Normative reference to an Unknown state RFC: RFC 1102 (ref. '6') ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1519 (ref. '8') (Obsoleted by RFC 4632) ** Downref: Normative reference to an Historic RFC: RFC 1517 (ref. '9') ** Obsolete normative reference: RFC 2050 (ref. '11') (Obsoleted by RFC 7020) -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Historic RFC: RFC 1482 (ref. '13') -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-06) exists of draft-ietf-rps-appl-rpsl-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '15') -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '18') ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '19') ** Obsolete normative reference: RFC 2073 (ref. '21') (Obsoleted by RFC 2374) -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 26 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Curtis Villamizar 3 INTERNET-DRAFT ANS 4 draft-ietf-rps-auth-01 Cengiz Alaettinoglu 5 ISI 6 David M. Meyer 7 University of Oregon 8 Sandy Murphy 9 TIS 10 Carol Orange 11 RIPE 12 May 15, 1998 14 Routing Policy System Security 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 31 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 32 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 33 (US West Coast). 35 Abstract 37 The RIPE database specifications [2] and RPSL language [1] define 38 languages used as the basis for representing information in a routing 39 policy system. A repository for routing policy system information is 40 known as a routing registry. A routing registry provides a means of 41 exchanging information needed to address many issues on importance to 42 the operation of the Internet. The implementation and deployment of a 43 routing policy system must maintain some degree of integrity to be of 44 any operational use. This document addresses the need to assure 45 integrity of the data by providing an authentication and authorization 46 model. 48 1 Overview 50 The Internet Routing Registry (IRR) has evolved to meet a need for 51 Internet-wide coordination. This need was described in RFC-1787, an 52 informational RFC prepared on behalf of the IAB [18]. The following 53 summary appears in Section 7 of RFC-1787. 55 While ensuring Internet-wide coordination may be more and more 56 difficult, as the Internet continues to grow, stability and con- 57 sistency of the Internet-wide routing could significantly benefit 58 if the information about routing requirements of various organi- 59 zations could be shared across organizational boundaries. Such 60 information could be used in a wide variety of situations ranging 61 from troubleshooting to detecting and eliminating conflicting 62 routing requirements. The scale of the Internet implies that the 63 information should be distributed. Work is currently underway to 64 establish depositories of this information (Routing Registries), 65 as well as to develop tools that analyze, as well as utilize this in- 66 formation. 68 A routing registry must maintain some degree of integrity to be of any 69 use. The degree of integrity required depends on the usage of the 70 routing policy system. 72 An initial intended usage of routing policy systems such as the RIPE 73 database had been in an advisory capacity, documenting the intended 74 routing policies for the purpose of debugging. In this role a very 75 weak form of authentication was deemed sufficient. 77 The IRR is increasingly used for purposes that have a stronger 78 requirement for data integrity and security. This document addresses 79 issues of data integrity and security that is consistent with the 80 usage of the IRR and which avoids compromising data integrity and se- 81 curity even if the IRR is distributed among less trusted repositories. 83 2 Background 85 An early routing policy system used in the T3--NSFNET, the policy 86 routing database (PRDB), provided a means of determining who was 87 authorized to announce specific prefixes to the NSFNET backbone. The 88 need for a policy database was recognized as far back as 1989 [6, 4]. 89 By 1991 the database was in place [5]. Authentication was 90 accomplished by requiring confirmation and was a manually intensive 91 process. This solved the problem for the NSFNET, but was oriented 92 toward holding the routing policy of a single organization. 94 The problem since has become more difficult. New requirements have 95 emerged. 97 1. The need to represent the routing policies of many organizations, 99 2. CIDR and overlapping prefixes, the increasing complexity of routing 100 policies and the needs of aggregation, 101 3. the need to assure integrity of the data and delegate authority for 102 the data representing specifically allocated resources to multiple 103 persons or organizations, 105 4. the need to assure integrity of the data and distribute the storage 106 of data subsets to multiple repositories. 108 The RIPE effort specificly focused on the first issue [2]. Its 109 predecessor, the PRDB, addressed the needs of a single organization, 110 while the RIPE database was initially intended to address the needs of 111 the European Internet community. The RIPE database formats as 112 described in [2] are the basis of current IRR. 114 Routing protocols themselves provide no assurance that the origination 115 of a route is legitimate and can actually reach the stated 116 destination. The nature of CIDR allows more specific prefixes to 117 override less specific prefixes [9, 19, 8]. Even with signed route 118 origination, there is no way to determine if a more specific prefix is 119 legitimate and should override a less specific route announcement 120 without a means of determining who is authorized to announce specific 121 prefixes. Failing to do so places no assurance of integrity of global 122 routing information and leaves an opportunity for a very effective 123 form of denial of service attack. 125 The Routing Policy System Language (RPSL) [1, 15, 14] was a fairly 126 substantial evolutionary step in the data representation which was 127 largely targeted at addressing the second group of needs. The PRDB 128 accommodated CIDR in 1993 [13] and the RIPE database accommodated the 129 entry of CIDR prefixes from inception, but RPSL provides many needed 130 improvements including explicit support for aggregation. Transition 131 of the IRR to RPSL is expected to occur in late 1988 [12]. 133 This document addresses the third group of needs identified above. 135 While the current implementation supporting weak authentication 136 doesn't guarantee integrety of the data, it does provide extensive 137 mechanisms to make sure that all involved parties get notified when a 138 change is made to the database, whether the change was malicious or 139 intended. This provides inaddequate protection against additions. 140 Since the software is increasingly used to configure the major parts 141 of the Internet infrastructure, it is not considered to be adequate 142 anymore to know about and have the ability roll back unintended 143 changes. Therefore, more active security mechanism need to be 144 developed to prevent such problems before they happen. 146 A separate document addressing the fourth group of needs is also being 147 written. 149 3 Implicit Policy Assumptions 151 The authorization model encodes certain policies for allocation of 152 address numbers, AS numbers, and for the announcement of routes. 153 Implicit to the authorization model are a very limited number of 154 policy assumptions. 156 1. Address numbers are allocated hierachically. The IANA delegates 157 portions of the address space to the regional registries (currently 158 ARIN, APNIC and RIPE), which in turn delegate address space to 159 their members, who can assign addresses to their customers. 160 2. AS numbers are allocated either singly or in small blocks by 161 registries. Registries are allocated blocks of AS numbers, thereby 162 making the allocation hierarchical. 164 3. Routes should only be anounced with the consent of the holder of 165 the origin AS number of the announcement and with the consent of 166 the holder of the address space. 168 4. AS numbers and IP address registries may be different entities from 169 routing registries. 171 For subsets of any of these three allocation spaces, network 172 addresses, AS numbers, and routes, these restrictions may be loosened 173 or disabled by specifying a very weak authorization method or an 174 authentication method of ``none''. However, even when no 175 authentication mechanism is used, all involved parties can be notified 176 about the changes that occurred through use of the existing ``notify'' 177 attribute. 179 4 Organization of this Document 181 Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this 182 document. Goals are described in Section 5. Section 6 through 183 Section 8 provide descriptions of the changes and discussion. 184 Section 9 provides a concise summary of data formats and semantics. 185 Appendix A through Appendix C provide additional technical discussion, 186 examples, and deployment considerations. 188 Goals and Requirements Section 5 provides a more detailed 189 description of the issues and identifies specific problems that 190 need to be solved, some of which require a degree of cooperation in 191 the Internet community. 193 Data Representation Section 6 provides some characteristics of RPSL 194 and formats for external representations of information. 196 Authentication Model Section 7 describes current practice, proposes 197 additional authentication methods, and describes the extension 198 mechanism if additional methods are needed in the future. 200 Authorization Model Section 8 describes the means of determining 201 whether a transaction contains the authorization needed to add, 202 modify, or delete specific data objects, based on stated 203 authentication requirements in related data objects. 205 Data Format Summaries Section 9 provides a concise reference to the 206 data formats and steps in transaction processing. 208 Technical Discussion Section A contains some discussion of 209 technical tradeoffs. 211 Common Operational Cases Section B provides some examples drawn 212 from past operational experience with the IRR. 214 Deployment Considerations Section C describes some deployment 215 issues and discusses possible means of resolution. 217 5 Goals and Requirements 219 The Internet is an open network. This openness and the large scale of 220 the Internet can present operational problems. Technical weaknesses 221 that allow misconfiguration or errant operation in part of the network 222 to propagate globally or which provide potentials for simple denial of 223 service attacks should be eliminated to the extent that it is 224 practical. The integrity of routing information is critical in 225 assuring that traffic goes where it is supposed to. 227 An accidental misconfiguration can direct traffic toward routers that 228 cannot reach a destination for which they are advertising reachabil- 229 ity. This is commonly caused by misconfigured static routes though 230 there are numerous other potential causes. Static routes are often 231 used to provide constant apparent reachability to single homed desti- 232 nations. Some of the largest ISPs literally have thousands of static 233 routes in their networks. These are often entered manually by opera- 234 tors. Mistyping can divert traffic from a completely unrelated desti- 235 nation to a router with no actual reachability to the advertised des- 236 tination. This can happen and does happen somewhat regularly. In ad- 237 dition, implementation bugs or severe misconfigurations that result in the 238 loss of BGP AS path information or alteration of prefix length can result 239 in the advertisement of large sets of routes. Though considerably more 240 rare, on a few occasions where this has occurred the results were catas- 241 trophic. 243 Where there is the potential for an accidental misconfiguration in a 244 remote part of the Internet affecting the global Internet there is 245 also the potential for malice. For example, it has been demonstrated 246 by accident that multiple hour outages at a major institution can be 247 caused by a laptop and a dial account if proper precautions are not 248 taken. The dial account need not be with the same provider used by 249 the major institution. 251 The potential for error is increased by the CIDR preference for more 252 specific routes [8]. If an institution advertises a single route of a 253 given length and a distant router advertises a more specific router 254 covering critical hosts, the more specific route, if accepted at all, 255 is preferred regardless of administrative weighting or any routing 256 protocol attributes. 258 There is a need to provide some form of checks on whether a route 259 advertisement is valid. Today checks are typically made against the 260 border AS advertising the route. This prevents accepting routes from 261 the set of border AS that could not be legitimately advertise the 262 route. Theses checks rely on the use of information registered in the 263 IRR to generate lists of prefixes that could be advertised by a 264 specific border AS. Checks can also be made against the origin AS. If 265 policy information were sufficiently populated, checks could be made 266 against the entire AS path, but this is not yet feasible. 268 The use of a routing registry can also make it more difficult for 269 prefixes to be used without authorization such as unallocated prefixes 270 or prefixes allocated to another party. 272 In summary, some of the problems being addressed are: 274 o Localizing the impact of accidental misconfiguration made by 275 Internet Providers to that provider's networks only. 277 o Eliminating the potential for an Internet provider's customer to 278 use malicious misconfiguration of routing as a denial of service 279 attack if the provider router filters their customers and 280 localizing the denial of service to that Internet provider only if 281 the immediate Internet service provider does not route filter their 282 customers but other providers route filter the route exchange at 283 the inter-provider peering. 285 o Eliminating the unauthorized use of address space. 287 If the data within a routing registry is critical, then the ability to 288 change the data must be controlled. Centralized authorities can 289 provide control but centralization can lead to scaling problems (and 290 is politically distasteful). 292 Address allocation and name allocation is already delegated. Since 293 delegation can be to outside registries it is at least somewhat 294 distributed [11]. Autonomous System (AS) numbers are allocated by the 295 same authorities. It makes sense to delegate the routing number space 296 in a manner similar to the address allocation and AS number 297 allocation. The need for this delegation of authority to numerous 298 registries increases the difficulty of maintaining the integrity of 299 the body of information as a whole. 301 As a first step, the database can be somewhat centrally administered 302 with authority granted to many parties to change the information. 303 This is the case with the current IRR. There are a very small number 304 of well trusted repositories and a very large number of parties 305 authorized to make changes. Control must be exercised over who can 306 make changes and what changes they can make. The distinction of who 307 vs what separates authentication from authorization. 309 o Authentication is the means to determine who is attempting to make 310 a change. 312 o Authorization is the determination of whether a transaction passing 313 a specific authentication check is allowed to perform a given 314 operation. 316 Different portions of the database will require different methods of 317 authentication. Some applications will require authentication based 318 on strong encryption. In other cases software supporting strong 319 encryption may not be necessary or may not be legally available. For 320 this reason multiple authentication methods must be supported, 321 selected on a per object basis. The authentication methods may range 322 from very weak data integrity checks to cryptographicly strong 323 signatures. The authorization model must insure that the use of weak 324 integrity checks in parts of the database does not compromise the 325 overall integrity of the database. 327 Additional requirements are placed on the authorization model if the 328 database is widely distributed with delegations made to parties that 329 may not be trustworthy or whose security practices may be lacking. 330 This problem must be addressed in the authorization model in order to 331 enable later evolution to a more distributed routing registry. 333 Autonomous system numbers can be delegated in blocks and subdelegated 334 as needed and then individual AS numbers assigned. Address allocation 335 is a simple numeric hierarchy. Route allocation is somewhat more 336 complicated. The key attributes in a route object (key with regard to 337 making it unique) contains both an address prefix and an AS number, 338 known as the origin AS. The addition of a route object must be 339 validated against both the authorization criteria for the AS and the 340 address prefix. Route objects may exist for the same prefix with mul- 341 tiple origin AS values due to a common multihoming practice that does 342 not require a unique origin AS. There is often no correlation between 343 the origin AS of a prefix and the origin AS of overlapping more specific 344 prefixes. 346 There are numerous operational cases that must be accommodated. Some 347 of the more common are listed below. These are explored in greater 348 detail in Appendix B with discussion of technical tradeoffs in 349 Appendix A. 351 o simple hierarchical address allocation and route allocation 353 o aggregation and multihomed more specific routes 354 o provider independent addresses and multiple origin AS 356 o changing Internet service providers 358 o renumbering grace periods 360 The authorization model must accommodate a variety of policies 361 regarding the allocation of address space and cannot mandate the use 362 of any one model. There is no standardization of address allocation 363 policies though guidelines do exist [11, 20]. Whether authorization 364 allows the recovery of address space must be selectable on a per 365 object basis and may differ in parts of the database. This issue is 366 discussed further in Appendix A. 368 6 Data Representation 370 RPSL provides a complete description of the contents of a routing 371 repository [1]. Many RPSL data objects remain unchanged from the RIPE 372 and RPSL references the RIPE-181 specification as recorded in RFC-1786 373 [2]. RPSL provides external data representation. Data may be stored 374 differently internal to a routing registry. 376 Some database object types or database attributes must be added to 377 RPSL to record the delegation of authority and to improve the 378 authentication and authorization mechanisms. These additions are very 379 few and are described in Section 7 and Section 8. 381 Some form of encapsulation must be used to exchange data. The 382 de-facto encapsulation has been the one which the RIPE tools accept, a 383 plain text file or plain text in the body of an RFC-822 formatted mail 384 message with information needed for authentication derived from the 385 mail headers or the body of the message. Merit has slightly modified 386 this using the PGP signed portion of a plain text file or PGP signed 387 portion of the body of a mail message. These very simple forms of 388 encapsulation are suitable for the initial submission of a database 389 transaction. 391 The encapsulation of registry transaction submissions, registry 392 queries and registry responses and exchanges between registries is 393 outside the scope of this document. 395 7 Authentication Model 397 The maintainer objects serve as a container to hold authentication 398 filters. A reference to a maintainer within another object defines 399 authorization to perform operations on the object or on a set of 400 related objects. The maintainer is typically referenced by name in 401 mnt-by attributes of objects. Further details on the use of 402 maintainers are provided in Section 8.1. 404 The maintainer contains one or more ``auth'' attributes. Each 405 ``auth'' attribute begins with a keyword identifying the 406 authentication method followed by the authentication information 407 needed to enforce that method. For example, where the method is 408 identified by the keyword ``pgp-key'' the authentication information 409 is the PGP public key block in ASCII radix-64 format. 411 Authentication methods currently supported include the following. 412 Note that pgp-from is being replaced by the pgp-key (see Section 9). 414 mail-from This is a very weak authentication check and is 415 discouraged. The authentication information is a regular 416 expression over ASCII characters. The maintainer is authenticated 417 if the from or reply-to fields in RFC-822 mail headers are matched 418 by this regular expression. Since mail forgery is quite easy, this 419 is a very weak form of authentication. 421 crypt-pw This is another weak form of authentication. The 422 authentication information is a fixed encrypted password in UNIX 423 crypt format. The maintainer is authenticated if the transaction 424 contains the clear text password of the maintainer. Since the 425 password is in clear text in transactions, it can be captured by 426 snooping. Since the encrypted form of the password is exposed, it 427 is subject to password guessing attacks. 429 pgp-from This format is being replaced by the ``pgp-key'' so that the 430 public key certificate will be available to remote repositories. 431 This is Merit's PGP extension. The authentication information is a 432 signature identity pointing to an external public key ring. The 433 maintainer is authenticated if the transaction (currently PGP 434 signed portion of a mail message) is signed by the corresponding 435 private key. 436 pgp-key The authentication information is a PGP public key block in 437 ASCII radix-64 format. The maintainer is authenticated if the 438 transaction is signed by the corresponding private key. 440 Repositories may elect to disallow the addition of ``auth'' attributes 441 specifying weaker forms of authentication and/or disallow their use in 442 local transaction submissions. Repositories are encouraged to 443 disallow the addition of ``auth'' attributes with the depricated 444 ``pgp-from'' method. 446 Any digital signature technique can be used for authentication. 447 Transactions should be signed using multiple digital signature 448 techniques to allow repositories or mirrors that only use a subset of 449 the techniques to verify at least one of the signatures. Any digital 450 signature techniques would be applicable. One that may be supported 451 in the in the future is DSA [16, 17]. Numerous digital signature 452 algorithms are described in [22]. 454 8 Authorization Model 456 The authorization model must accommodate the requirements outlined in 457 Section 5. A key feature of the authorization model is the 458 recognition that authorization for the addition of certain types of 459 data objects must be derived from related data objects. 461 With multiple repositories, objects not found in RPSL are needed to 462 control AS delegations and new attributes are needed in existing 463 objects to control subdelegation. Objects are also needed to provide 464 query information for other repositories. 466 A root repository must be agreed upon. Ideally such a repository 467 would contain only top level delegations and pointers to other 468 repositories used in these delegations. It would be wise to allow 469 only cryptographically strong transactions in the root repository. 470 The following might be used to identify a repository (for formal 471 description, see 9). 473 repository: RIPE 474 query-address: whois.ripe.net 43 475 response-auth-type: rsa-pubkey some-incredibly-long-public-key 476 response-auth-type: none 477 remarks: you can request rsa signature on queries 478 submit-address: mailto://auto-dbm@ripe.net 479 submit-address: rps-query://whois.ripe.net:43 480 submit-auth-type: pgp-key crypt-pw mail-from 481 remarks: these are the authentication types supported 482 mnt-by: maint-ripe-db 483 refresh: 3600 484 expire: 14400 485 remarks: refresh and expire same as in DNS SOA 486 ... 487 remarks: admin and technical contact, etc 488 source: IANA 490 In each repository there should be a special repository object named 491 ROOT. This should point to the root repository or to a higher level 492 repository. This is to allow queries to be directed to the local 493 repository but refer to the full set of registries for resolution of 494 hierarchically allocated objects. 496 The ``repository'' object and its usage is described in greater detail 497 in Section 9. 499 8.1 Maintainer Objects 501 The maintainer objects serve as a container to hold authentication 502 filters. The authentication methods are described in Section 7. The 503 maintainer can be referenced by name in other objects, most notably in 504 the mnt-by attributes of those objects. 506 Maintainers themselves contain mnt-by attributes. In some cases the 507 mnt-by in a maintainer will reference the maintainer itself. In this 508 case, authorization to modify the maintainer is provided to a (usually 509 very limited) set of identities. A good practice is to create a 510 maintainer containing a long list of identities authorized to make 511 specific types of changes but have the maintainer's mnt-by attribute 512 reference a far more restrictive maintainer more tightly controlling 513 changes to the maintainer object itself. 515 The mnt-by attribute is mandatory in all objects. Some data already 516 exists without mnt-by attributes. A missing mnt-by attribute is 517 interpreted as the absence of any control over changes. This is 518 highly inadvisable and most repositories will no longer allow this. 520 The ``mnt-routes'' attribute are needed to reference maintainer 521 objects to provide specific permissions related to the object. This 522 is an extensions to RPSL and RIPE-181 proposed in this document and 523 are described in detail in Section 9. 525 A mnt-routes attribute in an aut-num object allows addition of route 526 objects with that AS number as the origin to the maintainers listed. 527 A mnt-routes attribute in an inetnum object allows addition of route 528 objects with exact matching or more specific prefixes. A mnt-routes 529 attribute in a route object allows addition of route objects with 530 exact matching or more specific prefixes. A mnt-routes attribute does 531 not allow changes to the aut-num, inetnum, or route object where they 532 appear. A mnt-routes may optionally be constrained to only apply to a 533 subset of more specific routes. 535 8.2 The reclaim and no-reclaim attributes 537 A reclaim attribute is needed in as-block, inetnum and route objects. 538 The reclaim attribute allows a control to be retained over more 539 specific AS, address or route space by allowing modify and delete 540 privileges regardless of the mnt-by in the object itself. 542 The reclaim and no-reclaim attributes contain contain lists of objects 543 subject to the reclaim and no-reclaim. See Section 9 for a full 544 description of the reclaim and no-reclaim attributes. 546 The reclaim attribute provides the means to enforce address lending. 547 It allows cleanup in cases where entities cease to exist or as a last 548 resort means to correct errors such as parties locking themselves out 549 of access to their own objects. To allow finer control a set of 550 prefixes can be specified. 552 A no-reclaim attribute can be used to provide explicit exceptions. A 553 reclaim attribute can only be added to an existing object if the 554 addition of the reclaim attribute does not remove autonomy of existing 555 more specific objects that are covered by the new reclaim attribute. 557 1. A reclaim attribute can be added to an existing object if there are 558 no existing exact matches or more specific objects overlapped by 559 the new reclaim attribute, or 561 2. if the submitter is listed in the maintainer pointed to be the 562 mnt-by of the objects which are overlapped, or 563 3. if any overlapped object is listed in a no-reclaim attribute in the 564 object where the reclaim is being added. 566 Similarly a no-reclaim attribute cannot be deleted unless there are no 567 overlapped objects for which the submitter is not listed in the 568 maintainer pointed to be the mnt-by of the overlapped object. 570 8.3 AS-block and aut-num objects 572 An ``as-block'' object is needed to delegate a range of AS numbers to 573 a given repository. This is needed for authorization and it is needed 574 to avoid having to make an exhaustive search of all repositories to 575 find a specific AS. This search would not be a problem now but would 576 be if a more distributed routing repository is used. 578 The ``as-block'' object also makes it possible to separate AS number 579 allocation from registration of AS routing policy. 581 as-block: AS1321 - AS1335 582 delegated: ANS 583 ... 585 The ``aut-num'' describes the routing policy for an AS and is critical 586 for router configuration of that AS and for analysis performed by 587 another AS. For the purpose of this document it is sufficient to 588 consider the aut-num solely as a place holder identifying the 589 existence of an AS and providing a means to associate authorization 590 with that AS for the purpose of adding ``route'' objects. 592 The ``as-block'' object is proposed here solely as a means of record- 593 ing the delegation of blocks of AS numbers to alternate registries and 594 in doing so providing a means to direct queries and a means to support 595 hierarchical authorization across multiple repositories. 597 8.4 inetnum objects 599 A delegation attribute is needed in the inetnum and route object. 600 This will accommodate the delegation of address space from IANA to 601 regional IP registries. When the routing registry becomes more widely 602 distributed a delegation attribute is needed to support any 603 subdelegations to more localized registries or delegations to Internet 604 provider operated registries or organizations who may prefer to run 605 their own routing registry. The delegation attribute for an inetnum 606 or a route object can be multi-valued and refers to all registries in 607 which more specific route objects can be found. 609 inetnum: 193.0.0.0 - 193.0.0.255 610 delegated: RIPE 611 ... 612 source: IANA 614 This inetnum simply delegates the storage of any more specific inetnum 615 objects overlapping the stated range to the RIPE repository. An exact 616 match of this inetnum may exist in the RIPE repository to provide 617 hooks for the attributes referencing maintainer objects. 619 The ``inetnum'' exists to support address allocation. For external 620 number registries, such as those using ``[r]whoisd[++]'' the 621 ``inetnum'' can serve as a secondary record that is added when an 622 address allocation is made in the authoritative database. Such 623 records could be added by a address registry such as ARIN as a 624 courtesy to the corresponding routing registry. 626 8.5 route objects 628 Currently there are a quite few route objects in more than one 629 registry. Quite a few are registered with origin AS for which they 630 have never been announced. There is a legitimate reason to be in more 631 than one origin AS. With the previous authorization restrictions, this 632 could result in a route object for the same prefix in more than one 633 database. The example below is a route registered differently in two 634 databases (and registered incorrectly). This would now require a 635 delegation attribute. 637 route: 128.32.0.0/16 638 delegated: MCI RADB 640 The ``delegated'' attribute should be single valued for all objects 641 except those that are granfathered due to addition prior to the use of 642 these authorization rules. This is to prevent race conditions 643 involving mutually exclusive additions with the same origin AS in 644 different repositories. 646 The ``route'' object is used to record routes which may appear in the 647 global routing table. Explicit support for aggregation is provided. 648 Route objects exist both for the configuration of routing information 649 filters used to contain incidents of erroneous route announcements 650 (Section 5) and to support network problem diagnosis. 652 8.6 Other Objects 654 Many of the RPSL ancillary objects have no natural hierarchy the way 655 AS numbers, Internet addresses and routes have a numeric hierarchy. 656 Some examples are ``maintainers'', ``people'' and ``role'' objects. 657 For these objects, lack of any hierarchy leads to two problems. 659 1. There is no hierarchy that can be exploited to direct queries to 660 alternate registries. At some point the query strategy of 661 searching all known registries becomes impractical. 663 2. There is no hierarchy on which authorizations of additions can be 664 based. 666 The first problem can be addressed by considering the name space for 667 each of the ancillary objects to be unique only within the local 668 database and to use explicit references to an external repository 669 where needed. A possible syntax is to precede the object key with the 670 name of the repository and a delimiter. For example, the delimiter 671 ``::'' can be used to form the NIC handle ``RIPE::CO19''. Currently 672 there is a desire to keep NIC handles unique so the naming convention 673 of appending a dash and the repository name is used. Prepending the 674 repository name provides the unique name space since an object in the 675 RIPE database referencing ``CO19'' would be interpreted as 676 ``RIPE::CO19'' by default, but it would still be possible to query or ref- 677 erence ``IANA::CO19''. There is no possibility of accidentally forget- 678 ting to adhere to the conventions when making an addition and the exist- 679 ing objects are accommodated, including cases where name conflicts have 680 already occurred. 682 The second problem can be partially addressed by using a referral 683 system for the addition of maintainers and requiring that any other 684 object be submitted by a registered maintainer. The referral system 685 would allow any existing maintainer to add another maintainer. This 686 can be used in parallel with the addition of other object types to 687 support the maintenance of those objects. For example, when adding a 688 subdomain to the ``domain'' hierarchy (in the RIPE repository where 689 domains are also handled), even when adding a new domain to a rela- 690 tively flat domain such as ``com'', there is already a maintainer for 691 the existing domain. The existing maintainer can add the maintainer 692 that will be needed for the new domain in addition to adding the new do- 693 main and giving the new maintainer the right to modify it. 695 An organization gaining a presence on the Internet for the first time 696 would be given a maintainer. This maintainer may list a small number 697 of very trusted employees that are authorized to modify the maintainer 698 itself. The organization itself can then add another maintainer 699 listing a larger set of employees but listing the more restrictive 700 maintainer in the mnt-by attributes of the maintainers themselves. 701 The organization can then add people and role objects as needed and 702 any other objects as needed and as authorization permits. 704 8.7 Query Processing 706 A query may have to span multiple repositories. All queries should be 707 directed toward a local repository which may mirror the root 708 repository and others. Currently each IRR repository mirrors all 709 others repositories. In this way, the query may be answered by the 710 local repository but draw data from others. 712 For object types that have a natural hierarchy, such as aut-num, 713 inetnum, and route, the search begins at the root database and follows 714 the hierarchy. For objects types that have no natural hierarchy, such 715 as maintainers, people, and roles, the search is confined to a default 716 database unless a database is specified. The default database is the 717 same database as an object from which a reference is made if the query 718 is launched through the need to follow a reference. Otherwise the 719 default is generally the local database or a default set by the 720 repository. The default can be specified in the query itself. 722 In searching for an AS, the AS blocks can be consulted, moving the 723 search to data from other repositories. Eventually the AS is either 724 found or the search fails. 726 The search for an inetnum is similar. Less specific inetnums may 727 refer the search to other databases. Eventually the most specific 728 inetnum is found and its status can be determined and assignment 729 determined if it is assigned. 731 The search for a route is similar except the search may branch to more 732 than one repository. The most specific route in one repository may be 733 more specific than the most specific in another. In looking for a 734 route object it makes sense to return the most specific route that is 735 not more specific than the query requests regardless of which 736 repository that route is in rather than return one route from each 737 repository that contains a less specific overlap. 739 8.8 Adding to the Database 741 The root repository must be initially populated at some epoch with a 742 few entries. An initial maintainer is needed to add more maintainers. 743 The referral-by and referral-in attribute can be set to refer to 744 itself in this special case (Section 9 describes the referral-by and 745 referral-in). When adding an inetnum or a route object an existing 746 exact match or a less specific overlap must exist. A route object may 747 be added based on an exact match or a less specific inetnum. The root 748 repository must be initially populated with the allocation of an 749 inetnum covering the prefix 0/0, indicating that some address 750 allocation authority exists. Similarly an initial as-block is needed 751 covering the full AS number range. 753 When adding an object with no natural hierarchy, the search for an 754 existing object follows the procedure outlined in Section 8.7. 756 When adding an aut-num (an AS), the same procedure used in a query is 757 used to determine the appropriate repository for the addition and to 758 determine which maintainer applies. The sequence of AS-block objects 759 and repository delegations is followed. If the aut-num does not 760 exist, then the submission must match the authentication specified in 761 the maintainer for the most specific AS-block in order to be added. 763 The procedure for adding an inetnum is similar. The sequence of 764 inetnum blocks is followed until the most specific is found. The 765 submission must match the authentication specified in the maintainer 766 for the most specific inetnum overlapping the addition. 768 Adding a route object is somewhat more complicated. The route object 769 submission must satisfy two authentication criteria. It must match 770 the authentication specified in the aut-num and the authentication 771 specified in either a route object or if no applicable route object is 772 found, then an inetnum. 774 An addition is submitted with an AS number and prefix as its key. If 775 the object already exists, then the submission is treated as a modify 776 (see Section 8.9). If the aut-num does not exist on a route add, then 777 the addition is rejected (see Section A for further discussion of 778 tradeoffs). If the aut-num exists then the submission is checked 779 against the applicable maintainer. A search is then done for the 780 prefix first looking for an exact match. If the search for an exact 781 match fails, a search is made for the longest prefix match that is 782 less specific than the prefix specified. If this search succeeds it 783 will return one or more route objects. The submission must match an 784 applicable maintainer in at least one of these route objects for the ad- 785 dition to succeed. If the search for a route object fails, then a search 786 is performed for an inetnum that exactly matches the prefix or for the most 787 specific inetnum that is less specific than the route object submission. 788 The search for an inetnum should never fail but it may return an unallo- 789 cated or reserved range. The inetnum status must be ``allocated'' and the 790 submission must match the maintainer. 792 Having found the AS and either a route object or inetnum, the 793 authorization is taken from these two objects. The applicable 794 maintainer object is any referenced by the mnt-routes attributes. If 795 one or more mnt-routes attributes are present in an object, the mnt-by 796 attributes are not considered. In the absence of a mnt-routes 797 attribute in a given object, the mnt-by attributes are used for that 798 object. The authentication must match one of the authorizations in 799 each of the two objects. 801 If the addition of a route object or inetnum contains a reclaim 802 attribute, then any more specific objects of the same type must be 803 examined. The reclaim attribute can only be added if there are no 804 more specific overlaps or if the authentication on the addition is 805 present in the authorization of a less specific object that already 806 has a reclaim attribute covering the prefix range, or if the 807 authentication on the addition is authorized for the modification of 808 all existing more specific prefixes covered by the addition. 810 8.9 Modifying or Deleting Database Objects 812 When modifying or deleting any existing object a search for the object 813 is performed as described in Section 8.7. If the submission matches 814 an applicable maintainer for the object, then the operation can 815 proceed. An applicable maintainer for a modification is any 816 maintainer referenced by the mnt-by attribute in the object. For 817 route and inetnum objects an applicable maintainer may be listed in a 818 less specific object with a reclaim attribute. 820 If the submission is for a route object, a search is done for all less 821 specific route objects and inetnums. If the submission is for an 822 inetnum, a search is done for all less specific inetnums. If the 823 submission fails the authorization in the object itself but matches 824 the reclaim attribute in any of the less specific objects, then the 825 operation can proceed. Section A contains discussion of the rationale 826 behind the use of the reclaim attribute. 828 A modification to an inetnum object that adds a reclaim attribute or 829 removes a no-reclaim attribute must be checked against all existing 830 inetnums that are more specific. The same check of the reclaim 831 attribute that is made during addition must be made when a reclaim 832 attribute is added by a modification (see Section 8.8). 834 A deletion is considered a special case of the modify operation. The 835 deleted object may remain in the database with a ``deleted'' attribute 836 in which case the mnt-by can still be consulted to remove the 837 ``deleted'' attribute. 839 9 Data Format Summaries 841 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII 842 text. Objects consist of a set of attributes. Attributes are name 843 value pairs. A single attribute is represented as a single line with 844 the name followed by a colon followed by whitespace characters (space, 845 tab, or line continuation) and followed by the value. Within a value 846 all whitespace is equivalent to a single space. Line continuation is 847 supported by a backslash at the end of a line or the following line 848 beginning with whitespace. When transferred, externally attributes 849 are generally broken into shorter lines using line continuation though 850 this is not a requirement. An object is externally represented as a 851 series of attributes. Objects are separated by blank lines. 853 There are about 80 attribute types in the current RIPE schema and 854 about 15 object types. Some of the attributes are mandatory in 855 certain objects. Some attributes may appear multiple times. One or 856 more attributes may form a key. Some attributes or sets of attributes 857 may be required to be unique across all repositories. Some of the 858 attributes may reference a key field in an object type and may be 859 required to be a valid reference. Some attributes may be used in 860 inverse lookups. 862 A review of the entire RIPE or RPSL schema would be too lengthy to 863 include here. Only the differences in the schema are described. 865 9.1 Changes to the RIPE/RPSL Schema 867 Two object types are added to the RIPE/RPSL schema. A few attributes 868 are added to existing object types. There are significant changes to 869 the rules which determine if the addition of an object is authorized. 870 Additional keywords representing new authentication types are added to 871 the semantics of the existing ``auth'' attribute. 873 The new object types are listed below. The first attribute listed is 874 the key attribute and also serves as the name of the object type. 876 repository key mandatory single unique 877 query-address mandatory multiple 878 response-auth-type mandatory multiple 879 submit-address mandatory multiple 880 submit-auth-type mandatory multiple 881 refresh optional single 882 expire mandatory single 883 descr optional multiple 884 remarks optional multiple 885 admin-c mandatory multiple 886 tech-c mandatory multiple 887 notify optional multiple 888 mnt-by mandatory multiple 889 changed mandatory multiple 890 source mandatory single 892 as-block key mandatory single unique 893 delegated optional single 894 descr optional multiple 895 remarks optional multiple 896 admin-c mandatory multiple 897 tech-c mandatory multiple 898 notify optional multiple 899 mnt-by mandatory multiple 900 changed mandatory multiple 901 source mandatory single 903 In the above object types only a small number of the attribute types 904 are new. These are: 906 repository This attribute provides the name of the repository. This 907 is the key field for the object and is single and must be globally 908 unique. This is the same name used in the source attribute of all 909 objects in that repository. 910 query-address This attribute provides a host name and a port number 911 used to direct queries. Optional fields may follow the port number 912 at a later time and should be ignored. Alternately a URL format 913 may be used. The special protocol identified ``rps-query'' can be 914 used in URL format. 916 response-auth-type This attribute provides the authentication types 917 that may be used by the repository when responding to queries. 918 submit-address This attribute provides a host name and a port number 919 used to submit objects to the repository. Optional fields may 920 follow the port number at a later time and should be ignored. 921 Alternately a URL format may be used. The special protocol 922 identified ``rps-query'' can be used in URL format. 924 submit-auth-type This attribute provides the authentication types 925 that may be used by the repository when responding to queries. 927 refresh Near real time flooding of repository updates is recommended 928 as a method of distributing database changes. The refresh suggests 929 a time interval for processing updates. Time is in seconds if 930 expressed as an integer. Alternately, the letters ``h'', ``m'', or 931 ``s'' can be used to indicate hours, minutes, and seconds. 933 expire If near real time flooding is temporarily not operational, 934 objects should be considered non-authoritative after this interval, 935 and cannot be used for authorization purposes. 937 as-block This attribute provides the AS number range for an 938 ``as-block'' object. 939 delegated This attribute indicates that further searches for object 940 in the hierarchy must be made in one or more alternate 941 repositories. The current repository may be listed. 943 In order to support stronger authentication, the following keywords 944 are added to the ``auth'' attribute: 946 pgp-from The remainder of the attribute gives the string identifying 947 a PGP identity whose public key is held in an external keyring. 948 The use of this method is depricated in favor of the ``pgp-key'' 949 method. 950 pgp-key The remainder of the attribute provides a PGP public key 951 block in ASCII radix-64 format. 953 In order to disable authentication and give permission to anyone, the 954 authentication method ``none'' is added. It has no arguments. 956 An additional change is the ``auth'' attribute is allowed to exist in 957 a ``person'' or ``role'' object. The ``auth'' method ``role'' or 958 ``person'' can be used to refer to a role or person object and take 959 the ``auth'' fields from those objects. Care must be taken in 960 implementations to detect circular references and terminate expansion 961 or the references already visited. 963 A few attributes are added to the schema. These are: 965 mnt-routes The mnt-routes attribute may appear in an aut-num, 966 inetnum, or route object. This attribute references a maintainer 967 object which is used in determining authorization for the addition 968 of inetnum and route objects. If a mnt-routes object is absent, 969 the mnt-by attribute is used for this purpose. The mnt-routes 970 attribute is optional and multiple. the format is identical the 971 the exiting ``mnt-by'' but has an additional optional range 972 preceeding the authorization information. The syntax for the range 973 is the word ``range'' followed by a 974 prefix lists (as defined in RPSL) in curly braces (``{\and \}") asused 975 elsewherein RPSL. 977 reclaim Thereclaim attributemay appearinas-block, aut-num,inetnum, orroute objects. Any 978 objectof thesame typebelow inthe hierarchymay bemodified ordeleted bythe maintainerof 979 theobject containinga reclaimattribute. Thevalue of theattribute isa setor rangeof objects 980 ofthe sametype wherethe syntaxof theset orrange isas definedin RPSL. SeeSection 8.2for 981 restrictionson addingreclaim attributes. 983 no-reclaim Theno-reclaim attribute is usedwith the reclaimattribute. Theno-reclaim at- 984 tributenegates any reclaimattribute it overlaps. See Section8.2 for restrictions ondeleting 985 no-reclaimattributes. 986 delegated Thedelegated attributeisallowed inany objecttype withahierarchy. This attribute 987 indicatesthatfurther searchesfor objectin thehierarchy mustbe madein oneor morealternate 988 repositories.The currentrepository maybe listed. 990 referral-by Thisattribute isrequired inthe maintainer object.It maynever be alteredafter 991 theaddition ofthe maintainer. Thisattribute refers tothe maintainerthat created thismain- 992 tainer.It maybe multiple ifmore thanone signatureappeared onthe transaction creatingthe 993 object. 995 referral-in Thisattribute mayappear in amaintainer object. Itis multiple. Eachtime the 996 maintainerobjectis usedto addanother maintainer,a referral-inreferencingthe newmaintainer 997 isautomatically added. 998 auth-override Anauth-override attributecan beadded, deleted,or changedby a transaction 999 submittedby maintainerlisted inthereferal-by. The auth-overrideattribute itselfcontains only 1000 thedate whenthe attributewill gointo effect whichmust beat least60 days fromthe current 1001 dateunless thereis alreadyauthorization tomodify themaintainer. Afterthe date inthe auth- 1002 overrideis reached, thoseidentified by themaintainer in thereferal-by have authorization to 1003 modifythe maintainer. This attribute existsas a means toclean up should theholder of a 1004 maintainerbecomeunresponsive andcan onlytake effectif thatmaintainer doesnot removethe 1005 auth-overridein responseto theautomatic notificationthat occurson changes. 1007 Each repository must identify itself with a ``repository'' object. 1008 The repository must also contain a special ``repository'' whose key is 1009 ``ROOT''. The root repository is where all non-local queries are 1010 directed, including where hierarchical object queries start. The 1011 query methods listed for the root repository may actually be a subset 1012 of those offered by that repository if efficiency considerations and 1013 topologic distance make some methods less useful. 1015 The root repository must contain a copy of the repository objects in 1016 any repository considered valid. The repository objects will be 1017 essential when the routing registry becomes more widely distributed. 1019 The existing ``mnt-by'' attribute references the ``maintainer'' object 1020 type. The ``mnt-by'' attribute is now mandatory in all object types. 1022 A new maintainer may be added by any existing maintainer. The 1023 ``referral-by'' attribute is now mandatory in the ``maintainer'' 1024 object to keep a record of which maintainer made the addition and can 1025 never be changed. Maintainers cannot be deleted as long as they are 1026 referenced by a ``referral-by'' attribute elsewhere. In order to add 1027 a maintainer to another database, a ``referral-in'' attribute is 1028 needed, containing the name of the external database. A ``referral- 1029 in'' attribute cannot be deleted unless there are no ``referral-by'' 1030 references to the maintainer in the named external databases. 1032 A Technical Discussion 1034 A few design tradeoffs exist. Some of these tradeoffs, the selected 1035 solution, and the alternatives are discussed here. Some of the issues 1036 are listed below. 1038 1. Whether to error on the side of permissiveness and weaken 1039 authorization controls or risk the possibility of erecting barriers 1040 to registering information. 1042 2. Whether to support enforcible address lending or provide the 1043 smaller or end user with ultimate control over the registration of 1044 the prefixes they are using. 1046 3. What to do with older objects that either don't conform to newer 1047 requirements regarding minimum authorization, authentication, and 1048 accountability, or are of questionable validity. 1050 A.1 Relaxing requirements for ease of registry 1052 If the requirement that an aut-num exists is relaxed, then it is 1053 possible for anyone to make use of an unassigned AS number or make use 1054 of an assigned AS number for which the aut-num has not been entered. 1055 Placing requirements on the entry of aut-num presumes cooperation of 1056 the Internet address allocation authority (if separate from the rout- 1057 ing registry). The address allocation authority must be willing to 1058 field requests to populate skeleton aut-nums from the party for which 1059 the allocation has been made. These aut-num must include a reference 1060 to a maintainer. A request to the address allocation authority must 1061 therefore include a reference to an existing maintainer. 1063 The ability to add route objects is also tied to the existence of less 1064 specific route objects or inetnums. The Internet address allocation 1065 authority (if separate from the routing registry) must also be willing 1066 to field requests to add inetnum records for the party already 1067 allocated the address space. 1069 The Internet address allocation authority should also add inetnums and 1070 aut-nums for new allocations. In order to do so, a maintainer must 1071 exist. If a party is going to connect to the Internet, they can get a 1072 maintainer by making a request to the Internet service provider they 1073 will be connecting to. Once they have a maintainer they can make a 1074 request for address space or an AS number. The maintainer can contain 1075 a public key for a cryptographicly strong authorization method or 1076 could contain a ``crypt-key'' or ``mail-to'' authorization check if 1077 that is considered adequate by the registering party. Furthermore an 1078 address allocation authority should verify that the request for an AS 1079 number or for address space matches the authorization criteria in the main- 1080 tainer. 1082 Currently only the registry themselves may add maintainers. This 1083 becomes a problem for the registry particularly verifying public keys. 1084 This requirement is relaxed by allowing existing maintainers to add 1085 maintainers. Unfortunately the accountability trail does not exist 1086 for existing maintainers. The requirement then should be relaxed such 1087 that existing maintainers may remain but only existing maintainers 1088 that have a ``referral-by'' attribute can add maintainers. The 1089 ``referral-by'' and ``referral-in'' cannot be modified. This require- 1090 ment can be relax slightly so that a ``referral-by'' can be added to a 1091 maintainer by an existing maintainer with a ``referral-by''. This 1092 will allow the accountability trail to be added to existing maintainers 1093 and these maintainers can then add new maintainers. 1095 Verifying that a party is who they claim to be on initial addition, is 1096 one of the problems that currently falls upon the AS number and 1097 address registry. This problem is reduced by allowing existing 1098 maintainers to add maintainers. This may actually make it easier to 1099 get maintainers and therefore easier to register. The number 1100 authority still must verify that the AS or address space is actually 1101 needed by the party making a request. 1103 Authorization checks made during the addition of route objects that 1104 refer to AS objects and inetnum strongly rely on the cooperation of 1105 the Internet address allocation authorities. The number authorities 1106 must register as-blocks, aut-nums, or inetnums as AS numbers or ad- 1107 dress space is allocated. If only a subset of the number authorities 1108 cooperate, then either an inetnum or as-block can be created covering 1109 the space that registry allocates and essentially requiring null allo- 1110 cation (for example a ``crypt-pw'' authentication where the password 1111 is given in the remarks in the object or its maintainer) or those ob- 1112 taining addresses from that number authority will have trouble regis- 1113 tering in the routing registry. The authorization model supports either 1114 option, though it would be preferable if the number authorities cooper- 1115 ated and the issue never surfaced in practice. 1117 The maintainer requirements can be relaxed slightly for existing main- 1118 tainers making it easier to register. Relaxing requirements on other 1119 objects may defeat the authorization model, hence is not an option. 1121 A.2 The address lending issue 1123 The issue of whether lending contracts should be enforcible is an 1124 issue of who should ultimately be able to exercise control over allo- 1125 cations of address space. The routing registry would be wise to stay 1126 as neutral as possible with regard to disputes between third parties. 1127 The ``reclaim'' and ``no-reclaim'' are designed to allow either out- 1128 come to the decision as to whether the holder of a less specific inet- 1129 num or route object can exercise control over suballocations in the 1130 registry. The routing registry itself must decide whether to retain 1131 control themselves and if so, should very clearly state under what 1132 conditions the registry would intervene. A registry could even go to 1133 the extreme of stating that they will intervene in such a dispute only af- 1134 ter the dispute has been resolved in court and a court order has been is- 1135 sued. 1137 When an allocation is made by a registry, the registry should keep a 1138 ``reclaim'' attribute in the less specific object and make a strong 1139 policy statement that the reclaim privilege will not be used except 1140 under very clearly defined special circumstances (which at the very 1141 minimum would include a court order). If the allocation is further 1142 subdivided the party subdividing the allocation and the party accept- 1143 ing the suballocation must decide whether a ``reclaim'' can be kept by 1144 the holder of the less specific allocation or whether a ``no-reclaim'' 1145 must be added transferring control to the holder of the more specific. 1146 The registry is not involved in that decision. Different pairs of 1147 third parties may do different decisions regarding the ``reclaim'' and any 1148 contractual restrictions on its use that may be expressed outside of the 1149 registry in the form of a legal contract and ultimately resolved by the 1150 courts in the event of a bitter dispute. 1152 By retaining ``reclaim'' rights the registry retains the ability to 1153 abide by a court order. This may only truly become an issue in a 1154 distributed registry environment where registries will be rechecking 1155 the authorization of transactions made elsewhere and may fail to 1156 process the attempt of another registry to abide by a court order by 1157 overriding normal authorization to change the registry contents if a 1158 reclaim is not present. 1160 A.3 Dealing with non-conformant or questionable older data 1162 Some of the newer requirements include requiring that all objects 1163 reference a maintainer object responsible for the integrity of the 1164 object and requiring accountability for the creation of maintainers to 1165 be recorded in the maintainer objects so that accountability can be 1166 traced back from an unresponsive maintainer. In the event that 1167 contact information is absent or incorrect from objects and there is 1168 any question regarding the validity of the objects, the maintainer can 1169 be contacted. If the maintainer is unresponsive, the maintainer that 1170 authorized the addition of that maintainer can be contacted to either 1171 update the contact information on the maintainer or confirm that the 1172 entity no longer exists or is no longer actively using the Internet or the 1173 registry. 1175 Many route objects exist for which there are no maintainers and for 1176 which inetnum and AS objects do not exist. Some contain the now 1177 obsoleted guardian attribute rather than a mnt-by. 1179 It is not practical to unconditionally purge old data that does not 1180 have maintainers or does not conform to the authorization hierarchy. 1181 New additions must be required to conform to the new requirements 1182 (otherwise the requirements are meaningless). New requirements can be 1183 phased in by requiring modifications to conform to the new 1184 requirements. 1186 A great deal of questionable data exists in the current registry. The 1187 requirement that all objects have maintainers and the requirements for 1188 improved accountability in the maintainers themselves may make it 1189 easier to determine contact information even where the objects are not 1190 updated to reflect contact information changes. 1192 It is not unreasonable to require valid contact information on 1193 existing data. A great deal of data appears to be unused, such as 1194 route objects for which no announcement has been seen in many months 1195 or years. An attempt should be made to contact the listed contacts in 1196 the object, in the maintainer if there is one, then up the maintainer 1197 referral-by chain if there is one, and using the number registry or 1198 origin AS contact information if there is no maintainer accountability 1199 trail to follow. Experience so far indicates that the vast majority 1200 of deletions identified by comparing registered prefixes against route 1201 dumps will be positively confirmed (allowing the deletion) or there 1202 will be no response due to invalid contact information (in many cases the 1203 IRR contact information points to nsfnet-admin@merit.edu). 1205 By allowing the registry to modify (or delete) any objects which are 1206 disconnected from the maintainer accountability trail, cleanup can be 1207 made possible (though mail header forging could in many cases have the 1208 same effect it is preferable to record the fact that the registry 1209 itself made the cleanup). Similarly, a mechanism may be needed in the 1210 future to allow the maintainer in the referral-by to override 1211 maintainer privileges in a referred maintainer if all contacts have 1212 become unresponsive for a maintainer. The referral-by maintainer is 1213 allowed to add an ``auth-override'' attribute which becomes usable as 1214 an ``auth'' within 60 days from the time of addition. The maintainer 1215 themselves would be notified of the change and could remove the ``auth- 1216 override'' attribute before it becomes effective and inquire as to why it 1217 was added and correct whatever problem existed. This can be supported im- 1218 mediately or added later if needed. 1220 B Common Operational Cases 1222 In principle address allocation and route allocation should be 1223 hierarchical with the hierarchy corresponding to the physical 1224 topology. In practice this is often not the case for numerous 1225 reasons. The primary reasons are the topology is not strictly tree 1226 structured and the topology can change. More specificly: 1228 1. The Internet topology is not strictly tree structured. 1230 o At the top level the network more closely resembles a moderately 1231 dense mesh. 1232 o Near the bottom level many attachments to the Internet are 1233 multihomed to more than one Internet provider. 1235 2. The Internet topology can and does change. 1236 o Many attachments switch providers to obtain better service or 1237 terms. 1239 o Service providers may modify adjacencies to obtain better transit 1240 service or terms. 1241 o Service providers may disappear completely scattering attachments 1242 or merge. 1244 Renumbering is viewed as a practical means to maintain a strict 1245 numeric hierarchy [20]. It is also acknowledged that renumbering IPv4 1246 networks can be difficult [20, 3, 21]. We examine first the simple 1247 case where hierarchy still exists. We then examine the operational 1248 cases where either initial topology is not tree structured or cases 1249 where topology changes. 1251 B.1 simple hierarchical address allocation and route allocation 1253 This is the simplest case. Large ranges of inetnums are assigned to 1254 address registries. These registries in turn assign smaller ranges 1255 for direct use or to topologically large entities where allocations 1256 according to topology can reduce the amount of routing information 1257 needed (promote better route aggregation). 1259 AS objects are allocated as topology dictates the need for additional 1260 AS [10]. Route objects can be registered by those with authorization 1261 given by the AS and by the address owner. This is never an issue 1262 where the maintainer of the AS and the inetnum are the same. Where 1263 they differ, either the provider can give permission to add route 1264 objects for their AS, or the party allocated the address space can 1265 give the provider permission to add router objects for their address 1266 space, or both parties can sign the transaction. Permission is 1267 provided by adding to maintainer attributes. 1269 B.2 aggregation and multihomed more specific routes 1271 Aggregation is normally not a problem if a provider is aggregating 1272 address space allocated to the provider and then suballocated 1273 internally and/or to customers. In fact, the provider would be 1274 expected to do so. This is not a problem even if the route object for 1275 the aggregation is added after the more specific route objects since 1276 only less specific objects are considered. 1278 Aggregation is potentially a problem if a provider or a set of 1279 providers plan to aggregate address space that was never explicitly 1280 allocated as a block to those providers but rather remains the 1281 allocation of a address registry. These large aggregations can be 1282 expected to be uncommon, but relatively easily dealt with. 1283 Superaggregates of this type will generally be formed by topologically 1284 close entities who have also managed to draw adjacent address 1285 allocations. In effect, the registry must give permission to form 1286 such as superaggregate by either giving permission to do so in an 1287 inetnum or by signing the submission along with the other parties. 1289 A more common case is where a more specific route object must be 1290 registered with a different AS than the aggregate due to the prefix 1291 being multihomed. In this case, the maintainer of the aggregate can 1292 create a more specific route object with their own AS marked withdrawn 1293 so as not to be routable. The new AS can be included in the 1294 maintainer solely for the purpose of allowing them to create a new 1295 route object with their own AS. Again, alternately both parties can 1296 sign the submission for the addition with the new AS. 1298 B.3 provider independent addresses and multiple origin AS 1300 Provider independent addresses and multihoming arrangement using 1301 multiple origin AS present a similar problem to multihoming. The 1302 maintainer of the address space and the maintainer of the AS is not 1303 the same. Permission can be granted using additions to the maintainer 1304 or multiple signatures can appear on the submission. 1306 B.4 change in Internet service provider 1308 A change in Internet service providers is similar to multihoming. A 1309 minor difference is that the AS for the more specific route will be 1310 the AS of the new provider rather than the AS of the multihomed 1311 customer. A provider may be hesitant to give permissions to their 1312 competitor to make additions with their AS. There is no potential for 1313 harm in giving permission to a withdrawn exact match of the more 1314 specific so the maintainer of the aggregate could more easily in 1315 effect grant permission to the maintainers of the new AS. 1317 B.5 renumbering grace periods 1319 Renumbering grace periods allow a provider who wants to keep an 1320 address allocation intact to allow a customer who has chosen to go to 1321 another provider to renumber their network gradually and then return 1322 the address space after renumbering is completed. The issue of 1323 whether to require immediate renumbering or offer renumbering grace 1324 periods and how long they should be or whether they should be 1325 indefinite has been topic of bitter disputes. The authorization model 1326 can support no renumbering grace period, a finite renumbering grace 1327 period, or an indefinite renumbering grace period. The ``reclaim'' 1328 attribute described in Section 8.1 provides a means to end the grace 1329 period. 1331 C Deployment Considerations 1333 This section describes deployment considerations. The intention is to 1334 raise issues and discuss approaches rather than to provide a 1335 deployment plan. 1337 The use of routing registries is not yet universally accepted. There 1338 still remain Internet providers who see no reason to provide the added 1339 assurance of accurate routing information described in Section 5. 1340 More accurately, these benefits are viewed as being insufficient to 1341 justify the cost. This has been largely caused an inability of a very 1342 major router vendor up until recently to handle prefix lists of the 1343 size needed to specify routing policy on a per prefix basis. Another 1344 reason cited is that filtering on a prefix basis in an environment 1345 where routing registry is incomplete or inaccurate can interfere with 1346 connectivity. 1348 There clearly is a critical mass issue with regard to the use of 1349 routing registries. A minority of providers use the existing IRR to 1350 filter on a per prefix basis. Another minority of providers do not 1351 support the IRR and generally fail to register prefixes until 1352 connectivity problems are reported. The majority of providers 1353 register prefixes but do not implement strict prefix filtering. 1355 Deploying new authentication mechanisms has no adverse consequences. 1357 This has been proven with Merit's deployment of PGP. 1359 In deploying new authorization mechanisms, a major issue is dealing 1360 with existing data of very questionable origin. A very large number 1361 of route objects refer to prefixes that have not been announced for 1362 many years. Other route objects refer to prefixes that are no longer 1363 announced with the origin AS that they are register with (some were 1364 incorrectly registered to start with). There are many causes for 1365 this. 1367 1. During the transition from the NSFNET PRDB to the RADB a large 1368 number of prefixes were registered with an origin AS corresponding 1369 to the border AS at which the NSFNET had once heard the route 1370 announcements. The PRDB did not support origin AS, so border AS 1371 was used. Many of these routes were no longer in use at the time 1372 and are now routed with a submitter listed as 1373 ``nsfnet-admin@merit.edu''. 1375 2. As CIDR was deployed, aggregates replaced previously separately 1376 announced more specific prefixes. The route objects for the more 1377 specific prefixes were never withdrawn from the routing registries. 1378 3. Some prefixes are simply no longer in use. Some networks have been 1379 renumbered. Some network no longer exist. Often the routing 1380 registry information is not withdrawn. 1382 4. As provider AS adjacencies changed and as end customers switched 1383 providers often the actual origin AS changed. This was often not 1384 reflected by a change in the routing registry. 1386 Inaccuracies will continue to occur due to the reasons above, except 1387 the first. The hierarchical authorization provides greater 1388 accountability. In the event that the contacts for specific objects 1389 become unresponsive traversal up the authorization hierarchy should 1390 help identify the parties having previous provided authorization. 1391 These contacts may still have sufficient authorization to perform the 1392 necessary cleanup. This issue is discussed in Section A. 1394 A great deal of information is currently missing in the IRR. Quite a 1395 few AS have no aut-num. Quite a lot of data has no maintainer and the 1396 vast majority of maintainers use only the weakest of authentication 1397 methods. Very little can be done by the registries to correct this. 1398 The defaults in the cases of missing objects needed for authorization 1399 has to be to make no authentication checks at all. 1401 The transition can be staged as follows: 1403 1. Add and make use of stronger authorization models. 1405 2. Make schema modifications necessary to support delegations. 1407 3. Add delegation objects needed for query traversal. 1409 4. Base query traversal on delegations rather than search of all known 1410 registries. 1411 5. Obtain the cooperation of the address registries for the purpose of 1412 populating the ``inetnum'' entries on an ongoing basis. 1414 6. Add hierarchical authorization support for critical object types, 1415 ``aut-num'', ``inetnum'' and ``route''. 1417 7. Add the requirement that database object either be in use or have 1418 valid contact information and if queries are made by the registry a 1419 response from a contact indicating that the object serves a purpose 1420 if it is not clear what its use is. 1421 8. Begin to purge data which is clearly not in use and for which there 1422 is no valid contact information or no response from the contacts. 1424 Deployment of hierarchical authorization requires cooperation among 1425 the existing routing registries. New code will have to be deployed. 1426 In some cases very little development resources are available and 1427 substantial inertia exists due to the reliance on the current 1428 repository and the need to avoid disruption. 1430 If hierarchical authorization of route objects depends on the 1431 existence of address registration information, minimal cooperation of 1432 the currently separate address registries is required. The extent of 1433 the cooperation amounts to sending cryptographically signed 1434 transactions from the address registry to the number registry as 1435 address allocations are made or providing equivalent access to new 1436 address allocations. 1438 Currently most registries returns query results from all of the known 1439 repositories using their mirrored copies. Cross registry 1440 authorizations are not yet implemented. Minimal schema changes have 1441 to be made to support the ability to delegate objects for which there 1442 is an authorization hierarchy and the support queries and references 1443 to other repositories. In the case of AS delegations, ``as-block'' 1444 need to be created solely for the purpose of traversal. 1446 Acknowledgments 1448 This document draws ideas from numerous discussions and contributions 1449 of the IETF Routing Policy System Work Group and RIPE Routing Work 1450 Group. 1452 References 1454 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 1455 M. Terpstra, and C. Villamizar. Routing policy specification 1456 language (rpsl). Technical Report RFC 2280, Internet Engineering 1457 Task Force, 1998. ftp://ds.internic.net/rfc/rfc2280.txt. 1458 [2] T. Bates, E. Gerich, L. Joncheray, J-M. 1459 Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation 1460 of ip routing policies in a routing reg- 1461 istry (ripe-81++). Technical Report RFC 1786, Internet Engineer- 1462 ing Task Force, 1995. ftp://ds.internic.net/rfc/rfc1786.txt. 1464 [3] H. Berkowitz. Router 1465 renumbering guide. Technical Report RFC 2072, Internet Engineer- 1466 ing Task Force, 1997. ftp://ds.internic.net/rfc/rfc2072.txt. 1468 [4] H.W. Braun. Models of policy based routing. Technical Report RFC 1469 1104, Internet Engineering Task Force, 1989. 1470 ftp://ds.internic.net/rfc/rfc1104.txt. 1471 [5] H.W. Braun and Y. Rekhter. Advancing the nsfnet routing ar- 1472 chitecture. Technical Report RFC 1222, Internet Engineering Task 1473 Force, 1991. ftp://ds.internic.net/rfc/rfc1222.txt. 1475 [6] D.D. Clark. Policy routing in internet protocols. Technical Re- 1476 port RFC 1102, Internet Engineering Task Force, 1989. 1477 ftp://ds.internic.net/rfc/rfc1102.txt. 1479 [7] D. Crocker. Standard for the format of arpa 1480 internet text messages. Technical Report RFC 822, Internet Engi- 1481 neering Task Force, 1982. ftp://ds.internic.net/rfc/rfc822.txt. 1482 [8] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless inter-domain 1483 routing (cidr): an address assignment and aggregation strat- 1484 egy. Technical Report RFC 1519, Internet Engineering Task Force, 1485 1993. ftp://ds.internic.net/rfc/rfc1519.txt. 1487 [9] Internet Engineering Steering Group and R. Hinden. Applicability 1488 statement for the implementation of classless inter-domain rout- 1489 ing (cidr). Technical Report RFC 1517, Internet Engineering Task 1490 Force, 1993. ftp://ds.internic.net/rfc/rfc1517.txt. 1492 [10] J. Hawkinson and T. Bates. Guidelines for creation, selection, 1493 and registration of an autonomous system (as). Technical Report 1494 RFC 1930, Internet Engineering Task Force, 1996. 1495 ftp://ds.internic.net/rfc/rfc1930.txt. 1496 [11] K. Hubbard, M. Kosters, D. Con- 1497 rad, D. Karrenberg, and J. Postel. Internet registry ip alloca- 1498 tion guidelines. Technical Report RFC 2050, Internet Engineering 1499 Task Force, 1996. ftp://ds.internic.net/rfc/rfc2050.txt. 1501 [12] David Kessens and Carol Or- 1502 ange. Ripe-181 to rpsl transition plan. Internet Draft (Work in 1503 Progress) draft-ietf-rps-transition-02, Internet 1504 Engineering Task Force, 11 1997. ftp://ds.internic.net/internet- 1505 drafts/draft-ietf-rps-transition-02.txt. 1507 [13] Mark Knopper and Steven J. 1508 Richardson. Aggregation support in the nsfnet policy-based rout- 1509 ing database. Technical Report RFC 1482, Internet Engineering 1510 Task Force, 1993. ftp://ds.internic.net/rfc/rfc1482.txt. 1512 [14] David Meyer, Cengiz Alaettinoglu, and David 1513 Kessens. Guidelines for extending rpsl. Internet Draft (Work in 1514 Progress) draft-ietf-rps-extending-00, Internet 1515 Engineering Task Force, 11 1997. ftp://ds.internic.net/internet- 1516 drafts/draft-ietf-rps-extending-00.txt. 1517 [15] David Meyer, Cengiz Alaettinoglu, and J. Schmitz. Application of 1518 routing policy specification language (rpsl) on the 1519 internet. Internet Draft (Work in Progress) draft-ietf-rps-appl- 1520 rpsl-01, Internet Engineering Task Force, 7 1521 1997. ftp://ds.internic.net/internet-drafts/draft-ietf-rps-appl- 1522 rpsl-01.txt. 1524 [16] National Institute of Standards and Technology. The digital sig- 1525 nature standard, proposal and discussion. Communications of the 1526 ACM, 35(7):36--54, July 1992. 1528 [17] National Institute of Standards and Technology (NIST). Fips pub- 1529 lication 186: Digital signature standard (dss). Technical re- 1530 port, Gaithersburg, MD, May 1994. 1531 [18] Y. Rekhter. Routing in a multi-provider internet. Technical Re- 1532 port RFC 1787, Internet Engineering Task Force, 1995. 1533 ftp://ds.internic.net/rfc/rfc1787.txt. 1535 [19] Y. Rekhter and T. Li. An architecture for ip address allocation 1536 with cidr. Technical Report RFC 1518, Internet Engineering Task 1537 Force, 1993. ftp://ds.internic.net/rfc/rfc1518.txt. 1539 [20] Y. Rekhter and T. Li. Implications of various address allocation 1540 policies for internet routing. Technical Report RFC 2008, Inter- 1541 net Engineering Task Force, 1996. 1542 ftp://ds.internic.net/rfc/rfc2008.txt. 1543 [21] Y. Rekhter, P. Lothberg, R. Hinden, S. Deer- 1544 ing, and J. Postel. An ipv6 provider-based unicast address for- 1545 mat. Technical Report RFC 2073, Internet Engineering Task Force, 1546 1997. ftp://ds.internic.net/rfc/rfc2073.txt. 1548 [22] Bruce Schneier. Applied Cryptography. Wiley, New York, 1996. 1550 Security Considerations 1552 @@ This entire document is about security but at some point we need to 1553 figure out what belongs here in this case. Maybe the Area Directors 1554 can provide some advice. 1556 Author's Addresses 1558 Curtis Villamizar 1559 ANS Communications 1560 1562 Cengiz Alaettinoglu 1563 ISI 1564 1566 David M. Meyer 1567 University of Oregon 1568 1570 Sandy Murphy 1571 Trusted Information Systems 1572 1574 Carol Orange 1575 RIPE NCC 1576