idnits 2.17.1 draft-ietf-rps-auth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** 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-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 848 has weird spacing: '... key manda...' == Line 849 has weird spacing: '...ptional mult...' == Line 850 has weird spacing: '...ptional mult...' == Line 851 has weird spacing: '...ndatory multi...' == Line 852 has weird spacing: '...ndatory multi...' == (4 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 (February 23, 1999) is 9187 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 1398, 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) ** Downref: Normative reference to an Historic RFC: RFC 1482 (ref. '12') == Outdated reference: A later version (-06) exists of draft-ietf-rps-appl-rpsl-03 ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '13') == Outdated reference: A later version (-06) exists of draft-ietf-rps-dist-00 -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '17') ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '18') ** Obsolete normative reference: RFC 2073 (ref. '20') (Obsoleted by RFC 2374) -- Possible downref: Non-RFC (?) normative reference: ref. '21' == Outdated reference: A later version (-02) exists of draft-ietf-rps-dbsec-pgp-authent-00 Summary: 22 errors (**), 0 flaws (~~), 12 warnings (==), 5 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 UUNET 4 draft-ietf-rps-auth-02 Cengiz Alaettinoglu 5 ISI 6 David M. Meyer 7 Cisco 8 Sandy Murphy 9 TIS 10 February 23, 1999 12 Routing Policy System Security 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute 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 mate- 26 rial or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright (C) The Internet Society (February 23, 1999). All Rights 35 Reserved. 37 Abstract 39 The RIPE database specifications [2] and RPSL language [1] define lan- 40 guages used as the basis for representing information in a routing 41 policy system. A repository for routing policy system information is 42 known as a routing registry. A routing registry provides a means of 43 exchanging information needed to address many issues on importance to 44 the operation of the Internet. The implementation and deployment of 45 a routing policy system must maintain some degree of integrity to be 46 of any operational use. This document addresses the need to assure 47 integrity of the data by providing an authentication and authorization 48 model. 50 1 Overview 52 The Internet Routing Registry (IRR) has evolved to meet a need for 53 Internet-wide coordination. This need was described in RFC-1787, an 54 informational RFC prepared on behalf of the IAB [17]. The following 55 summary appears in Section 7 of RFC-1787. 57 While ensuring Internet-wide coordination may be more and more 58 difficult, as the Internet continues to grow, stability and con- 59 sistency of the Internet-wide routing could significantly benefit 60 if the information about routing requirements of various organi- 61 zations could be shared across organizational boundaries. Such 62 information could be used in a wide variety of situations ranging 63 from troubleshooting to detecting and eliminating conflicting 64 routing requirements. The scale of the Internet implies that the 65 information should be distributed. Work is currently underway to 66 establish depositories of this information (Routing Registries), 67 as well as to develop tools that analyze, as well as utilize this 68 information. 70 A routing registry must maintain some degree of integrity to be of 71 any use. The degree of integrity required depends on the usage of the 72 routing policy system. 74 An initial intended usage of routing policy systems such as the RIPE 75 database had been in an advisory capacity, documenting the intended 76 routing policies for the purpose of debugging. In this role a very 77 weak form of authentication was deemed sufficient. 79 The IRR is increasingly used for purposes that have a stronger re- 80 quirement for data integrity and security. This document addresses 81 issues of data integrity and security that is consistent with the 82 usage of the IRR and which avoids compromising data integrity and se- 83 curity even if the IRR is distributed among less trusted repositories. 85 2 Background 87 An early routing policy system used in the T3--NSFNET, the policy 88 routing database (PRDB), provided a means of determining who was au- 89 thorized to announce specific prefixes to the NSFNET backbone. The 90 need for a policy database was recognized as far back as 1989 [6, 4]. 91 By 1991 the database was in place [5]. Authentication was accom- 92 plished by requiring confirmation and was a manually intensive pro- 93 cess. This solved the problem for the NSFNET, but was oriented toward 94 holding the routing policy of a single organization. 96 The problem since has become more difficult. New requirements have 97 emerged. 99 1. There is a need to represent the routing policies of many organiza- 100 tions. 102 2. CIDR and overlapping prefixes and the increasing complexity of 103 routing policies and the needs of aggregation have introduced new 104 requirements. 105 3. There is a need to assure integrity of the data and delegate au- 106 thority for the data representing specifically allocated resources 107 to multiple persons or organizations. 109 4. There is a need to assure integrity of the data and distribute the 110 storage of data subsets to multiple repositories. 112 The RIPE effort specificly focused on the first issue [2]. Its prede- 113 cessor, the PRDB, addressed the needs of a single organization, while 114 the RIPE database was initially intended to address the needs of the 115 European Internet community. The RIPE database formats as described 116 in [2] were the basis of the original IRR. 118 Routing protocols themselves provide no assurance that the origination 119 of a route is legitimate and can actually reach the stated destina- 120 tion. The nature of CIDR allows more specific prefixes to override 121 less specific prefixes [9, 18, 8]. Even with signed route origina- 122 tion, there is no way to determine if a more specific prefix is legit- 123 imate and should override a less specific route announcement without a 124 means of determining who is authorized to announce specific prefixes. 125 Failing to do so places no assurance of integrity of global routing 126 information and leaves an opportunity for a very effective form of 127 denial of service attack. 129 The Routing Policy System Language (RPSL) [1, 13] was a fairly sub- 130 stantial evolutionary step in the data representation which was 131 largely targeted at addressing the second group of needs. The PRDB 132 accommodated CIDR in 1993 [12] and the RIPE database accommodated the 133 entry of CIDR prefixes from inception, but RPSL provides many needed 134 improvements including explicit support for aggregation. 136 This document addresses the third group of needs identified above. 138 While the current implementation supporting weak authentication 139 doesn't guarantee integrity of the data, it does provide extensive 140 mechanisms to make sure that all involved parties get notified when 141 a change is made to the database, whether the change was malicious 142 or intended. This provides inadequate protection against additions. 143 Since the software is increasingly used to configure the major parts 144 of the Internet infrastructure, it is not considered to be adequate 145 anymore to know about and have the ability roll back unintended 146 changes. Therefore, more active security mechanism need to be de- 147 veloped to prevent such problems before they happen. 149 A separate document addresses the fourth group of needs [14]. 151 3 Implicit Policy Assumptions 153 The authorization model encodes certain policies for allocation of 154 address numbers, AS numbers, and for the announcement of routes. Im- 155 plicit to the authorization model are a very limited number of policy 156 assumptions. 158 1. Address numbers are allocated hierarchically. The IANA delegates 159 portions of the address space to the regional registries (currently 160 ARIN, APNIC and RIPE), which in turn delegate address space to 161 their members, who can assign addresses to their customers. 163 2. AS numbers are allocated either singly or in small blocks by reg- 164 istries. Registries are allocated blocks of AS numbers, thereby 165 making the allocation hierarchical. 167 3. Routes should only be announced with the consent of the holder of 168 the origin AS number of the announcement and with the consent of 169 the holder of the address space. 170 4. AS numbers and IP address registries may be different entities from 171 routing registries. 173 For subsets of any of these three allocation spaces, network ad- 174 dresses, AS numbers, and routes, these restrictions may be loosened 175 or disabled by specifying a very weak authorization method or an 176 authentication method of ``none''. However, even when no authenti- 177 cation mechanism is used, all involved parties can be notified about 178 the changes that occurred through use of the existing ``notify'' at- 179 tribute. 181 4 Organization of this Document 183 Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this 184 document. Goals are described in Section 5. Section 6 through Sec- 185 tion 8 provide descriptions of the changes and discussion. Section 9 186 provides a concise summary of data formats and semantics. Appendix A 187 through Appendix C provide additional technical discussion, examples, 188 and deployment considerations. 190 Goals and Requirements Section 5 provides a more detailed descrip- 191 tion of the issues and identifies specific problems that need to 192 be solved, some of which require a degree of cooperation in the 193 Internet community. 195 Data Representation Section 6 provides some characteristics of RPSL 196 and formats for external representations of information. 198 Authentication Model Section 7 describes current practice, proposes 199 additional authentication methods, and describes the extension 200 mechanism if additional methods are needed in the future. 202 Authorization Model Section 8 describes the means of determining 203 whether a transaction contains the authorization needed to add, 204 modify, or delete specific data objects, based on stated authenti- 205 cation requirements in related data objects. 207 Data Format Summaries Section 9 provides a concise reference to the 208 data formats and steps in transaction processing. 210 Technical Discussion Section A contains some discussion of techni- 211 cal tradeoffs. 213 Common Operational Cases Section B provides some examples drawn 214 from past operational experience with the IRR. 216 Deployment Considerations Section C describes some deployment is- 217 sues and discusses possible means of resolution. 219 5 Goals and Requirements 221 The Internet is an open network. This openness and the large scale of 222 the Internet can present operational problems. Technical weaknesses 223 that allow misconfiguration or errant operation in part of the network 224 to propagate globally or which provide potentials for simple denial 225 of service attacks should be eliminated to the extent that it is prac- 226 tical. The integrity of routing information is critical in assuring 227 that traffic goes where it is supposed to. 229 An accidental misconfiguration can direct traffic toward routers that 230 cannot reach a destination for which they are advertising reachabil- 231 ity. This is commonly caused by misconfigured static routes though 232 there are numerous other potential causes. Static routes are often 233 used to provide constant apparent reachability to single homed desti- 234 nations. Some of the largest ISPs literally have thousands of static 235 routes in their networks. These are often entered manually by op- 236 erators. Mistyping can divert traffic from a completely unrelated 237 destination to a router with no actual reachability to the advertised 238 destination. This can happen and does happen somewhat regularly. In 239 addition, implementation bugs or severe misconfigurations that result 240 in the loss of BGP AS path information or alteration of prefix length 241 can result in the advertisement of large sets of routes. Though con- 242 siderably more rare, on a few occasions where this has occurred the 243 results were catastrophic. 245 Where there is the potential for an accidental misconfiguration in 246 a remote part of the Internet affecting the global Internet there is 247 also the potential for malice. For example, it has been demonstrated 248 by accident that multiple hour outages at a major institution can be 249 caused by a laptop and a dial account if proper precautions are not 250 taken. The dial account need not be with the same provider used by 251 the major institution. 253 The potential for error is increased by the CIDR preference for more 254 specific routes [8]. If an institution advertises a single route of 255 a given length and a distant router advertises a more specific router 256 covering critical hosts, the more specific route, if accepted at all, 257 is preferred regardless of administrative weighting or any routing 258 protocol attributes. 260 There is a need to provide some form of checks on whether a route ad- 261 vertisement is valid. Today checks are typically made against the 262 border AS advertising the route. This prevents accepting routes from 263 the set of border AS that could not be legitimately advertise the 264 route. Theses checks rely on the use of information registered in 265 the IRR to generate lists of prefixes that could be advertised by a 266 specific border AS. Checks can also be made against the origin AS. If 267 policy information were sufficiently populated, checks could be made 268 against the entire AS path, but this is not yet feasible. 270 The use of a routing registry can also make it more difficult for pre- 271 fixes to be used without authorization such as unallocated prefixes or 272 prefixes allocated to another party. 274 In summary, some of the problems being addressed are: 276 o Localizing the impact of accidental misconfiguration made by Inter- 277 net Providers to that provider's networks only. 279 o Eliminating the potential for an Internet provider's customer to 280 use malicious misconfiguration of routing as a denial of service 281 attack if the provider router filters their customers and local- 282 izing the denial of service to that Internet provider only if the 283 immediate Internet service provider does not route filter their 284 customers but other providers route filter the route exchange at 285 the inter-provider peering. 286 o Eliminating the unauthorized use of address space. 288 If the data within a routing registry is critical, then the ability 289 to change the data must be controlled. Centralized authorities can 290 provide control but centralization can lead to scaling problems (and 291 is politically distasteful). 293 Address allocation and name allocation is already delegated. Since 294 delegation can be to outside registries it is at least somewhat dis- 295 tributed [11]. Autonomous System (AS) numbers are allocated by the 296 same authorities. It makes sense to delegate the routing number space 297 in a manner similar to the address allocation and AS number alloca- 298 tion. The need for this delegation of authority to numerous reg- 299 istries increases the difficulty of maintaining the integrity of the 300 body of information as a whole. 302 As a first step, the database can be somewhat centrally administered 303 with authority granted to many parties to change the information. 304 This is the case with the current IRR. There are a very small number 305 of well trusted repositories and a very large number of parties au- 306 thorized to make changes. Control must be exercised over who can make 307 changes and what changes they can make. The distinction of who vs 308 what separates authentication from authorization. 310 o Authentication is the means to determine who is attempting to make 311 a change. 313 o Authorization is the determination of whether a transaction pass- 314 ing a specific authentication check is allowed to perform a given 315 operation. 317 Different portions of the database will require different methods of 318 authentication. Some applications will require authentication based 319 on strong encryption. In other cases software supporting strong en- 320 cryption may not be necessary or may not be legally available. For 321 this reason multiple authentication methods must be supported, se- 322 lected on a per object basis. The authentication methods may range 323 from very weak data integrity checks to cryptographicly strong sig- 324 natures. The authorization model must insure that the use of weak 325 integrity checks in parts of the database does not compromise the 326 overall integrity of the database. 328 Additional requirements are placed on the authorization model if the 329 database is widely distributed with delegations made to parties that 330 may not be trustworthy or whose security practices may be lacking. 331 This problem must be addressed in the authorization model in order to 332 enable later evolution to a more distributed routing registry. 334 Autonomous system numbers can be delegated in blocks and subdelegated 335 as needed and then individual AS numbers assigned. Address alloca- 336 tion is a simple numeric hierarchy. Route allocation is somewhat 337 more complicated. The key attributes in a route object (key with re- 338 gard to making it unique) contains both an address prefix and an AS 339 number, known as the origin AS. The addition of a route object must 340 be validated against both the authorization criteria for the AS and 341 the address prefix. Route objects may exist for the same prefix with 342 multiple origin AS values due to a common multihoming practice that 343 does not require a unique origin AS. There is often no correlation be- 344 tween the origin AS of a prefix and the origin AS of overlapping more 345 specific prefixes. 347 There are numerous operational cases that must be accommodated. Some 348 of the more common are listed below. These are explored in greater 349 detail in Appendix B with discussion of technical tradeoffs in Ap- 350 pendix A. 352 o simple hierarchical address allocation and route allocation 354 o aggregation and multihomed more specific routes 355 o provider independent addresses and multiple origin AS 357 o changing Internet service providers 358 o renumbering grace periods 360 The authorization model must accommodate a variety of policies regard- 361 ing the allocation of address space and cannot mandate the use of any 362 one model. There is no standardization of address allocation policies 363 though guidelines do exist [11, 19]. Whether authorization allows the 364 recovery of address space must be selectable on a per object basis and 365 may differ in parts of the database. This issue is discussed further 366 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 authen- 378 tication and authorization mechanisms. These additions are very few 379 and are described in Section 7 and Section 8. 381 Some form of encapsulation must be used to exchange data. The de- 382 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. The encapsulation of registry 394 transaction submissions and exchanges between registries is covered in 395 [14]. 397 7 Authentication Model 399 The maintainer objects serve as a container to hold authentication 400 filters. A reference to a maintainer within another object defines 401 authorization to perform operations on the object or on a set of re- 402 lated objects. The maintainer is typically referenced by name in mnt- 403 by attributes of objects. Further details on the use of maintainers 404 are provided in Section 8.1. 406 The maintainer contains one or more ``auth'' attributes. Each 407 ``auth'' attribute begins with a keyword identifying the authenti- 408 cation method followed by the authentication information needed to 409 enforce that method. The PGPKEY method is slightly syntactically 410 different in that the method PGPKEY is a substring. 412 Authentication methods currently supported include the following. 413 Note that pgp-from is being replaced by the pgpkey (see Section 9 and 414 [22]). 416 mail-from This is a very weak authentication check and is discour- 417 aged. The authentication information is a regular expression over 418 ASCII characters. The maintainer is authenticated if the from or 419 reply-to fields in RFC-822 mail headers are matched by this regular 420 expression. Since mail forgery is quite easy, this is a very weak 421 form of authentication. 423 crypt-pw This is another weak form of authentication. The authenti- 424 cation information is a fixed encrypted password in UNIX crypt for- 425 mat. The maintainer is authenticated if the transaction contains 426 the clear text password of the maintainer. Since the password 427 is in clear text in transactions, it can be captured by snooping. 428 Since the encrypted form of the password is exposed, it is subject 429 to password guessing attacks. 431 pgp-from This format is being replaced by the ``pgpkey'' so that the 432 public key certificate will be available to remote repositories. 433 This is Merit's PGP extension. The authentication information 434 is a signature identity pointing to an external public key ring. 435 The maintainer is authenticated if the transaction (currently PGP 436 signed portion of a mail message) is signed by the corresponding 437 private key. 438 pgpkey This keyword takes the form ``PGPKEY-hhhh'', where ``hhhh'' is 439 the hex representation of the four bytes id of the PGP public key 440 used for authentication. The public key certificate is stored in a 441 separate object as described in [22]. 443 Repositories may elect to disallow the addition of ``auth'' attributes 444 specifying weaker forms of authentication and/or disallow their use 445 in local transaction submissions. Repositories are encouraged to dis- 446 allow the addition of ``auth'' attributes with the deprecated ``pgp- 447 from'' method. 449 Any digital signature technique can be used for authentication. 450 Transactions should be signed using multiple digital signature tech- 451 niques to allow repositories or mirrors that only use a subset of the 452 techniques to verify at least one of the signatures. Any digital sig- 453 nature techniques would be applicable. One that may be supported in 454 the in the future is DSA [15, 16]. Numerous digital signature algo- 455 rithms are described in [21]. 457 8 Authorization Model 459 The authorization model must accommodate the requirements outlined 460 in Section 5. A key feature of the authorization model is the recog- 461 nition that authorization for the addition of certain types of data 462 objects must be derived from related data objects. 464 With multiple repositories, objects not found in RPSL are needed to 465 control AS delegations and new attributes are needed in existing ob- 466 jects to control subdelegation. Objects are also needed to provide 467 query information for other repositories. 469 8.1 Maintainer Objects 471 The maintainer objects serve as a container to hold authentication 472 filters. The authentication methods are described in Section 7. The 473 maintainer can be referenced by name in other objects, most notably in 474 the mnt-by attributes of those objects. 476 Maintainers themselves contain mnt-by attributes. In some cases the 477 mnt-by in a maintainer will reference the maintainer itself. In this 478 case, authorization to modify the maintainer is provided to a (usu- 479 ally very limited) set of identities. A good practice is to create 480 a maintainer containing a long list of identities authorized to make 481 specific types of changes but have the maintainer's mnt-by attribute 482 reference a far more restrictive maintainer more tightly controlling 483 changes to the maintainer object itself. 485 The mnt-by attribute is mandatory in all objects. Some data already 486 exists without mnt-by attributes. A missing mnt-by attribute is in- 487 terpreted as the absence of any control over changes. This is highly 488 inadvisable and most repositories will no longer allow this. 490 The ``mnt-routes'' attribute are needed to reference maintainer ob- 491 jects to provide specific permissions related to the object. This is 492 an extensions to RPSL and RIPE-181 proposed in this document and are 493 described in detail in Section 9. 495 A mnt-routes attribute in an aut-num object allows addition of route 496 objects with that AS number as the origin to the maintainers listed. 497 A mnt-routes attribute in an inetnum object allows addition of route 498 objects with exact matching or more specific prefixes. A mnt-routes 499 attribute in a route object allows addition of route objects with ex- 500 act matching or more specific prefixes. A mnt-routes attribute does 501 not allow changes to the aut-num, inetnum, or route object where they 502 appear. A mnt-routes may optionally be constrained to only apply to a 503 subset of more specific routes. 505 8.2 as-block and aut-num objects 507 An ``as-block'' object is needed to delegate a range of AS numbers to 508 a given repository. This is needed for authorization and it is needed 509 to avoid having to make an exhaustive search of all repositories to 510 find a specific AS. This search would not be a problem now but would 511 be if a more distributed routing repository is used [14]. 513 The ``as-block'' object also makes it possible to separate AS number 514 allocation from registration of AS routing policy. 516 as-block: AS1321 - AS1335 517 ... 519 The ``aut-num'' describes the routing policy for an AS and is criti- 520 cal for router configuration of that AS and for analysis performed by 521 another AS. For the purpose of this document it is sufficient to con- 522 sider the aut-num solely as a place holder identifying the existence 523 of an AS and providing a means to associate authorization with that AS 524 for the purpose of adding ``route'' objects. 526 The ``as-block'' object is proposed here solely as a means of record- 527 ing the delegation of blocks of AS numbers to alternate registries and 528 in doing so providing a means to direct queries and a means to support 529 hierarchical authorization across multiple repositories. 531 8.3 inetnum objects 533 A delegation attribute is needed in the inetnum and route object. 534 This will accommodate the delegation of address space from IANA to 535 regional IP registries. When the routing registry becomes more widely 536 distributed a delegation attribute is needed to support any subdelega- 537 tions to more localized registries or delegations to Internet provider 538 operated registries or organizations who may prefer to run their own 539 routing registry. The delegation attribute for an inetnum or a route 540 object can be multi-valued and refers to all registries in which more 541 specific route objects can be found. 543 inetnum: 193.0.0.0 - 193.0.0.255 544 ... 545 source: IANA 547 The ``inetnum'' exists to support address allocation. For external 548 number registries, such as those using ``[r]whoisd[++]'' the ``inet- 549 num'' can serve as a secondary record that is added when an address 550 allocation is made in the authoritative database. Such records could 551 be added by a address registry such as ARIN as a courtesy to the cor- 552 responding routing registry. 554 8.4 route objects 556 Currently there are a quite few route objects in more than one reg- 557 istry. Quite a few are registered with origin AS for which they have 558 never been announced. There is a legitimate reason to be in more than 559 one origin AS. 561 The ``route'' object is used to record routes which may appear in the 562 global routing table. Explicit support for aggregation is provided. 563 Route objects exist both for the configuration of routing information 564 filters used to contain incidents of erroneous route announcements 565 (Section 5) and to support network problem diagnosis. 567 8.5 reclaim and no-reclaim attributes 569 A reclaim attribute is needed in as-block, inetnum and route objects. 570 The reclaim attribute allows a control to be retained over more spe- 571 cific AS, address or route space by allowing modify and delete privi- 572 leges regardless of the mnt-by in the object itself. 574 The reclaim and no-reclaim attributes contain contain lists of ob- 575 jects subject to the reclaim and no-reclaim. See Section 9 for a full 576 description of the reclaim and no-reclaim attributes. 578 The reclaim attribute provides the means to enforce address lending. 579 It allows cleanup in cases where entities cease to exist or as a last 580 resort means to correct errors such as parties locking themselves 581 out of access to their own objects. To allow finer control a set of 582 prefixes can be specified. 584 A no-reclaim attribute can be used to provide explicit exceptions. A 585 reclaim attribute can only be added to an existing object if the ad- 586 dition of the reclaim attribute does not remove autonomy of existing 587 more specific objects that are covered by the new reclaim attribute. 589 1. A reclaim attribute can be added to an existing object if there are 590 no existing exact matches or more specific objects overlapped by 591 the new reclaim attribute, or 593 2. if the submitter is listed in the maintainer pointed to be the mnt- 594 by of the objects which are overlapped, or 596 3. if any overlapped object is listed in a no-reclaim attribute in the 597 object where the reclaim is being added. 599 Similarly a no-reclaim attribute cannot be deleted unless there are 600 no overlapped objects for which the submitter is not listed in the 601 maintainer pointed to be the mnt-by of the overlapped object. 603 If neither a reclaim or no-reclaim attribute is present, then more 604 specific objects of a given object cannot be modified by the main- 605 tainer of the less specified object unless the maintainer is also 606 listed as a maintainer in the more specific object. 608 8.6 Other Objects 610 Many of the RPSL ancillary objects have no natural hierarchy the way 611 AS numbers, Internet addresses and routes have a numeric hierarchy. 612 Some examples are ``maintainers'', ``people'' and ``role'' objects. 613 For these objects, lack of any hierarchy leads to two problems. 615 1. There is no hierarchy that can be exploited to direct queries to 616 alternate registries. At some point the query strategy of search- 617 ing all known registries becomes impractical. 618 2. There is no hierarchy on which authorizations of additions can be 619 based. 621 The first problem can be addressed by considering the name space 622 for each of the ancillary objects to be unique only within the lo- 623 cal database and to use explicit references to an external repository 624 where needed. The object key is preceded by the name of the reposi- 625 tory and the delimiter ``::''. For example a NIC handle may take the 626 form ``RIPE::CO19''. Currently there is a desire to keep NIC handles 627 unique so the naming convention of appending a dash and the reposi- 628 tory name is used. Prepending the repository name provides the unique 629 name space since an object in the RIPE database referencing ``CO19'' 630 would be interpreted as ``RIPE::CO19'' by default, but it would still 631 be possible to query or reference ``IANA::CO19''. There is no pos- 632 sibility of accidentally forgetting to adhere to the conventions when 633 making an addition and the existing objects are accommodated, includ- 634 ing cases where name conflicts have already occurred. 636 The second problem can be partially addressed by using a referral 637 system for the addition of maintainers and requiring that any other 638 object be submitted by a registered maintainer. The referral system 639 would allow any existing maintainer to add another maintainer. This 640 can be used in parallel with the addition of other object types to 641 support the maintenance of those objects. For example, when adding 642 a subdomain to the ``domain'' hierarchy (in the RIPE repository where 643 domains are also handled), even when adding a new domain to a rela- 644 tively flat domain such as ``com'', there is already a maintainer for 645 the existing domain. The existing maintainer can add the maintainer 646 that will be needed for the new domain in addition to adding the new 647 domain and giving the new maintainer the right to modify it. 649 An organization gaining a presence on the Internet for the first time 650 would be given a maintainer. This maintainer may list a small number 651 of very trusted employees that are authorized to modify the maintainer 652 itself. The organization itself can then add another maintainer list- 653 ing a larger set of employees but listing the more restrictive main- 654 tainer in the mnt-by attributes of the maintainers themselves. The 655 organization can then add people and role objects as needed and any 656 other objects as needed and as authorization permits. 658 8.7 Objects with AS Hierarchical Names 660 Many RPSL objects do not have a natural hierarchy of their own but al- 661 low hierarchical names. Some examples are the object types ``as-set'' 662 and ``route-set''. An as-set may have a name corresponding to no nam- 663 ing hierarchy such as ``AS-Foo'' or it may have a hierarchical name of 664 the form ``AS1:AS-Bar''. 666 When a hierarchical name is not used, authorization for objects such 667 as ``as-set'' and ``route-set'' correspond to the rules for objects 668 with no hierarchy described in Section 8.6. 670 If hierarchical names are used, then the addition of an object must 671 be authorized by the aut-num for the AS in the name of the object. 672 The authentication must be listed in a maintainer referenced by the 673 mnt-lower attribute of the aut-num if present, or if absent, in a 674 maintainer referenced by the mnt-by attribute for the aut-num. 676 8.8 Query Processing 678 A query may have to span multiple repositories. All queries should 679 be directed toward a local repository which may mirror the root repos- 680 itory and others. Currently each IRR repository mirrors all others 681 repositories. In this way, the query may be answered by the local 682 repository but draw data from others. 684 For object types that have a natural hierarchy, such as aut-num, inet- 685 num, and route, the search begins at the root database and follows the 686 hierarchy. For objects types that have no natural hierarchy, such as 687 maintainers, people, and roles, the search is confined to a default 688 database unless a database is specified. The default database is 689 the same database as an object from which a reference is made if the 690 query is launched through the need to follow a reference. Otherwise 691 the default is generally the local database or a default set by the 692 repository. The default can be specified in the query itself. 694 In searching for an AS, the AS blocks can be consulted, moving the 695 search to data from other repositories. Eventually the AS is either 696 found or the search fails. 698 The search for an inetnum is similar. Less specific inetnums may 699 refer the search to other databases. Eventually the most specific 700 inetnum is found and its status can be determined and assignment de- 701 termined if it is assigned. 703 The search for a route is similar except the search may branch to 704 more than one repository. The most specific route in one repository 705 may be more specific than the most specific in another. In looking 706 for a route object it makes sense to return the most specific route 707 that is not more specific than the query requests regardless of which 708 repository that route is in rather than return one route from each 709 repository that contains a less specific overlap. 711 8.9 Adding to the Database 713 The root repository [14] must be initially populated at some epoch 714 with a few entries. An initial maintainer is needed to add more main- 715 tainers. The referral-by attribute can be set to refer to itself in 716 this special case (Section 9 describes the referral-by). When adding 717 an inetnum or a route object an existing exact match or a less spe- 718 cific overlap must exist. A route object may be added based on an 719 exact match or a less specific inetnum. The root repository must be 720 initially populated with the allocation of an inetnum covering the 721 prefix 0/0, indicating that some address allocation authority exists. 722 Similarly an initial as-block is needed covering the full AS number 723 range. 725 When adding an object with no natural hierarchy, the search for an 726 existing object follows the procedure outlined in Section 8.8. 728 When adding an aut-num (an AS), the same procedure used in a query is 729 used to determine the appropriate repository for the addition and to 730 determine which maintainer applies. The sequence of AS-block objects 731 and repository delegations is followed. If the aut-num does not ex- 732 ist, then the submission must match the authentication specified in 733 the maintainer for the most specific AS-block in order to be added. 735 The procedure for adding an inetnum is similar. The sequence of inet- 736 num blocks is followed until the most specific is found. The submis- 737 sion must match the authentication specified in the maintainer for the 738 most specific inetnum overlapping the addition. 740 Adding a route object is somewhat more complicated. The route object 741 submission must satisfy two authentication criteria. It must match 742 the authentication specified in the aut-num and the authentication 743 specified in either a route object or if no applicable route object is 744 found, then an inetnum. 746 An addition is submitted with an AS number and prefix as its key. If 747 the object already exists, then the submission is treated as a modify 748 (see Section 8.10). If the aut-num does not exist on a route add, 749 then the addition is rejected (see Section A for further discussion 750 of tradeoffs). If the aut-num exists then the submission is checked 751 against the applicable maintainer. A search is then done for the 752 prefix first looking for an exact match. If the search for an exact 753 match fails, a search is made for the longest prefix match that is 754 less specific than the prefix specified. If this search succeeds it 755 will return one or more route objects. The submission must match an 756 applicable maintainer in at least one of these route objects for the 757 addition to succeed. If the search for a route object fails, then 758 a search is performed for an inetnum that exactly matches the prefix 759 or for the most specific inetnum that is less specific than the route 760 object submission. The search for an inetnum should never fail but it 761 may return an unallocated or reserved range. The inetnum status must 762 be ``allocated'' and the submission must match the maintainer. 764 Having found the AS and either a route object or inetnum, the autho- 765 rization is taken from these two objects. The applicable maintainer 766 object is any referenced by the mnt-routes attributes. If one or more 767 mnt-routes attributes are present in an object, the mnt-by attributes 768 are not considered. In the absence of a mnt-routes attribute in a 769 given object, the mnt-by attributes are used for that object. The 770 authentication must match one of the authorizations in each of the two 771 objects. 773 If the addition of a route object or inetnum contains a reclaim at- 774 tribute, then any more specific objects of the same type must be ex- 775 amined. The reclaim attribute can only be added if there are no more 776 specific overlaps or if the authentication on the addition is present 777 in the authorization of a less specific object that already has a re- 778 claim attribute covering the prefix range, or if the authentication on 779 the addition is authorized for the modification of all existing more 780 specific prefixes covered by the addition. 782 8.10 Modifying or Deleting Database Objects 784 When modifying or deleting any existing object a search for the object 785 is performed as described in Section 8.8. If the submission matches 786 an applicable maintainer for the object, then the operation can pro- 787 ceed. An applicable maintainer for a modification is any maintainer 788 referenced by the mnt-by attribute in the object. For route and inet- 789 num objects an applicable maintainer may be listed in a less specific 790 object with a reclaim attribute. 792 If the submission is for a route object, a search is done for all 793 less specific route objects and inetnums. If the submission is for 794 an inetnum, a search is done for all less specific inetnums. If the 795 submission fails the authorization in the object itself but matches 796 the reclaim attribute in any of the less specific objects, then the 797 operation can proceed. Section A contains discussion of the rationale 798 behind the use of the reclaim attribute. 800 A modification to an inetnum object that adds a reclaim attribute 801 or removes a no-reclaim attribute must be checked against all exist- 802 ing inetnums that are more specific. The same check of the reclaim 803 attribute that is made during addition must be made when a reclaim 804 attribute is added by a modification (see Section 8.9). 806 A deletion is considered a special case of the modify operation. The 807 deleted object may remain in the database with a ``deleted'' at- 808 tribute in which case the mnt-by can still be consulted to remove 809 the ``deleted'' attribute. 811 9 Data Format Summaries 813 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII 814 text. Objects consist of a set of attributes. Attributes are name 815 value pairs. A single attribute is represented as a single line with 816 the name followed by a colon followed by whitespace characters (space, 817 tab, or line continuation) and followed by the value. Within a value 818 all whitespace is equivalent to a single space. Line continuation is 819 supported by a backslash at the end of a line or the following line 820 beginning with whitespace. When transferred, externally attributes 821 are generally broken into shorter lines using line continuation though 822 this is not a requirement. An object is externally represented as a 823 series of attributes. Objects are separated by blank lines. 825 There are about 80 attribute types in the current RIPE schema and 826 about 15 object types. Some of the attributes are mandatory in cer- 827 tain objects. Some attributes may appear multiple times. One or 828 more attributes may form a key. Some attributes or sets of attributes 829 may be required to be unique across all repositories. Some of the 830 attributes may reference a key field in an object type and may be 831 required to be a valid reference. Some attributes may be used in 832 inverse lookups. 834 A review of the entire RIPE or RPSL schema would be too lengthy to 835 include here. Only the differences in the schema are described. 837 9.1 Changes to the RIPE/RPSL Schema 839 One object type is added to the RIPE/RPSL schema. A few attributes 840 are added to existing object types. There are significant changes to 841 the rules which determine if the addition of an object is authorized. 842 Additional keywords representing new authentication types are added to 843 the semantics of the existing ``auth'' attribute. 845 The new object type is listed below. The first attribute listed is 846 the key attribute and also serves as the name of the object type. 848 as-block key mandatory single unique 849 descr optional multiple 850 remarks optional multiple 851 admin-c mandatory multiple 852 tech-c mandatory multiple 853 notify optional multiple 854 mnt-by mandatory multiple 855 changed mandatory multiple 856 source mandatory single 858 In the above object type only the key attribute ``as-block'' is new: 860 as-block This attribute provides the AS number range for an ``as- 861 block'' object. The format is two AS numbers including the sub- 862 string ``AS'' separated by a ``-'' delimiter and optional whites- 863 pace before and after the delimiter. 865 In order to support stronger authentication, the following keywords 866 are added to the ``auth'' attribute: 868 pgp-from The remainder of the attribute gives the string identify- 869 ing a PGP identity whose public key is held in an external keyring. 870 The use of this method is deprecated in favor of the ``pgpkey'' 871 method. 873 pgpkey See [22]. 875 In order to disable authentication and give permission to anyone, the 876 authentication method ``none'' is added. It has no arguments. 878 An additional change is the ``auth'' attribute is allowed to exist 879 in a ``person'' or ``role'' object. The ``auth'' method ``role'' or 880 ``person'' can be used to refer to a role or person object and take 881 the ``auth'' fields from those objects. Care must be taken in imple- 882 mentations to detect circular references and terminate expansion or 883 the references already visited. 885 A few attributes are added to the schema. These are: 887 mnt-routes The mnt-routes attribute may appear in an aut-num, inet- 888 num, or route object. When used with a aut-num, inetnum, or route 889 object, this attribute references a maintainer object which is used 890 in determining authorization for the addition of route objects. 891 When placed in a less specific inetnum it is used in determining 892 authorization for the addition of more specific inetnum objects. 893 After the reference to the maintainer, an optional list of prefix 894 ranges (as defined in RPSL) inside of curly braces or the keyword 895 ``ANY'' may follow. If a mnt-routes attribute is absent, the mnt- 896 lower or mnt-by mnt-by attribute is used for this purpose. The 897 mnt-routes attribute is optional and multiple. 899 mnt-lower The mnt-lower attribute may appear in an inetnum, route, 900 as-block or aut-num object. This attribute references a maintainer 901 object. When used in an inetnum or route object the effect is the 902 same as a ``mnt-routes'' but applies only to prefixes more specific 903 than the prefix of the object in which it is contained. In an as- 904 block object, mnt-lower allows addition of more specific as-block 905 objects or aut-num objects. In an aut-num object the mnt-lower at- 906 tribute specifies a maintainer that can be used to add objects with 907 hierarchical names as described in Section 8.7. If a mnt-lower 908 attribute is absent, the mnt-by attribute is used. 909 reclaim The reclaim attribute may appear in as-block, aut-num, inet- 910 num, or route objects. Any object of the same type below in the 911 hierarchy may be modified or deleted by the maintainer of the ob- 912 ject containing a reclaim attribute. The value of the attribute is 913 a set or range of objects of the same type where the syntax of the 914 set or range is as defined in RPSL. See Section 8.5 for restric- 915 tions on adding reclaim attributes. 917 no-reclaim The no-reclaim attribute is used with the reclaim at- 918 tribute. The no-reclaim attribute negates any reclaim attribute it 919 overlaps. See Section 8.5 for restrictions on deleting no-reclaim 920 attributes. 922 referral-by This attribute is required in the maintainer object. It 923 may never be altered after the addition of the maintainer. This 924 attribute refers to the maintainer that created this maintainer. 925 It may be multiple if more than one signature appeared on the 926 transaction creating the object. 928 auth-override An auth-override attribute can be added, deleted, or 929 changed by a transaction submitted by maintainer listed in the 930 referral-by. An auth-override can only be added to a maintainer 931 if that maintainer has been inactive for the prior 60 days. The 932 auth-override attribute itself contains only the date when the at- 933 tribute will go into effect which must be at least 60 days from the 934 current date unless there is already authorization to modify the 935 maintainer. After the date in the auth-override is reached, those 936 identified by the maintainer in the referral-by have authoriza- 937 tion to modify the maintainer. This attribute exists as a means to 938 clean up should the holder of a maintainer become unresponsive and 939 can only take effect if that maintainer does not remove the auth- 940 override in response to the automatic notification that occurs on 941 changes. 943 Each repository must identify itself with a ``repository'' object. 944 The repository must also contain a special ``repository'' whose key 945 is ``ROOT''. The root repository is where all non-local queries are 946 directed, including where hierarchical object queries start. The 947 query methods listed for the root repository may actually be a subset 948 of those offered by that repository if efficiency considerations and 949 topologic distance make some methods less useful. 951 The root repository must contain a copy of the repository objects 952 in any repository considered valid. The repository objects will be 953 essential when the routing registry becomes more widely distributed. 955 The existing ``mnt-by'' attribute references the ``maintainer'' ob- 956 ject type. The ``mnt-by'' attribute is now mandatory in all object 957 types. A new maintainer may be added by any existing maintainer. The 958 ``referral-by'' attribute is now mandatory in the ``maintainer'' ob- 959 ject to keep a record of which maintainer made the addition and can 960 never be changed. Maintainers cannot be deleted as long as they are 961 referenced by a ``referral-by'' attribute elsewhere. 963 A Technical Discussion 965 A few design tradeoffs exist. Some of these tradeoffs, the selected 966 solution, and the alternatives are discussed here. Some of the issues 967 are listed below. 969 1. Whether to error on the side of permissiveness and weaken autho- 970 rization controls or risk the possibility of erecting barriers to 971 registering information. 973 2. Whether to support enforcible address lending or provide the 974 smaller or end user with ultimate control over the registration 975 of the prefixes they are using. 977 3. What to do with older objects that either don't conform to newer 978 requirements regarding minimum authorization, authentication, and 979 accountability, or are of questionable validity. 981 A.1 Relaxing requirements for ease of registry 983 If the requirement that an aut-num exists is relaxed, then it is pos- 984 sible for anyone to make use of an unassigned AS number or make use 985 of an assigned AS number for which the aut-num has not been entered. 986 Placing requirements on the entry of aut-num presumes cooperation of 987 the Internet address allocation authority (if separate from the rout- 988 ing registry). The address allocation authority must be willing to 989 field requests to populate skeleton aut-nums from the party for which 990 the allocation has been made. These aut-num must include a reference 991 to a maintainer. A request to the address allocation authority must 992 therefore include a reference to an existing maintainer. 994 The ability to add route objects is also tied to the existence of less 995 specific route objects or inetnums. The Internet address allocation 996 authority (if separate from the routing registry) must also be will- 997 ing to field requests to add inetnum records for the party already 998 allocated the address space. 1000 The Internet address allocation authority should also add inetnums and 1001 aut-nums for new allocations. In order to do so, a maintainer must 1002 exist. If a party is going to connect to the Internet, they can get a 1003 maintainer by making a request to the Internet service provider they 1004 will be connecting to. Once they have a maintainer they can make a 1005 request for address space or an AS number. The maintainer can con- 1006 tain a public key for a cryptographicly strong authorization method 1007 or could contain a ``crypt-key'' or ``mail-to'' authorization check if 1008 that is considered adequate by the registering party. Furthermore an 1009 address allocation authority should verify that the request for an AS 1010 number or for address space matches the authorization criteria in the 1011 maintainer. 1013 Currently only the registry themselves may add maintainers. This be- 1014 comes a problem for the registry particularly verifying public keys. 1015 This requirement is relaxed by allowing existing maintainers to add 1016 maintainers. Unfortunately the accountability trail does not exist 1017 for existing maintainers. The requirement then should be relaxed 1018 such that existing maintainers may remain but only existing maintain- 1019 ers that have a ``referral-by'' attribute can add maintainers. The 1020 ``referral-by'' cannot be modified. This requirement can be relax 1021 slightly so that a ``referral-by'' can be added to a maintainer by 1022 an existing maintainer with a ``referral-by''. This will allow the 1023 accountability trail to be added to existing maintainers and these 1024 maintainers can then add new maintainers. 1026 Verifying that a party is who they claim to be on initial addition, 1027 is one of the problems that currently falls upon the AS number and 1028 address registry. This problem is reduced by allowing existing main- 1029 tainers to add maintainers. This may actually make it easier to get 1030 maintainers and therefore easier to register. The number authority 1031 still must verify that the AS or address space is actually needed by 1032 the party making a request. 1034 Authorization checks made during the addition of route objects that 1035 refer to AS objects and inetnum strongly rely on the cooperation of 1036 the Internet address allocation authorities. The number authorities 1037 must register as-blocks, aut-nums, or inetnums as AS numbers or ad- 1038 dress space is allocated. If only a subset of the number authorities 1039 cooperate, then either an inetnum or as-block can be created cover- 1040 ing the space that registry allocates and essentially requiring null 1041 allocation (for example a ``crypt-pw'' authentication where the pass- 1042 word is given in the remarks in the object or its maintainer) or those 1043 obtaining addresses from that number authority will have trouble reg- 1044 istering in the routing registry. The authorization model supports 1045 either option, though it would be preferable if the number authorities 1046 cooperated and the issue never surfaced in practice. 1048 The maintainer requirements can be relaxed slightly for existing main- 1049 tainers making it easier to register. Relaxing requirements on other 1050 objects may defeat the authorization model, hence is not an option. 1052 A.2 The address lending issue 1054 The issue of whether lending contracts should be enforcible is an 1055 issue of who should ultimately be able to exercise control over al- 1056 locations of address space. The routing registry would be wise to 1057 stay as neutral as possible with regard to disputes between third par- 1058 ties. The ``reclaim'' and ``no-reclaim'' are designed to allow either 1059 outcome to the decision as to whether the holder of a less specific 1060 inetnum or route object can exercise control over suballocations in 1061 the registry. The routing registry itself must decide whether to re- 1062 tain control themselves and if so, should very clearly state under 1063 what conditions the registry would intervene. A registry could even 1064 go to the extreme of stating that they will intervene in such a dis- 1065 pute only after the dispute has been resolved in court and a court 1066 order has been issued. 1068 When an allocation is made by a registry, the registry should keep a 1069 ``reclaim'' attribute in the less specific object and make a strong 1070 policy statement that the reclaim privilege will not be used except 1071 under very clearly defined special circumstances (which at the very 1072 minimum would include a court order). If the allocation is further 1073 subdivided the party subdividing the allocation and the party accept- 1074 ing the suballocation must decide whether a ``reclaim'' can be kept by 1075 the holder of the less specific allocation or whether a ``no-reclaim'' 1076 must be added transferring control to the holder of the more specific. 1077 The registry is not involved in that decision. Different pairs of 1078 third parties may do different decisions regarding the ``reclaim'' 1079 and any contractual restrictions on its use that may be expressed out- 1080 side of the registry in the form of a legal contract and ultimately 1081 resolved by the courts in the event of a bitter dispute. 1083 By retaining ``reclaim'' rights the registry retains the ability to 1084 abide by a court order. This may only truly become an issue in a dis- 1085 tributed registry environment where registries will be rechecking the 1086 authorization of transactions made elsewhere and may fail to process 1087 the attempt of another registry to abide by a court order by overrid- 1088 ing normal authorization to change the registry contents if a reclaim 1089 is not present. 1091 A.3 Dealing with non-conformant or questionable older data 1093 Some of the newer requirements include requiring that all objects 1094 reference a maintainer object responsible for the integrity of the 1095 object and requiring accountability for the creation of maintainers 1096 to be recorded in the maintainer objects so that accountability can 1097 be traced back from an unresponsive maintainer. In the event that 1098 contact information is absent or incorrect from objects and there is 1099 any question regarding the validity of the objects, the maintainer can 1100 be contacted. If the maintainer is unresponsive, the maintainer that 1101 authorized the addition of that maintainer can be contacted to either 1102 update the contact information on the maintainer or confirm that the 1103 entity no longer exists or is no longer actively using the Internet or 1104 the registry. 1106 Many route objects exist for which there are no maintainers and for 1107 which inetnum and AS objects do not exist. Some contain the now obso- 1108 leted guardian attribute rather than a mnt-by. 1110 It is not practical to unconditionally purge old data that does not 1111 have maintainers or does not conform to the authorization hierarchy. 1112 New additions must be required to conform to the new requirements 1113 (otherwise the requirements are meaningless). New requirements can 1114 be phased in by requiring modifications to conform to the new require- 1115 ments. 1117 A great deal of questionable data exists in the current registry. The 1118 requirement that all objects have maintainers and the requirements 1119 for improved accountability in the maintainers themselves may make it 1120 easier to determine contact information even where the objects are not 1121 updated to reflect contact information changes. 1123 It is not unreasonable to require valid contact information on exist- 1124 ing data. A great deal of data appears to be unused, such as route 1125 objects for which no announcement has been seen in many months or 1126 years. An attempt should be made to contact the listed contacts in 1127 the object, in the maintainer if there is one, then up the maintainer 1128 referral-by chain if there is one, and using the number registry or 1129 origin AS contact information if there is no maintainer accountability 1130 trail to follow. Experience so far indicates that the vast majority 1131 of deletions identified by comparing registered prefixes against route 1132 dumps will be positively confirmed (allowing the deletion) or there 1133 will be no response due to invalid contact information (in many cases 1134 the IRR contact information points to nsfnet-admin@merit.edu). 1136 By allowing the registry to modify (or delete) any objects which are 1137 disconnected from the maintainer accountability trail, cleanup can 1138 be made possible (though mail header forging could in many cases have 1139 the same effect it is preferable to record the fact that the registry 1140 itself made the cleanup). Similarly, a mechanism may be needed in 1141 the future to allow the maintainer in the referral-by to override 1142 maintainer privileges in a referred maintainer if all contacts have 1143 become unresponsive for a maintainer. The referral-by maintainer is 1144 allowed to add an ``auth-override'' attribute which becomes usable 1145 as an ``auth'' within 60 days from the time of addition. The main- 1146 tainer themselves would be notified of the change and could remove the 1147 ``auth-override'' attribute before it becomes effective and inquire as 1148 to why it was added and correct whatever problem existed. This can be 1149 supported immediately or added later if needed. 1151 B Common Operational Cases 1153 In principle address allocation and route allocation should be hierar- 1154 chical with the hierarchy corresponding to the physical topology. In 1155 practice this is often not the case for numerous reasons. The pri- 1156 mary reasons are the topology is not strictly tree structured and the 1157 topology can change. More specificly: 1159 1. The Internet topology is not strictly tree structured. 1160 o At the top level the network more closely resembles a moderately 1161 dense mesh. 1163 o Near the bottom level many attachments to the Internet are multi- 1164 homed to more than one Internet provider. 1165 2. The Internet topology can and does change. 1167 o Many attachments switch providers to obtain better service or 1168 terms. 1170 o Service providers may modify adjacencies to obtain better transit 1171 service or terms. 1172 o Service providers may disappear completely scattering attachments 1173 or merge. 1175 Renumbering is viewed as a practical means to maintain a strict nu- 1176 meric hierarchy [19]. It is also acknowledged that renumbering IPv4 1177 networks can be difficult [19, 3, 20]. We examine first the simple 1178 case where hierarchy still exists. We then examine the operational 1179 cases where either initial topology is not tree structured or cases 1180 where topology changes. 1182 B.1 simple hierarchical address allocation and route allocation 1184 This is the simplest case. Large ranges of inetnums are assigned to 1185 address registries. These registries in turn assign smaller ranges 1186 for direct use or to topologically large entities where allocations 1187 according to topology can reduce the amount of routing information 1188 needed (promote better route aggregation). 1190 AS objects are allocated as topology dictates the need for additional 1191 AS [10]. Route objects can be registered by those with authoriza- 1192 tion given by the AS and by the address owner. This is never an issue 1193 where the maintainer of the AS and the inetnum are the same. Where 1194 they differ, either the provider can give permission to add route ob- 1195 jects for their AS, or the party allocated the address space can give 1196 the provider permission to add router objects for their address space, 1197 or both parties can sign the transaction. Permission is provided by 1198 adding to maintainer attributes. 1200 B.2 aggregation and multihomed more specific routes 1202 Aggregation is normally not a problem if a provider is aggregating ad- 1203 dress space allocated to the provider and then suballocated internally 1204 and/or to customers. In fact, the provider would be expected to do 1205 so. This is not a problem even if the route object for the aggrega- 1206 tion is added after the more specific route objects since only less 1207 specific objects are considered. 1209 Aggregation is potentially a problem if a provider or a set of 1210 providers plan to aggregate address space that was never explicitly 1211 allocated as a block to those providers but rather remains the alloca- 1212 tion of a address registry. These large aggregations can be expected 1213 to be uncommon, but relatively easily dealt with. Superaggregates of 1214 this type will generally be formed by topologically close entities who 1215 have also managed to draw adjacent address allocations. In effect, 1216 the registry must give permission to form such as superaggregate by 1217 either giving permission to do so in the mnt-routes of an inetnum or 1218 by signing the submission along with the other parties. 1220 B.3 provider independent addresses and multiple origin AS 1222 Provider independent addresses and multihoming arrangement using mul- 1223 tiple origin AS present a similar problem to multihoming. The main- 1224 tainer of the address space and the maintainer of the AS is not the 1225 same. Permission can be granted using mnt-routes or multiple signa- 1226 tures can appear on the submission. 1228 B.4 change in Internet service provider 1230 A change in Internet service providers is similar to multihoming. 1231 A minor difference is that the AS for the more specific route will 1232 be the AS of the new provider rather than the AS of the multihomed 1233 customer. Permission can be granted using mnt-routes or multiple 1234 signatures can appear on the submission. 1236 B.5 renumbering grace periods 1238 Renumbering grace periods allow a provider who wants to keep an ad- 1239 dress allocation intact to allow a customer who has chosen to go to 1240 another provider to renumber their network gradually and then re- 1241 turn the address space after renumbering is completed. The issue of 1242 whether to require immediate renumbering or offer renumbering grace 1243 periods and how long they should be or whether they should be in- 1244 definite has been topic of bitter disputes. The authorization model 1245 can support no renumbering grace period, a finite renumbering grace 1246 period, or an indefinite renumbering grace period. The ``reclaim'' 1247 attribute described in Section 8.1 provides a means to end the grace 1248 period. 1250 C Deployment Considerations 1252 This section describes deployment considerations. The intention is to 1253 raise issues and discuss approaches rather than to provide a deploy- 1254 ment plan. 1256 The use of routing registries is not yet universally accepted. There 1257 still remain Internet providers who see no reason to provide the added 1258 assurance of accurate routing information described in Section 5. 1259 More accurately, these benefits are viewed as being insufficient to 1260 justify the cost. This has been largely caused an inability of a very 1261 major router vendor up until recently to handle prefix lists of the 1262 size needed to specify routing policy on a per prefix basis. Another 1263 reason cited is that filtering on a prefix basis in an environment 1264 where routing registry is incomplete or inaccurate can interfere with 1265 connectivity. 1267 There clearly is a critical mass issue with regard to the use of rout- 1268 ing registries. A minority of providers use the existing IRR to 1269 filter on a per prefix basis. Another minority of providers do not 1270 support the IRR and generally fail to register prefixes until con- 1271 nectivity problems are reported. The majority of providers register 1272 prefixes but do not implement strict prefix filtering. 1274 Deploying new authentication mechanisms has no adverse consequences. 1275 This has been proven with Merit's deployment of PGP. 1277 In deploying new authorization mechanisms, a major issue is dealing 1278 with existing data of very questionable origin. A very large num- 1279 ber of route objects refer to prefixes that have not been announced 1280 for many years. Other route objects refer to prefixes that are no 1281 longer announced with the origin AS that they are register with (some 1282 were incorrectly registered to start with). There are many causes for 1283 this. 1285 1. During the transition from the NSFNET PRDB to the RADB a large 1286 number of prefixes were registered with an origin AS correspond- 1287 ing to the border AS at which the NSFNET had once heard the route 1288 announcements. The PRDB did not support origin AS, so border 1289 AS was used. Many of these routes were no longer in use at the 1290 time and are now routed with a submitter listed as ``nsfnet- 1291 admin@merit.edu''. 1292 2. As CIDR was deployed, aggregates replaced previously separately 1293 announced more specific prefixes. The route objects for the more 1294 specific prefixes were never withdrawn from the routing registries. 1296 3. Some prefixes are simply no longer in use. Some networks have been 1297 renumbered. Some network no longer exist. Often the routing reg- 1298 istry information is not withdrawn. 1299 4. As provider AS adjacencies changed and as end customers switched 1300 providers often the actual origin AS changed. This was often not 1301 reflected by a change in the routing registry. 1303 Inaccuracies will continue to occur due to the reasons above, except 1304 the first. The hierarchical authorization provides greater account- 1305 ability. In the event that the contacts for specific objects become 1306 unresponsive traversal up the authorization hierarchy should help 1307 identify the parties having previous provided authorization. These 1308 contacts may still have sufficient authorization to perform the neces- 1309 sary cleanup. This issue is discussed in Section A. 1311 A great deal of information is currently missing in the IRR. Quite a 1312 few AS have no aut-num. Quite a lot of data has no maintainer and the 1313 vast majority of maintainers use only the weakest of authentication 1314 methods. Very little can be done by the registries to correct this. 1315 The defaults in the cases of missing objects needed for authorization 1316 has to be to make no authentication checks at all. 1318 The transition can be staged as follows: 1320 1. Add and make use of stronger authorization models. 1322 2. Make schema modifications necessary to support delegations. 1323 3. Add delegation objects needed for query traversal. 1325 4. Base query traversal on delegations rather than search of all known 1326 registries. 1328 5. Obtain the cooperation of the address registries for the purpose of 1329 populating the ``inetnum'' entries on an ongoing basis. 1330 6. Add hierarchical authorization support for critical object types, 1331 ``aut-num'', ``inetnum'' and ``route''. 1333 7. Add the requirement that database object either be in use or have 1334 valid contact information and if queries are made by the registry a 1335 response from a contact indicating that the object serves a purpose 1336 if it is not clear what its use is. 1338 8. Begin to purge data which is clearly not in use and for which there 1339 is no valid contact information or no response from the contacts. 1341 Deployment of hierarchical authorization requires cooperation among 1342 the existing routing registries. New code will have to be deployed. 1343 In some cases very little development resources are available and sub- 1344 stantial inertia exists due to the reliance on the current repository 1345 and the need to avoid disruption. 1347 If hierarchical authorization of route objects depends on the exis- 1348 tence of address registration information, minimal cooperation of 1349 the currently separate address registries is required. The extent 1350 of the cooperation amounts to sending cryptographically signed trans- 1351 actions from the address registry to the number registry as address 1352 allocations are made or providing equivalent access to new address 1353 allocations. 1355 Currently most registries returns query results from all of the known 1356 repositories using their mirrored copies. Cross registry authoriza- 1357 tions are not yet implemented. Minimal schema changes have to be made 1358 to support the ability to delegate objects for which there is an au- 1359 thorization hierarchy and the support queries and references to other 1360 repositories. In the case of AS delegations, ``as-block'' need to be 1361 created solely for the purpose of traversal. 1363 Acknowledgments 1365 This document draws ideas from numerous discussions and contributions 1366 of the IETF Routing Policy System Work Group and RIPE Routing Work 1367 Group. Earlier drafts of this document listed Carol Orange as a co- 1368 author. Carol Orange made contributions to this document while at 1369 RIPE. 1371 References 1373 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 1374 M. Terpstra, and C. Villamizar. Routing policy specification 1375 language (rpsl). Technical Report RFC 2280, Internet Engineering 1376 Task Force, 1998. ftp://ftp.isi.edu/in-notes/rfc2280.txt. 1377 [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Kar- 1378 renberg, M. Terpstra, and J. Yu. Representation of ip rout- 1379 ing policies in a routing registry (ripe-81++). Techni- 1380 cal Report RFC 1786, Internet Engineering Task Force, 1995. 1381 ftp://ftp.isi.edu/in-notes/rfc1786.txt. 1383 [3] H. Berkowitz. Router renumbering guide. Technical Re- 1384 port RFC 2072, Internet Engineering Task Force, 1997. 1385 ftp://ftp.isi.edu/in-notes/rfc2072.txt. 1387 [4] H.W. Braun. Models of policy based routing. Technical 1388 Report RFC 1104, Internet Engineering Task Force, 1989. 1389 ftp://ftp.isi.edu/in-notes/rfc1104.txt. 1390 [5] H.W. Braun and Y. Rekhter. Advancing the nsfnet routing archi- 1391 tecture. Technical Report RFC 1222, Internet Engineering Task 1392 Force, 1991. ftp://ftp.isi.edu/in-notes/rfc1222.txt. 1394 [6] D.D. Clark. Policy routing in internet protocols. Techni- 1395 cal Report RFC 1102, Internet Engineering Task Force, 1989. 1396 ftp://ftp.isi.edu/in-notes/rfc1102.txt. 1398 [7] D. Crocker. Standard for the format of arpa internet text mes- 1399 sages. Technical Report RFC 822, Internet Engineering Task 1400 Force, 1982. ftp://ftp.isi.edu/in-notes/rfc822.txt. 1402 [8] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless inter-domain 1403 routing (cidr): an address assignment and aggregation strat- 1404 egy. Technical Report RFC 1519, Internet Engineering Task Force, 1405 1993. ftp://ftp.isi.edu/in-notes/rfc1519.txt. 1407 [9] Internet Engineering Steering Group and R. Hinden. Applicability 1408 statement for the implementation of classless inter-domain rout- 1409 ing (cidr). Technical Report RFC 1517, Internet Engineering Task 1410 Force, 1993. ftp://ftp.isi.edu/in-notes/rfc1517.txt. 1411 [10] J. Hawkinson and T. Bates. Guidelines for creation, selec- 1412 tion, and registration of an autonomous system (as). Techni- 1413 cal Report RFC 1930, Internet Engineering Task Force, 1996. 1414 ftp://ftp.isi.edu/in-notes/rfc1930.txt. 1416 [11] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, and J. Pos- 1417 tel. Internet registry ip allocation guidelines. Techni- 1418 cal Report RFC 2050, Internet Engineering Task Force, 1996. 1419 ftp://ftp.isi.edu/in-notes/rfc2050.txt. 1420 [12] Mark Knopper and Steven J. Richardson. Aggregation sup- 1421 port in the nsfnet policy-based routing database. Techni- 1422 cal Report RFC 1482, Internet Engineering Task Force, 1993. 1423 ftp://ftp.isi.edu/in-notes/rfc1482.txt. 1425 [13] David Meyer, Cengiz Alaettinoglu, J. Schmitz, and Carol Orange. 1426 Using rpsl in practice. Internet Draft (Work in Progress) draft- 1427 ietf-rps-appl-rpsl-03, Internet Engineering Task Force, 11 1998. 1428 ftp://ftp.isi.edu/internet-drafts/draft-ietf-rps-appl-rpsl- 1429 03.txt. 1430 [14] David Meyer, Curtis Villamizar, Cengiz Alaettinoglu, and 1431 R. Govindan. Distributed routing policy system. Internet Draft 1432 (Work in Progress) draft-ietf-rps-dist-00, Internet Engineering 1433 Task Force, 9 1998. ftp://ftp.isi.edu/internet-drafts/draft- 1434 ietf-rps-dist-00.txt. 1436 [15] National Institute of Standards and Technology. The digital sig- 1437 nature standard, proposal and discussion. Communications of the 1438 ACM, 35(7):36--54, July 1992. 1440 [16] National Institute of Standards and Technology (NIST). Fips pub- 1441 lication 186: Digital signature standard (dss). Technical re- 1442 port, Gaithersburg, MD, May 1994. 1443 [17] Y. Rekhter. Routing in a multi-provider internet. Techni- 1444 cal Report RFC 1787, Internet Engineering Task Force, 1995. 1445 ftp://ftp.isi.edu/in-notes/rfc1787.txt. 1447 [18] Y. Rekhter and T. Li. An architecture for ip address allocation 1448 with cidr. Technical Report RFC 1518, Internet Engineering Task 1449 Force, 1993. ftp://ftp.isi.edu/in-notes/rfc1518.txt. 1451 [19] Y. Rekhter and T. Li. Implications of various address alloca- 1452 tion policies for internet routing. Technical Report RFC 2008, 1453 Internet Engineering Task Force, 1996. ftp://ftp.isi.edu/in- 1454 notes/rfc2008.txt. 1456 [20] Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, and J. Pos- 1457 tel. An ipv6 provider-based unicast address format. Techni- 1458 cal Report RFC 2073, Internet Engineering Task Force, 1997. 1459 ftp://ftp.isi.edu/in-notes/rfc2073.txt. 1461 [21] Bruce Schneier. Applied Cryptography. Wiley, New York, 1996. 1462 [22] Janos Zsako. Pgp authentication for ripe database updates. 1463 Internet Draft (Work in Progress) draft-ietf-rps-dbsec- 1464 pgp-authent-00, Internet Engineering Task Force, 11 1998. 1465 ftp://ftp.isi.edu/internet-drafts/draft-ietf-rps-dbsec-pgp- 1466 authent-00.txt. 1468 Security Considerations 1470 @@ This entire document is about security but at some point we need to 1471 figure out what belongs here in this case. Maybe the Area Directors 1472 can provide some advice. 1474 Author's Addresses 1476 Curtis Villamizar 1477 UUNET Network Architecture Group 1478 1480 Cengiz Alaettinoglu 1481 ISI 1482 1484 David M. Meyer 1485 Cisco 1486 1488 Sandy Murphy 1489 Trusted Information Systems 1490 1492 Full Copyright Statement 1494 Copyright (C) The Internet Society (February 23, 1999). All Rights 1495 Reserved. 1497 This document and translations of it may be copied and furnished to 1498 others, and derivative works that comment on or otherwise explain it 1499 or assist in its implmentation may be prepared, copied, published and 1500 distributed, in whole or in part, without restriction of any kind, 1501 provided that the above copyright notice and this paragraph are in- 1502 cluded on all such copies and derivative works. However, this doc- 1503 ument itself may not be modified in any way, such as by removing the 1504 copyright notice or references to the Internet Society or other In- 1505 ternet organizations, except as needed for the purpose of developing 1506 Internet standards in which case the procedures for copyrights defined 1507 in the Internet Standards process must be followed, or as required to 1508 translate it into languages other than English. 1510 The limited permissions granted above are perpetual and will not be 1511 revoked by the Internet Society or its successors or assigns. 1513 This document and the information contained herein is provided on an 1514 ``AS IS'' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEER- 1515 ING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUD- 1516 ING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1517 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1518 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.