idnits 2.17.1 draft-ietf-rps-auth-04.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 107 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 40 pages 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 878 has weird spacing: '... key manda...' == Line 879 has weird spacing: '...ptional mult...' == Line 880 has weird spacing: '...ptional mult...' == Line 881 has weird spacing: '...ndatory multi...' == Line 882 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 (June 23, 1999) is 9073 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1699, 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') ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '13') ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '15') ** Obsolete normative reference: RFC 2073 (ref. '17') (Obsoleted by RFC 2374) == Outdated reference: A later version (-02) exists of draft-ietf-rps-dbsec-pgp-authent-01 Summary: 22 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Curtis Villamizar 2 INTERNET-DRAFT Avici 3 draft-ietf-rps-auth-04.txt Cengiz Alaettinoglu 4 ISI 5 David M. Meyer 6 Cisco 7 Sandy Murphy 8 TIS 9 June 23, 1999 11 Routing Policy System Security 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference mate- 25 rial or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright (C) The Internet Society (June 23, 1999). All Rights Re- 34 served. 36 Abstract 38 The RIPE database specifications and RPSL language define languages 39 used as the basis for representing information in a routing policy 40 system. A repository for routing policy system information is known 41 as a routing registry. A routing registry provides a means of ex- 42 changing information needed to address many issues on importance to 43 the operation of the Internet. The implementation and deployment of 44 a routing policy system must maintain some degree of integrity to be 45 of any operational use. This document addresses the need to assure 46 integrity of the data by providing an authentication and authorization 47 model. 49 1 Overview 51 The Internet Routing Registry (IRR) has evolved to meet a need for 52 Internet-wide coordination. This need was described in RFC-1787, an 53 informational RFC prepared on behalf of the IAB [14]. The following 54 summary appears in Section 7 of RFC-1787. 56 While ensuring Internet-wide coordination may be more and more 57 difficult, as the Internet continues to grow, stability and con- 58 sistency of the Internet-wide routing could significantly benefit 59 if the information about routing requirements of various organi- 60 zations could be shared across organizational boundaries. Such 61 information could be used in a wide variety of situations ranging 62 from troubleshooting to detecting and eliminating conflicting 63 routing requirements. The scale of the Internet implies that the 64 information should be distributed. Work is currently underway to 65 establish depositories of this information (Routing Registries), 66 as well as to develop tools that analyze, as well as utilize this 67 information. 69 A routing registry must maintain some degree of integrity to be of 70 any use. The degree of integrity required depends on the usage of the 71 routing policy system. 73 An initial intended usage of routing policy systems such as the RIPE 74 database had been in an advisory capacity, documenting the intended 75 routing policies for the purpose of debugging. In this role a very 76 weak form of authentication was deemed sufficient. 78 The IRR is increasingly used for purposes that have a stronger re- 79 quirement for data integrity and security. This document addresses 80 issues of data integrity and security that is consistent with the 81 usage of the IRR and which avoids compromising data integrity and se- 82 curity even if the IRR is distributed among less trusted repositories. 84 2 Background 86 An early routing policy system used in the NSFNET, the policy routing 87 database (PRDB), provided a means of determining who was authorized 88 to announce specific prefixes to the NSFNET backbone. The need for 89 a policy database was recognized as far back as 1989 [6, 4]. By 1991 90 the database was in place [5]. Authentication was accomplished by 91 requiring confirmation and was a manually intensive process. This 92 solved the problem for the NSFNET, but was oriented toward holding the 93 routing policy of a single organization. 95 The problem since has become more difficult. New requirements have 96 emerged. 98 1. There is a need to represent the routing policies of many organiza- 99 tions. 101 2. CIDR and overlapping prefixes and the increasing complexity of 102 routing policies and the needs of aggregation have introduced new 103 requirements. 104 3. There is a need to assure integrity of the data and delegate au- 105 thority for the data representing specifically allocated resources 106 to multiple persons or organizations. 108 4. There is a need to assure integrity of the data and distribute the 109 storage of data subsets to multiple repositories. 111 The RIPE effort specificly focused on the first issue and needs of the 112 European community. Its predecessor, the PRDB, addressed the needs of 113 a single organization, the NSF. The RIPE database formats as described 114 in [2] were the basis of the original IRR. 116 Routing protocols themselves provide no assurance that the origination 117 of a route is legitimate and can actually reach the stated destina- 118 tion. The nature of CIDR allows more specific prefixes to override 119 less specific prefixes [9, 15, 8]. Even with signed route origina- 120 tion, there is no way to determine if a more specific prefix is legit- 121 imate and should override a less specific route announcement without a 122 means of determining who is authorized to announce specific prefixes. 123 Failing to do so places no assurance of integrity of global routing 124 information and leaves an opportunity for a very effective form of 125 denial of service attack. 127 The Routing Policy System Language (RPSL) [1, 13] was a fairly sub- 128 stantial evolutionary step in the data representation which was 129 largely targeted at addressing the second group of needs. The PRDB 130 accommodated CIDR in 1993 [12] and the RIPE database accommodated the 131 entry of CIDR prefixes from inception, but RPSL provides many needed 132 improvements including explicit support for aggregation. 134 This document addresses the third group of needs identified above. 136 While the current implementation supporting weak authentication 137 doesn't guarantee integrity of the data, it does provide extensive 138 mechanisms to make sure that all involved parties get notified when 139 a change is made to the database, whether the change was malicious 140 or intended. This provides inadequate protection against additions. 141 Since the software is increasingly used to configure the major parts 142 of the Internet infrastructure, it is not considered to be adequate 143 anymore to know about and have the ability roll back unintended 144 changes. Therefore, more active security mechanisms need to be de- 145 veloped to prevent such problems before they happen. 147 A separate document will be needed to address the fourth group of 148 needs. 150 3 Implicit Policy Assumptions 152 The authorization model encodes certain policies for allocation of 153 address numbers, AS numbers, and for the announcement of routes. Im- 154 plicit to the authorization model is a very limited number of policy 155 assumptions. 157 1. Address numbers are allocated hierarchically. The IANA delegates 158 portions of the address space to the regional registries (currently 159 ARIN, APNIC and RIPE), which in turn delegate address space to 160 their members, who can assign addresses to their customers. 162 2. AS numbers are allocated either singly or in small blocks by reg- 163 istries. Registries are allocated blocks of AS numbers, thereby 164 making the allocation hierarchical. 166 3. Routes should only be announced with the consent of the holder of 167 the origin AS number of the announcement and with the consent of 168 the holder of the address space. 169 4. AS numbers and IP address registries may be different entities from 170 routing registries. 172 For subsets of any of these three allocation spaces, network ad- 173 dresses, AS numbers, and routes, these restrictions may be loosened 174 or disabled by specifying a very weak authorization method or an 175 authentication method of ``none''. However, even when no authenti- 176 cation mechanism is used, all involved parties can be notified about 177 the changes that occurred through use of the existing ``notify'' at- 178 tribute. 180 4 Scope of Security Coverage 182 This document is intended only to provide an authentication and au- 183 thorization model to insure the integrety of the policy data in a reg- 184 istry. Only authetication and authorization of additions, deletions, 185 and changes to the database are within the scope of this document. 186 Authentication and authorization of database queries is explicitly 187 out of scope. Mutual authentication of queries, that is authenticat- 188 ing both the origin of the query and the repository from which query 189 results are obtained, is also out of scope. 191 5 Organization of this Document 193 Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this 194 document. Goals are described in Section 6. Section 7 through Sec- 195 tion 9 provide descriptions of the changes and discussion. Section 10 196 provides a concise summary of data formats and semantics. Appendix C 197 through Appendix E provide additional technical discussion, examples, 198 and deployment considerations. 200 Goals and Requirements Section 6 provides a more detailed descrip- 201 tion of the issues and identifies specific problems that need to 202 be solved, some of which require a degree of cooperation in the 203 Internet community. 205 Data Representation Section 7 provides some characteristics of RPSL 206 and formats for external representations of information. 208 Authentication Model Section 8 describes current practice, proposes 209 additional authentication methods, and describes the extension 210 mechanism if additional methods are needed in the future. 212 Authorization Model Section 9 describes the means of determining 213 whether a transaction contains the authorization needed to add, 214 modify, or delete specific data objects, based on stated authenti- 215 cation requirements in related data objects. 217 Data Format Summaries Section 10 provides a concise reference to 218 the data formats and steps in transaction processing. 220 Technical Discussion Section C contains some discussion of techni- 221 cal tradeoffs. 223 Common Operational Cases Section D provides some examples drawn 224 from past operational experience with the IRR. 226 Deployment Considerations Section E describes some deployment is- 227 sues and discusses possible means of resolution. 229 6 Goals and Requirements 231 The Internet is an open network. This openness and the large scale of 232 the Internet can present operational problems. Technical weaknesses 233 that allow misconfiguration or errant operation in part of the network 234 to propagate globally or which provide potentials for simple denial 235 of service attacks should be eliminated to the extent that it is prac- 236 tical. The integrity of routing information is critical in assuring 237 that traffic goes where it is supposed to. 239 An accidental misconfiguration can direct traffic toward routers that 240 cannot reach a destination for which they are advertising reachabil- 241 ity. This is commonly caused by misconfigured static routes though 242 there are numerous other potential causes. Static routes are often 243 used to provide constant apparent reachability to single homed desti- 244 nations. Some of the largest ISPs literally have thousands of static 245 routes in their networks. These are often entered manually by op- 246 erators. Mistyping can divert traffic from a completely unrelated 247 destination to a router with no actual reachability to the advertised 248 destination. This can happen and does happen somewhat regularly. In 249 addition, implementation bugs or severe misconfigurations that result 250 in the loss of BGP AS path information or alteration of prefix length 251 can result in the advertisement of large sets of routes. Though con- 252 siderably more rare, on a few occasions where this has occurred the 253 results were catastrophic. 255 Where there is the potential for an accidental misconfiguration in 256 a remote part of the Internet affecting the global Internet there is 257 also the potential for malice. For example, it has been demonstrated 258 by accident that multiple hour outages at a major institution can be 259 caused by a laptop and a dial account if proper precautions are not 260 taken. The dial account need not be with the same provider used by 261 the major institution. 263 The potential for error is increased by the CIDR preference for more 264 specific routes [8]. If an institution advertises a single route of 265 a given length and a distant router advertises a more specific route 266 covering critical hosts, the more specific route, if accepted at all, 267 is preferred regardless of administrative weighting or any routing 268 protocol attributes. 270 There is a need to provide some form of checks on whether a route ad- 271 vertisement is valid. Today checks are typically made against the 272 border AS advertising the route. This prevents accepting routes from 273 the set of border AS that could not legitimately advertise the route. 274 Theses checks rely on the use of information registered in the IRR 275 to generate lists of prefixes that could be advertised by a specific 276 border AS. Checks can also be made against the origin AS. If policy 277 information were sufficiently populated, checks could be made against 278 the entire AS path, but this is not yet feasible. 280 The use of a routing registry can also make it more difficult for pre- 281 fixes to be used without authorization such as unallocated prefixes or 282 prefixes allocated to another party. 284 In summary, some of the problems being addressed are: 286 o Localizing the impact of accidental misconfiguration made by Inter- 287 net Providers to that provider's networks only. 289 o Eliminating the potential for an Internet provider's customer to 290 use malicious misconfiguration of routing as a denial of service 291 attack if the provider route filters their customers. Localizing 292 the denial of service to that Internet provider only if the immedi- 293 ate Internet service provider does not route filter their customers 294 but other providers route filter the route exchange at the inter- 295 provider peering. 296 o Eliminating the unauthorized use of address space. 298 If the data within a routing registry is critical, then the ability 299 to change the data must be controlled. Centralized authorities can 300 provide control but centralization can lead to scaling problems (and 301 is politically distasteful). 303 Address allocation and name allocation is already delegated. Since 304 delegation can be to outside registries it is at least somewhat dis- 305 tributed [11]. Autonomous System (AS) numbers are allocated by the 306 same authorities. It makes sense to delegate the routing number space 307 in a manner similar to the address allocation and AS number alloca- 308 tion. The need for this delegation of authority to numerous reg- 309 istries increases the difficulty of maintaining the integrity of the 310 body of information as a whole. 312 As a first step, the database can be somewhat centrally administered 313 with authority granted to many parties to change the information. 314 This is the case with the current IRR. There are a very small number 315 of well trusted repositories and a very large number of parties au- 316 thorized to make changes. Control must be exercised over who can make 317 changes and what changes they can make. The distinction of who vs 318 what separates authentication from authorization. 320 o Authentication is the means to determine who is attempting to make 321 a change. 323 o Authorization is the determination of whether a transaction pass- 324 ing a specific authentication check is allowed to perform a given 325 operation. 327 Different portions of the database will require different methods of 328 authentication. Some applications will require authentication based 329 on strong encryption. In other cases software supporting strong en- 330 cryption may not be necessary or may not be legally available. For 331 this reason multiple authentication methods must be supported, se- 332 lected on a per object basis through the specification of authen- 333 tication methods in the maintainer object ``auth'' attribute. The 334 authentication methods may range from very weak data integrity checks 335 to cryptographicly strong signatures. The authorization model must 336 insure that the use of weak integrity checks in parts of the database 337 does not compromise the overall integrity of the database. 339 Additional requirements are placed on the authorization model if the 340 database is widely distributed with delegations made to parties that 341 may not be trustworthy or whose security practices may be lacking. 342 This problem must be addressed in the authorization model in order to 343 enable later evolution to a more distributed routing registry. 345 Autonomous system numbers can be delegated in blocks and subdelegated 346 as needed and then individual AS numbers assigned. Address alloca- 347 tion is a simple numeric hierarchy. Route allocation is somewhat 348 more complicated. The key attributes in a route object (key with re- 349 gard to making it unique) contain both an address prefix and an AS 350 number, known as the origin AS. The addition of a route object must 351 be validated against the authorization criteria for both the AS and 352 the address prefix. Route objects may exist for the same prefix with 353 multiple origin AS values due to a common multihoming practice that 354 does not require a unique origin AS. There is often no correlation be- 355 tween the origin AS of a prefix and the origin AS of overlapping more 356 specific prefixes. 358 There are numerous operational cases that must be accommodated. Some 359 of the more common are listed below. These are explored in greater 360 detail in Appendix D with discussion of technical tradeoffs in Ap- 361 pendix C. 363 o simple hierarchical address allocation and route allocation 364 o aggregation and multihomed more specific routes 366 o provider independent addresses and multiple origin AS 367 o changing Internet service providers 369 o renumbering grace periods 371 The authorization model must accommodate a variety of policies regard- 372 ing the allocation of address space and cannot mandate the use of any 373 one model. There is no standardization of address allocation policies 374 though guidelines do exist [11, 16]. Whether authorization allows the 375 recovery of address space must be selectable on a per object basis and 376 may differ in parts of the database. This issue is discussed further 377 in Appendix C. 379 7 Data Representation 381 RPSL provides a complete description of the contents of a routing 382 repository [1]. Many RPSL data objects remain unchanged from the 383 RIPE specifications and RPSL references the RIPE-181 specification as 384 recorded in RFC-1786 [2]. RPSL provides external data representation. 385 Data may be stored differently internal to a routing registry. 387 Some database object types or database attributes must be added to 388 RPSL to record the delegation of authority and to improve the authen- 389 tication and authorization mechanisms. These additions are very few 390 and are described in Section 8 and Section 9. 392 Some form of encapsulation must be used to exchange data. The de- 393 facto encapsulation has been the one which the RIPE tools accept, a 394 plain text file or plain text in the body of an RFC-822 formatted mail 395 message with information needed for authentication derived from the 396 mail headers or the body of the message. Merit has slightly modified 397 this using the PGP signed portion of a plain text file or PGP signed 398 portion of the body of a mail message. These very simple forms of 399 encapsulation are suitable for the initial submission of a database 400 transaction. 402 The encapsulation of registry transaction submissions, registry 403 queries and registry responses and exchanges between registries is 404 outside the scope of this document. The encapsulation of registry 405 transaction submissions and exchanges between registries is outside 406 the scope of this document. 408 8 Authentication Model 410 The maintainer objects serve as a container to hold authentication 411 filters. A reference to a maintainer within another object defines 412 authorization to perform operations on the object or on a set of re- 413 lated objects. The maintainer is typically referenced by name in mnt- 414 by attributes of objects. Further details on the use of maintainers 415 are provided in Section 9.1. 417 The maintainer contains one or more ``auth'' attributes. Each 418 ``auth'' attribute begins with a keyword identifying the authenti- 419 cation method followed by the authentication information needed to 420 enforce that method. The PGPKEY method is slightly syntactically 421 different in that the method PGPKEY is a substring. 423 Authentication methods currently supported include the following. 424 Note that pgp-from is being replaced by the pgpkey (see Section 10 and 425 [18]). 427 mail-from This is a very weak authentication check and is discour- 428 aged. The authentication information is a regular expression over 429 ASCII characters. The maintainer is authenticated if the from or 430 reply-to fields in RFC-822 mail headers are matched by this regular 431 expression. Since mail forgery is quite easy, this is a very weak 432 form of authentication. 434 crypt-pw This is another weak form of authentication. The authenti- 435 cation information is a fixed encrypted password in UNIX crypt for- 436 mat. The maintainer is authenticated if the transaction contains 437 the clear text password of the maintainer. Since the password 438 is in clear text in transactions, it can be captured by snooping. 439 Since the encrypted form of the password is exposed, it is subject 440 to password guessing attacks. 441 pgp-from This format is being replaced by the ``pgpkey'' so that the 442 public key certificate will be available to remote repositories. 443 This is Merit's PGP extension. The authentication information 444 is a signature identity pointing to an external public key ring. 445 The maintainer is authenticated if the transaction (currently PGP 446 signed portion of a mail message) is signed by the corresponding 447 private key. 449 pgpkey This keyword takes the form ``PGPKEY-hhhhhhhh'', where ``hh- 450 hhhhhh'' is the hex representation of the four byte id of the PGP 451 public key used for authentication. The public key certificate is 452 stored in a separate object as described in [18]. 454 Repositories may elect to disallow the addition of ``auth'' attributes 455 specifying weaker forms of authentication and/or disallow their use 456 in local transaction submissions. Repositories are encouraged to dis- 457 allow the addition of ``auth'' attributes with the deprecated ``pgp- 458 from'' method. 460 Any digital signature technique can in principle be used for authen- 461 tication. Transactions should be signed using multiple digital sig- 462 nature techniques to allow repositories or mirrors that only use a 463 subset of the techniques to verify at least one of the signatures. 464 The selection of digital signature techniques is not within the scope 465 of this document. 467 9 Authorization Model 469 The authorization model must accommodate the requirements outlined 470 in Section 6. A key feature of the authorization model is the recog- 471 nition that authorization for the addition of certain types of data 472 objects must be derived from related data objects. 474 With multiple repositories, objects not found in RPSL are needed to 475 control AS delegations and new attributes are needed in existing ob- 476 jects to control subdelegation. The definition of RPSL objects used 477 to implement a distrubuted routing registry system is not within the 478 scope of this document. 480 9.1 Maintainer Objects 482 The maintainer objects serve as a container to hold authentication 483 filters. The authentication methods are described in Section 8. The 484 maintainer can be referenced by name in other objects, most notably in 485 the mnt-by attributes of those objects. 487 Maintainers themselves contain mnt-by attributes. In some cases the 488 mnt-by in a maintainer will reference the maintainer itself. In this 489 case, authorization to modify the maintainer is provided to a (usu- 490 ally very limited) set of identities. A good practice is to create 491 a maintainer containing a long list of identities authorized to make 492 specific types of changes but have the maintainer's mnt-by attribute 493 reference a far more restrictive maintainer more tightly controlling 494 changes to the maintainer object itself. 496 The mnt-by attribute is mandatory in all objects. Some data already 497 exists without mnt-by attributes. A missing mnt-by attribute is in- 498 terpreted as the absence of any control over changes. This is highly 499 inadvisable and most repositories will no longer allow this. 501 An additional maintainer reference can occur through a new attribute, 502 ``mnt-routes'', and is used in aut-num, inetnum and route objects. 503 The ``mnt-routes'' attribute is an extension to RPSL and is described 504 in detail in Section 10. 506 A mnt-routes attribute in an aut-num object allows addition of route 507 objects with that AS number as the origin to the maintainers listed. 508 A mnt-routes attribute in an inetnum object allows addition of route 509 objects with exact matching or more specific prefixes. A mnt-routes 510 attribute in a route object allows addition of route objects with ex- 511 act matching or more specific prefixes. A mnt-routes attribute does 512 not allow changes to the aut-num, inetnum, or route object where it 513 appears. A mnt-routes may optionally be constrained to only apply to 514 a subset of more specific routes. 516 Where ``mnt-routes'' or ``mnt-lower'' are applicable, any maintainer 517 referenced in the ``mnt-by'' still apply. The set of applicable main- 518 tainers for whatever check is being made is the union of the ``mnt- 519 routes'' or ``mnt-lower'' and the ``mnt-by''. For example, when au- 520 thorizing a route object software would look at ``mnt-routes'', if it 521 does not exist, look at ``mnt-lower'', if that does not exist look at 522 ``mnt-by''. 524 9.2 as-block and aut-num objects 526 An ``as-block'' object is needed to delegate a range of AS numbers to 527 a given repository. This is needed for authorization and it is needed 528 to avoid having to make an exhaustive search of all repositories to 529 find a specific AS. This search would not be an issue now but would 530 be if a more distributed routing repository is used. Distributed 531 registry issues are not within the scope of this document. 533 The ``as-block'' object also makes it possible to separate AS number 534 allocation from registration of AS routing policy. 536 as-block: AS1321 - AS1335 537 ... 539 The ``aut-num'' describes the routing policy for an AS and is criti- 540 cal for router configuration of that AS and for analysis performed by 541 another AS. For the purpose of this document it is sufficient to con- 542 sider the aut-num solely as a place holder identifying the existence 543 of an AS and providing a means to associate authorization with that AS 544 when adding ``route'' objects. 546 The ``as-block'' object is proposed here solely as a means of record- 547 ing the delegation of blocks of AS numbers to alternate registries and 548 in doing so providing a means to direct queries and a means to support 549 hierarchical authorization across multiple repositories. 551 9.3 inetnum objects 553 The ``inetnum'' exists to support address allocation. For external 554 number registries, such as those using ``[r]whoisd[++]'' the ``inet- 555 num'' can serve as a secondary record that is added when an address 556 allocation is made in the authoritative database. Such records could 557 be added by a address registry such as ARIN as a courtesy to the cor- 558 responding routing registry. 560 inetnum: 193.0.0.0 - 193.0.0.255 561 ... 562 source: IANA 564 9.4 route objects 566 Currently there are a quite few route objects in more than one reg- 567 istry. Quite a few are registered with an origin AS for which they 568 have never been announced. There is a legitimate reason to be in more 569 than one origin AS. 571 The ``route'' object is used to record routes which may appear in the 572 global routing table. Explicit support for aggregation is provided. 573 Route objects exist both for the configuration of routing information 574 filters used to isolate incidents of erroneous route announcements 575 (Section 6) and to support network problem diagnosis. 577 9.5 reclaim and no-reclaim attributes 579 A reclaim attribute is needed in as-block, inetnum and route objects. 580 The reclaim attribute allows a control to be retained over more spe- 581 cific AS, IP address or route space by allowing modify and delete 582 privileges regardless of the mnt-by in the object itself. 584 The reclaim attribute provides the means to enforce address lending. 585 It allows cleanup in cases where entities cease to exist or as a last 586 resort means to correct errors such as parties locking themselves out 587 of access to their own objects. To specify all more specific objects 588 the reclaim attribute value should be ``ALL''. To allow finer control 589 a set of prefixes can be specified. 591 A no-reclaim attribute can be used to provide explicit exceptions. A 592 reclaim attribute can only be added to an existing object if the ad- 593 dition of the reclaim attribute does not remove autonomy of existing 594 more specific objects that are covered by the new reclaim attribute. 596 1. A reclaim attribute can be added to an existing object if there are 597 no existing exact matches or more specific objects overlapped by 598 the new reclaim attribute, or 600 2. if the submitter is listed in the maintainer pointed to by the mnt- 601 by of the objects which are overlapped, or 603 3. if any overlapped object is listed in a no-reclaim attribute in the 604 object where the reclaim is being added. 606 Similarly, a submitter may delete a no-reclaim attribute from an ob- 607 ject only when that submitter is the only maintainer listed in the 608 mnt-by attributes of any overlapped objects. If the submitter is not 609 listed in any of the maintainers pointed to by the mnt-by attributes 610 for one or more overlapped object, then the submitter is not permitted 611 to delete the no-reclaim attribute. 613 If neither a reclaim or no-reclaim attribute is present, then more 614 specific objects of a given object cannot be modified by the main- 615 tainer of the less specified object unless the maintainer is also 616 listed as a maintainer in the more specific object. However, the ad- 617 dition of a new route or inetnum object must pass authentication of 618 the largest less specific prefix as part of the authentication check 619 described in Section 9.9. 621 See Section 10 for a full description of the reclaim and no-reclaim 622 attributes. 624 9.6 Other Objects 626 Many of the RPSL ancillary objects have no natural hierarchy the way 627 AS numbers, Internet addresses and routes do have a numeric hierarchy. 628 Some examples are ``maintainers'', ``people'' and ``role'' objects. 629 For these objects, lack of any hierarchy leads to two problems. 631 1. There is no hierarchy that can be exploited to direct queries to 632 alternate registries. At some point the query strategy of search- 633 ing all known registries becomes impractical. 635 2. There is no hierarchy on which authorizations of additions can be 636 based. 638 The first problem can be addressed by considering the name space 639 for each of the ancillary objects to be unique only within the lo- 640 cal database and to use explicit references to an external repository 641 where needed. To specify an external repository reference, the ob- 642 ject key is preceded by the name of the repository and the delimiter 643 ``::''. For example a NIC handle may take the form ``RIPE::CO19''. 644 Currently there is a desire to keep NIC handles unique so the nam- 645 ing convention of appending a dash and the repository name is used. 646 Prepending the repository name provides the unique name space since an 647 object in the RIPE database referencing ``CO19'' would be interpreted 648 as ``RIPE::CO19'' by default, but it would still be possible to query 649 or reference ``IANA::CO19''. There is no possibility of accidentally 650 forgetting to adhere to the conventions when making an addition and 651 the existing objects are accommodated, including cases where name 652 conflicts have already occurred. 654 The second problem can be partially addressed by using a referral 655 system for the addition of maintainers and requiring that any other 656 object be submitted by a registered maintainer. The referral system 657 would allow any existing maintainer to add another maintainer. This 658 can be used in parallel with the addition of other object types to 659 support the maintenance of those objects. For example, when adding 660 a subdomain to the ``domain'' hierarchy (in the RIPE repository where 661 domains are also handled), even when adding a new domain to a rela- 662 tively flat domain such as ``com'', there is already a maintainer for 663 the existing domain. The existing maintainer can add the maintainer 664 that will be needed for the new domain in addition to adding the new 665 domain and giving the new maintainer the right to modify it. 667 An organization gaining a presence on the Internet for the first time 668 would be given a maintainer. This maintainer may list a small number 669 of very trusted employees that are authorized to modify the maintainer 670 itself. The organization itself can then add another maintainer list- 671 ing a larger set of employees but listing the more restrictive main- 672 tainer in the mnt-by attributes of the maintainers themselves. The 673 organization can then add people and role objects as needed and any 674 other objects as needed and as authorization permits. 676 9.7 Objects with AS Hierarchical Names 678 Many RPSL objects do not have a natural hierarchy of their own but al- 679 low hierarchical names. Some examples are the object types ``as-set'' 680 and ``route-set''. An as-set may have a name corresponding to no nam- 681 ing hierarchy such as ``AS-Foo'' or it may have a hierarchical name of 682 the form ``AS1:AS-Bar''. 684 When a hierarchical name is not used, authorization for objects such 685 as ``as-set'' and ``route-set'' correspond to the rules for objects 686 with no hierarchy described in Section 9.6. 688 If hierarchical names are used, then the addition of an object must 689 be authorized by the aut-num whose key is named by everything to the 690 left of the rightmost colon in the name of the object being added. 691 Authorization is determined by first using the mnt-lower maintainer 692 reference, or if absent, using the mnt-by reference. 694 9.8 Query Processing 696 A query may have to span multiple repositories. All queries should 697 be directed toward a local repository which may mirror the root repos- 698 itory and others. Currently each IRR repository mirrors all other 699 repositories. In this way, the query may be answered by the local 700 repository but draw data from others. 702 The mechanism below when applied to multiple repositories assumes the 703 existence of an attribute for traversal of the repositories. The def- 704 inition of this attribute is considered a distributed registry issue 705 and is out of scope of this document. 707 For object types that have a natural hierarchy, such as aut-num, inet- 708 num, and route, the search begins at the root database and follows 709 the hierarchy. For objects types that have no natural hierarchy, such 710 as maintainer, person, and role objects, the search is confined to a 711 default database unless a database is specified. The default database 712 is the same database as an object from which a reference is made if 713 the query is launched through the need to follow a reference. Other- 714 wise the default is generally the local database or a default set by 715 the repository. The default can be specified in the query itself as 716 described in Section 9.7. 718 In the absense of attributes to traverse multiple registries a search 719 of all repositories is needed. With such attributes the search would 720 proceed as follows. In searching for an AS, the delegation attribute 721 in AS blocks can be consulted, moving the search to data from other 722 repositories. Eventually the AS is either found or the search fails. 723 The search for an inetnum is similar. Less specific inetnums may 724 refer the search to other databases. Eventually the most specific 725 inetnum is found and its status (assigned or not assigned) can be de- 726 termined. The definition of attributes for traversal of repositories 727 is considered a distrbiuted registry issue and is not within the scope 728 of this document. 730 The search for a route in the presence of attributes for the traver- 731 sal of multiple registries is similar except the search may branch to 732 more than one repository. The most specific route in one repository 733 may be more specific than the most specific in another. In looking 734 for a route object it makes sense to return the most specific route 735 that is 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 9.9 Adding to the Database 741 The mechanism below when applied to multiple repositories assumes the 742 existence of an attribute for traversal of the repositories. The def- 743 inition of this attribute is considered a distributed registry issue 744 and is out of scope of this document. 746 The root repository must be initially populated at some epoch with a 747 few entries. An initial maintainer is needed to add more maintain- 748 ers. The referral-by attribute can be set to refer to itself in this 749 special case (Section 10 describes the referral-by). When adding an 750 inetnum or a route object an existing exact match or a less specific 751 overlap must exist. A route object may be added based on an exact 752 match or a less specific inetnum. The root repository must be ini- 753 tially populated with the allocation of an inetnum covering the prefix 754 0/0, indicating that some address allocation authority exists. Simi- 755 larly an initial as-block is needed covering the full AS number range. 757 When adding an object with no natural hierarchy, the search for an 758 existing object follows the procedure outlined in Section 9.8. 760 When adding an aut-num (an AS), the same procedure used in a query is 761 used to determine the appropriate repository for the addition and to 762 determine which maintainer applies. The sequence of AS-block objects 763 and repository delegations is followed. If the aut-num does not ex- 764 ist, then the submission must match the authentication specified in 765 the maintainer for the most specific AS-block in order to be added. 767 The procedure for adding an inetnum is similar. The sequence of inet- 768 num blocks is followed until the most specific is found. The submis- 769 sion must match the authentication specified in the maintainer for the 770 most specific inetnum overlapping the addition. 772 Adding a route object is somewhat more complicated. The route object 773 submission must satisfy two authentication criteria. It must match 774 the authentication specified in the aut-num and the authentication 775 specified in either a route object or if no applicable route object is 776 found, then an inetnum. 778 An addition is submitted with an AS number and prefix as its key. If 779 the object already exists, then the submission is treated as a modify 780 (see Section 9.10). If the aut-num does not exist on a route add, 781 then the addition is rejected (see Section C for further discussion 782 of tradeoffs). If the aut-num exists then the submission is checked 783 against the applicable maintainer. A search is then done for the 784 prefix first looking for an exact match. If the search for an exact 785 match fails, a search is made for the longest prefix match that is 786 less specific than the prefix specified. If this search succeeds it 787 will return one or more route objects. The submission must match an 788 applicable maintainer in at least one of these route objects for the 789 addition to succeed. If the search for a route object fails, then 790 a search is performed for an inetnum that exactly matches the prefix 791 or for the most specific inetnum that is less specific than the route 792 object submission. The search for an inetnum should never fail but it 793 may return an unallocated or reserved range. The inetnum status must 794 be ``allocated'' and the submission must match the maintainer. 796 Having found the AS and either a route object or inetnum, the autho- 797 rization is taken from these two objects. The applicable maintainer 798 object is any referenced by the mnt-routes attributes. If one or more 799 mnt-routes attributes are present in an object, the mnt-by attributes 800 are not considered. In the absence of a mnt-routes attribute in a 801 given object, the mnt-by attributes are used for that object. The 802 authentication must match one of the authorizations in each of the two 803 objects. 805 If the addition of a route object or inetnum contains a reclaim at- 806 tribute, then any more specific objects of the same type must be ex- 807 amined. The reclaim attribute can only be added if there are no more 808 specific overlaps or if the authentication on the addition is present 809 in the authorization of a less specific object that already has a re- 810 claim attribute covering the prefix range, or if the authentication on 811 the addition is authorized for the modification of all existing more 812 specific prefixes covered by the addition. 814 9.10 Modifying or Deleting Database Objects 816 When modifying or deleting any existing object a search for the object 817 is performed as described in Section 9.8. If the submission matches 818 an applicable maintainer for the object, then the operation can pro- 819 ceed. An applicable maintainer for a modification is any maintainer 820 referenced by the mnt-by attribute in the object. For route and inet- 821 num objects an applicable maintainer may be listed in a less specific 822 object with a reclaim attribute. 824 If the submission is for a route object, a search is done for all 825 less specific route objects and inetnums. If the submission is for 826 an inetnum, a search is done for all less specific inetnums. If the 827 submission fails the authorization in the object itself but matches 828 the reclaim attribute in any of the less specific objects, then the 829 operation can proceed. Section C contains discussion of the rationale 830 behind the use of the reclaim attribute. 832 A modification to an inetnum object that adds a reclaim attribute 833 or removes a no-reclaim attribute must be checked against all exist- 834 ing inetnums that are more specific. The same check of the reclaim 835 attribute that is made during addition must be made when a reclaim 836 attribute is added by a modification (see Section 9.9). 838 A deletion is considered a special case of the modify operation. The 839 deleted object may remain in the database with a ``deleted'' at- 840 tribute in which case the mnt-by can still be consulted to remove 841 the ``deleted'' attribute. 843 10 Data Format Summaries 845 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII 846 text. Objects consist of a set of attributes. Attributes are name 847 value pairs. A single attribute is represented as a single line with 848 the name followed by a colon followed by whitespace characters (space, 849 tab, or line continuation) and followed by the value. Within a value 850 all whitespace is equivalent to a single space. Line continuation is 851 supported by a backslash at the end of a line or the following line 852 beginning with whitespace. When transferred, externally attributes 853 are generally broken into shorter lines using line continuation though 854 this is not a requirement. An object is externally represented as a 855 series of attributes. Objects are separated by blank lines. 857 There are about 80 attribute types in the current RIPE schema and 858 about 15 object types. Some of the attributes are mandatory in cer- 859 tain objects. Some attributes may appear multiple times. One or 860 more attributes may form a key. Some attributes or sets of attributes 861 may be required to be unique across all repositories. Some of the 862 attributes may reference a key field in an object type and may be 863 required to be a valid reference. Some attributes may be used in 864 inverse lookups. 866 A review of the entire RIPE or RPSL schema would be too lengthy to 867 include here. Only the differences in the schema are described. 869 10.1 Changes to the RIPE/RPSL Schema 871 One new object type and several attributes are added to the RIPE/RPSL 872 schema. There are significant changes to the rules which determine if 873 the addition of an object is authorized. 875 The new object type is listed below. The first attribute listed is 876 the key attribute and also serves as the name of the object type. 878 as-block key mandatory single unique 879 descr optional multiple 880 remarks optional multiple 881 admin-c mandatory multiple 882 tech-c mandatory multiple 883 notify optional multiple 884 mnt-by mandatory multiple 885 changed mandatory multiple 886 source mandatory single 888 In the above object type only the key attribute ``as-block'' is new: 890 as-block This attribute provides the AS number range for an ``as- 891 block'' object. The format is two AS numbers including the sub- 892 string ``AS'' separated by a ``-'' delimiter and optional whites- 893 pace before and after the delimiter. 895 In order to support stronger authentication, the following keywords 896 are added to the ``auth'' attribute: 898 pgp-from The remainder of the attribute gives the string identify- 899 ing a PGP identity whose public key is held in an external keyring. 900 The use of this method is deprecated in favor of the ``pgpkey'' 901 method. 903 pgpkey See [18]. 905 In order to disable authentication and give permission to anyone, the 906 authentication method ``none'' is added. It has no arguments. 908 An additional change is the ``auth'' attribute is allowed to exist 909 in a ``person'' or ``role'' object. The ``auth'' method ``role'' or 910 ``person'' can be used to refer to a role or person object and take 911 the ``auth'' fields from those objects. Care must be taken in imple- 912 mentations to detect circular references and terminate expansion or 913 the references already visited. 915 A few attributes are added to the schema. These are: 917 mnt-routes The mnt-routes attribute may appear in an aut-num, inet- 918 num, or route object. This attribute references a maintainer ob- 919 ject which is used in determining authorization for the addition of 920 route objects. After the reference to the maintainer, an optional 921 list of prefix ranges (as defined in RPSL) inside of curly braces 922 or the keyword ``ANY'' may follow. The default, when no additional 923 set items are specified is ``ANY'' or all more specifics. The mnt- 924 routes attribute is optional and multiple. See usage details in 925 Section 9.1. 927 mnt-lower The mnt-lower attribute may appear in an inetnum, route, 928 as-block or aut-num object. This attribute references a maintainer 929 object. When used in an inetnum or route object the effect is the 930 same as a ``mnt-routes'' but applies only to prefixes more specific 931 than the prefix of the object in which it is contained. In an as- 932 block object, mnt-lower allows addition of more specific as-block 933 objects or aut-num objects. In an aut-num object the mnt-lower at- 934 tribute specifies a maintainer that can be used to add objects with 935 hierarchical names as described in Section 9.7. 937 reclaim The reclaim attribute may appear in as-block, aut-num, inet- 938 num, or route objects. Any object of the same type below in the 939 hierarchy may be modified or deleted by the maintainer of the ob- 940 ject containing a reclaim attribute. The value of the attribute is 941 a set or range of objects of the same type where the syntax of the 942 set or range is as defined in RPSL. See Section 9.5 for restric- 943 tions on adding reclaim attributes. 944 no-reclaim The no-reclaim attribute is used with the reclaim at- 945 tribute. The no-reclaim attribute negates any reclaim attribute it 946 overlaps. See Section 9.5 for restrictions on deleting no-reclaim 947 attributes. 949 referral-by This attribute is required in the maintainer object. It 950 may never be altered after the addition of the maintainer. This 951 attribute refers to the maintainer that created this maintainer. 952 It may be multiple if more than one signature appeared on the 953 transaction creating the object. 955 auth-override An auth-override attribute can be added, deleted, or 956 changed by a transaction submitted by maintainer listed in the 957 referral-by. An auth-override can only be added to a maintainer 958 if that maintainer has been inactive for the prior 60 days. The 959 auth-override attribute itself contains only the date when the at- 960 tribute will go into effect which must be at least 60 days from the 961 current date unless there is already authorization to modify the 962 maintainer. After the date in the auth-override is reached, those 963 identified by the maintainer in the referral-by have authoriza- 964 tion to modify the maintainer. This attribute exists as a means to 965 clean up should the holder of a maintainer become unresponsive and 966 can only take effect if that maintainer does not remove the auth- 967 override in response to the automatic notification that occurs on 968 changes. 970 The existing ``mnt-by'' attribute references the ``maintainer'' ob- 971 ject type. The ``mnt-by'' attribute is now mandatory in all object 972 types. A new maintainer may be added by any existing maintainer. The 973 ``referral-by'' attribute is now mandatory in the ``maintainer'' ob- 974 ject to keep a record of which maintainer made the addition and can 975 never be changed. Maintainers cannot be deleted as long as they are 976 referenced by a ``referral-by'' attribute elsewhere. 978 A Core and Non-Core Functionality 980 Most of the objects and attributes described in this document are 981 essential to the authorization framework. These are referred to as 982 being part of the ``core'' functionality. A few attributes listed 983 here are considered ``non-core''. 985 The ``reclaim'' and ``no-reclaim'' attributes are a convenience to 986 support flexibility in the implementation of address lending. 988 The ``auth-override'' attribute is a convenience to facilitate recov- 989 ery in an environment where repository data is redistributed in any 990 way. 992 The ``referal-by'' attribute is a ``core'' feature. An individual 993 registry may express its sutonomy by creating a self-referencing main- 994 tainer, one whose ``referal-by'' points to itslef. Other registries 995 can decide on a case by case basis whether to consider such an entry 996 valid. A registry may only allow the ``referal-by'' to refer to a 997 specific maintainer under the control of the registry. This further 998 restriction is an issue that is purely local to the registry. 1000 B Examples 1002 The examples below leave out some required attributes that are not 1003 needed to illustrate the use of the objects and attributes described 1004 in this document. Missing are admin-c, tech-c, changed, source. Also 1005 missing are attributes such as mnt-nfy, whose use are a good practice 1006 but are not strictly required. 1008 To do anything at all a maintainer is needed. At some epoch a a sin- 1009 gle maintainer is populated in one repository and that maintianer has 1010 a referal-by pointing to itself. All others referal-by references 1011 can be traced back to that maintainer. At the epoch the as-block AS0- 1012 AS65535 and the inetnum 0.0.0.0-255.255.255.255 are also allocated. 1013 Other ancilliary object may also be needed to bootstrap. 1015 mntner: ROOT-MAINTAINER 1016 auth: pgpkey PGP-12345678 1017 mnt-by: ROOT-MAINTAINER 1018 referal-by: ROOT-MAINTAINER 1020 This root maintainer might add a top level maintainer for some organi- 1021 zation. 1023 mntner: WIZARDS 1024 descr: High level Technical Folks 1025 auth: pgpkey PGP-23456789 1026 auth: pgpkey PGP-3456789a 1027 mnt-by: WIZARDS 1028 referal-by: ROOT-MAINTAINER 1030 That maintainer might add another who have more limited capabilities. 1032 mntner: MORTALS 1033 descr: Maintain day to day operations 1034 auth: pgpkey PGP-456789ab 1035 auth: pgpkey PGP-56789abc 1036 auth: pgpkey PGP-6789abcd 1037 mnt-by: WIZARDS 1038 referal-by: WIZARDS 1040 Note that the WIZARDS can change their own maintainer object and the 1041 MORTALS maintainer object but MORTALS cannot. 1043 At some point an as-block is allocated and broken down. In the exam- 1044 ple below, private number space is used. 1046 as-block: AS65500-AS65510 1047 mnt-by: SOME-REGISTRY 1048 mnt-lower: WIZARDS 1050 Note that a registry has control over the object that they have cre- 1051 ated representing the allocation, but have given the party to which 1052 the allocation was made the ability to create more specific objects. 1053 Below this as-block, an aut-num is added. Note that import and export 1054 are normally required for a aut-num but are not shown here. 1056 aut-num: AS65501 1057 mnt-by: WIZARDS 1058 mnt-lower: MORTALS 1060 In aut-num above the WIZARDS maintainer can modify the aut-num itself. 1061 The MORTALS maintainer can add route objects using this AS as the ori- 1062 gin if they also have authorization for the IP number space in a less 1063 specific route or inetnum. 1065 We also need an inetnum allocation. In this example the inetnum is 1066 allocated to a completely different organization. Again attributes 1067 are omited which would normally be needed in an inetnum. 1069 inetnum: 192.168.144.0-192.168.151.255 1070 mnt-by: SOME-REGISTRY 1071 mnt-lower: ISP 1072 reclaim: ALL 1074 The maintainer ISP can add more specific inetnums or routes with this 1075 address space. Note that the registry has declared their ability to 1076 reclaim the address space. 1078 If ISP wished to reclaim all allocations but some suballocation of 1079 theirs resisted, we might get something like the following in which 1080 they will reclaim only the top half of an allocation (possibly if it 1081 remains unused). 1083 inetnum: 192.168.144.0-192.168.147.255 1084 mnt-by: ISP 1085 mnt-lower: EBG-COM 1086 reclaim: 192.168.146/23+ 1088 If we assume that the maintainer EBG-COM and the maintainer MORTALS 1089 want to add a route object, one way to do it is for both parties to 1090 sign. If EBG-COM for some reason couldn't aggregate an allocate a 1091 single top level route (which is inexcusable these days) or there was 1092 a preference for some reason to avoid the joint signature approach on 1093 a submission either party could give the other permission to make the 1094 addition. A mnt-routes could be added to the aut-num or a mnt-lower 1095 could be added to an inetnum. 1097 aut-num: AS65501 1098 mnt-by: WIZARDS 1099 mnt-lower: MORTALS 1100 mnt-routes: EBG-COM {192.168.144/23} 1102 With this change to the aut-num the maintainer EBG-COM could add a 1103 route with origin AS65501, but only with a limited address range. 1105 route: 192.168.144/24 1106 origin: AS65501 1107 descr: These boneheads don't aggregate 1108 mnt-by: EBG-COM 1109 mnt-by: FICTION::MORTALS 1111 Note that while the maintainer EBG-COM added the object they allowed 1112 the maintainer MORTALS the ability to modify it. 1114 If an object ended up in another repository, a single maintainer could 1115 still be used. In the example above the notation FICTION::MORTALS in- 1116 dicates that the route object is in a different repository and rather 1117 than duplicate the maintainer, a reference is made to the repository 1118 in which the MORTALS object resides. 1120 In the example below, a pair of route-sets are added and hierarchical 1121 names are used. 1123 route-set: AS65501:Customers 1124 mnt-by: WIZARDS 1125 mnt-lower: MORTALS 1127 route-set: AS65501:Customers:EBG-COM 1128 mnt-by: MORTALS 1129 mnt-lower: EBG-COM 1131 Suppose in the 192.168.144/24 object above, only the EBG-COM main- 1132 tainer is listed. If EBG-COM goes bankrupt, no longer needs address 1133 space, and stops responding, it could be difficult to delete this 1134 object. The maintainer listed in the EBG-COM referral-by attribute 1135 could be contacted. They could add a auth-override attribute to the 1136 EBG-COM object. Later they could modify the EBG-COM object and then 1137 any objects with EBG-COM in the mnt-by. 1139 mntner: EBG-COM 1140 mnt-by: EBG-COM 1141 auth-override: 19990401 1143 The examples above stray significantly from realism. They do provide 1144 simple illustrations of the usage of the objects type and attributes 1145 described in this document and hopefully in doing some are of some 1146 value. 1148 C Technical Discussion 1150 A few design tradeoffs exist. Some of these tradeoffs, the selected 1151 solution, and the alternatives are discussed here. Some of the issues 1152 are listed below. 1154 1. Whether to err on the side of permissiveness and weaken autho- 1155 rization controls or risk the possibility of erecting barriers to 1156 registering information. 1158 2. Whether to support enforcible address lending or provide the 1159 smaller or end user with ultimate control over the registration 1160 of the prefixes they are using. 1162 3. What to do with older objects that either don't conform to newer 1163 requirements regarding minimum authorization, authentication, and 1164 accountability, or are of questionable validity. 1166 C.1 Relaxing requirements for ease of registry 1168 If the requirement that an aut-num exists is relaxed, then it is pos- 1169 sible for anyone to make use of an unassigned AS number or make use 1170 of an assigned AS number for which the aut-num has not been entered. 1171 Placing requirements on the entry of aut-num presumes cooperation of 1172 the Internet address allocation authority (if separate from the rout- 1173 ing registry). The address allocation authority must be willing to 1174 field requests to populate skeleton aut-nums from the party for which 1175 the allocation has been made. These aut-num must include a reference 1176 to a maintainer. A request to the address allocation authority must 1177 therefore include a reference to an existing maintainer. 1179 The ability to add route objects is also tied to the existence of less 1180 specific route objects or inetnums. The Internet address allocation 1181 authority (if separate from the routing registry) must also be will- 1182 ing to field requests to add inetnum records for the party already 1183 allocated the address space. 1185 The Internet address allocation authority should also add inetnums and 1186 aut-nums for new allocations. In order to do so, a maintainer must 1187 exist. If a party is going to connect to the Internet, they can get a 1188 maintainer by making a request to the Internet service provider they 1189 will be connecting to. Once they have a maintainer they can make a 1190 request for address space or an AS number. The maintainer can con- 1191 tain a public key for a cryptographicly strong authorization method 1192 or could contain a ``crypt-key'' or ``mail-to'' authorization check if 1193 that is considered adequate by the registering party. Furthermore an 1194 address allocation authority should verify that the request for an AS 1195 number or for address space matches the authorization criteria in the 1196 maintainer. 1198 Currently only the registries themselves may add maintainers. This 1199 becomes a problem for the registry, particularly in verifying public 1200 keys. This requirement is relaxed by allowing existing maintainers to 1201 add maintainers. Unfortunately the accountability trail does not ex- 1202 ist for existing maintainers. The requirement then should be relaxed 1203 such that existing maintainers may remain but only existing maintain- 1204 ers that have a ``referral-by'' attribute can add maintainers. The 1205 ``referral-by'' cannot be modified. This requirement can be relaxed 1206 slightly so that a ``referral-by'' can be added to a maintainer by 1207 an existing maintainer with a ``referral-by''. This will allow the 1208 accountability trail to be added to existing maintainers and these 1209 maintainers can then add new maintainers. 1211 Verifying that a party is who they claim to be on initial addition, 1212 is one of the problems that currently falls upon the AS number and 1213 address registry. This problem is reduced by allowing existing main- 1214 tainers to add maintainers. This may actually make it easier to get 1215 maintainers and therefore easier to register. The number authority 1216 still must verify that the AS or address space is actually needed by 1217 the party making a request. 1219 Authorization checks made during the addition of route objects that 1220 refer to AS objects and inetnums strongly rely on the cooperation of 1221 the Internet address allocation authorities. The number authorities 1222 must register as-blocks, aut-nums, or inetnums as AS numbers or ad- 1223 dress space is allocated. If only a subset of the number authorities 1224 cooperate, then either an inetnum or as-block can be created cover- 1225 ing the space that registry allocates and essentially requiring null 1226 allocation (for example a ``crypt-pw'' authentication where the pass- 1227 word is given in the remarks in the object or its maintainer) or those 1228 obtaining addresses from that number authority will have trouble reg- 1229 istering in the routing registry. The authorization model supports 1230 either option, though it would be preferable if the number authorities 1231 cooperated and the issue never surfaced in practice. 1233 The maintainer requirements can be relaxed slightly for existing main- 1234 tainers making it easier to register. Relaxing requirements on other 1235 objects may defeat the authorization model, hence is not an option. 1237 C.2 The address lending issue 1239 The issue of whether lending contracts should be enforcible is an 1240 issue of who should ultimately be able to exercise control over al- 1241 locations of address space. The routing registry would be wise to 1242 stay as neutral as possible with regard to disputes between third par- 1243 ties. The ``reclaim'' and ``no-reclaim'' are designed to allow either 1244 outcome to the decision as to whether the holder of a less specific 1245 inetnum or route object can exercise control over suballocations in 1246 the registry. The routing registry itself must decide whether to re- 1247 tain control themselves and if so, should very clearly state under 1248 what conditions the registry would intervene. A registry could even 1249 go to the extreme of stating that they will intervene in such a dis- 1250 pute only after the dispute has been resolved in court and a court 1251 order has been issued. 1253 When an allocation is made by a registry, the registry should keep a 1254 ``reclaim'' attribute in the less specific object and make a strong 1255 policy statement that the reclaim privilege will not be used except 1256 under very clearly defined special circumstances (which at the very 1257 minimum would include a court order). If the allocation is further 1258 subdivided the party subdividing the allocation and the party accept- 1259 ing the suballocation must decide whether a ``reclaim'' can be kept by 1260 the holder of the less specific allocation or whether a ``no-reclaim'' 1261 must be added transferring control to the holder of the more specific. 1262 The registry is not involved in that decision. Different pairs of 1263 third parties may reach different decisions regarding the ``reclaim'' 1264 and any contractual restrictions on its use that may be expressed out- 1265 side of the registry in the form of a legal contract and ultimately 1266 resolved by the courts in the event of a bitter dispute. 1268 By retaining ``reclaim'' rights the registry retains the ability to 1269 abide by a court order. This may only truly become an issue in a dis- 1270 tributed registry environment where registries will be rechecking the 1271 authorization of transactions made elsewhere and may fail to process 1272 the attempt of another registry to abide by a court order by overrid- 1273 ing normal authorization to change the registry contents if a reclaim 1274 is not present. 1276 C.3 Dealing with non-conformant or questionable older data 1278 Some of the newer requirements include requiring that all objects 1279 reference a maintainer object responsible for the integrity of the 1280 object and requiring accountability for the creation of maintainers 1281 to be recorded in the maintainer objects so that accountability can 1282 be traced back from an unresponsive maintainer. In the event that 1283 contact information is absent or incorrect from objects and there is 1284 any question regarding the validity of the objects, the maintainer can 1285 be contacted. If the maintainer is unresponsive, the maintainer that 1286 authorized the addition of that maintainer can be contacted to either 1287 update the contact information on the maintainer or confirm that the 1288 entity no longer exists or is no longer actively using the Internet or 1289 the registry. 1291 Many route objects exist for which there are no maintainers and for 1292 which inetnum and AS objects do not exist. Some contain the now obso- 1293 leted guardian attribute rather than a mnt-by. 1295 It is not practical to unconditionally purge old data that does not 1296 have maintainers or does not conform to the authorization hierarchy. 1297 New additions must be required to conform to the new requirements 1298 (otherwise the requirements are meaningless). New requirements can 1299 be phased in by requiring modifications to conform to the new require- 1300 ments. 1302 A great deal of questionable data exists in the current registry. The 1303 requirement that all objects have maintainers and the requirements 1304 for improved accountability in the maintainers themselves may make it 1305 easier to determine contact information even where the objects are not 1306 updated to reflect contact information changes. 1308 It is not unreasonable to require valid contact information on exist- 1309 ing data. A great deal of data appears to be unused, such as route 1310 objects for which no announcement has been seen in many months or 1311 years. An attempt should be made to contact the listed contacts in 1312 the object, in the maintainer if there is one, then up the maintainer 1313 referral-by chain if there is one, and using the number registry or 1314 origin AS contact information if there is no maintainer accountability 1315 trail to follow. Experience so far indicates that the vast majority 1316 of deletions identified by comparing registered prefixes against route 1317 dumps will be positively confirmed (allowing the deletion) or there 1318 will be no response due to invalid contact information (in many cases 1319 the IRR contact information points to nsfnet-admin@merit.edu). 1321 By allowing the registry to modify (or delete) any objects which are 1322 disconnected from the maintainer accountability trail, cleanup can 1323 be made possible (though mail header forging could in many cases have 1324 the same effect it is preferable to record the fact that the registry 1325 itself made the cleanup). Similarly, a mechanism may be needed in 1326 the future to allow the maintainer in the referral-by to override 1327 maintainer privileges in a referred maintainer if all contacts have 1328 become unresponsive for a maintainer. The referral-by maintainer is 1329 allowed to add an ``auth-override'' attribute which becomes usable 1330 as an ``auth'' within 60 days from the time of addition. The main- 1331 tainer themselves would be notified of the change and could remove the 1332 ``auth-override'' attribute before it becomes effective and inquire as 1333 to why it was added and correct whatever problem existed. This can be 1334 supported immediately or added later if needed. 1336 D Common Operational Cases 1338 In principle address allocation and route allocation should be hierar- 1339 chical with the hierarchy corresponding to the physical topology. In 1340 practice this is often not the case for numerous reasons. The pri- 1341 mary reasons are the topology is not strictly tree structured and the 1342 topology can change. More specificly: 1344 1. The Internet topology is not strictly tree structured. 1345 o At the top level the network more closely resembles a moderately 1346 dense mesh. 1348 o Near the bottom level many attachments to the Internet are multi- 1349 homed to more than one Internet provider. 1350 2. The Internet topology can and does change. 1352 o Many attachments switch providers to obtain better service or 1353 terms. 1354 o Service providers may modify adjacencies to obtain better transit 1355 service or terms. 1357 o Service providers may disappear completely scattering attachments 1358 or they may merge. 1360 Renumbering is viewed as a practical means to maintain a strict nu- 1361 meric hierarchy [16]. It is also acknowledged that renumbering IPv4 1362 networks can be difficult [16, 3, 17]. We examine first the simple 1363 case where hierarchy still exists. We then examine the operational 1364 cases where either initial topology is not tree structured or cases 1365 where topology changes. 1367 D.1 simple hierarchical address allocation and route allocation 1369 This is the simplest case. Large ranges of inetnums are assigned to 1370 address registries. These registries in turn assign smaller ranges 1371 for direct use or to topologically large entities where allocations 1372 according to topology can reduce the amount of routing information 1373 needed (promote better route aggregation). 1375 AS objects are allocated as topology dictates the need for additional 1376 AS [10]. Route objects can be registered by those with authoriza- 1377 tion given by the AS and by the address owner. This is never an issue 1378 where the maintainer of the AS and the inetnum are the same. Where 1379 they differ, either the provider can give permission to add route ob- 1380 jects for their AS, or the party allocated the address space can give 1381 the provider permission to add route objects for their address space, 1382 or both parties can sign the transaction. Permission is provided by 1383 adding to maintainer attributes. 1385 D.2 aggregation and multihomed more specific routes 1387 Aggregation is normally not a problem if a provider is aggregating ad- 1388 dress space allocated to the provider and then suballocated internally 1389 and/or to customers. In fact, the provider would be expected to do 1390 so. This is not a problem even if the route object for the aggrega- 1391 tion is added after the more specific route objects since only less 1392 specific objects are considered. 1394 Aggregation is potentially a problem if a provider or a set of 1395 providers plan to aggregate address space that was never explicitly 1396 allocated as a block to those providers but rather remains the alloca- 1397 tion of a address registry. These large aggregations can be expected 1398 to be uncommon, but relatively easily dealt with. Superaggregates of 1399 this type will generally be formed by topologically close entities who 1400 have also managed to draw adjacent address allocations. In effect, 1401 the registry must give permission to form such a superaggregate by 1402 either giving permission to do so in the mnt-routes of an inetnum or 1403 by signing the submission along with the other parties. 1405 D.3 provider independent addresses and multiple origin AS 1407 Provider independent addresses and multihoming arrangement using mul- 1408 tiple origin AS present a similar problem to multihoming. The main- 1409 tainer of the address space and the maintainer of the AS is not the 1410 same. Permission can be granted using mnt-routes or multiple signa- 1411 tures can appear on the submission. 1413 D.4 change in Internet service provider 1415 A change in Internet service providers is similar to multihoming. 1416 A minor difference is that the AS for the more specific route will 1417 be the AS of the new provider rather than the AS of the multihomed 1418 customer. Permission can be granted using mnt-routes or multiple 1419 signatures can appear on the submission. 1421 D.5 renumbering grace periods 1423 Renumbering grace periods allow a provider who wants to keep an ad- 1424 dress allocation intact to allow a customer who has chosen to go to 1425 another provider to renumber their network gradually and then re- 1426 turn the address space after renumbering is completed. The issue of 1427 whether to require immediate renumbering or offer renumbering grace 1428 periods and how long they should be or whether they should be in- 1429 definite has been topic of bitter disputes. The authorization model 1430 can support no renumbering grace period, a finite renumbering grace 1431 period, or an indefinite renumbering grace period. The ``reclaim'' 1432 attribute described in Section 9.1 provides a means to end the grace 1433 period. 1435 E Deployment Considerations 1437 This section describes deployment considerations. The intention is to 1438 raise issues and discuss approaches rather than to provide a deploy- 1439 ment plan. 1441 The use of routing registries is not yet universally accepted. There 1442 still remain Internet providers who see no reason to provide the added 1443 assurance of accurate routing information described in Section 6. 1444 More accurately, these benefits are viewed as being insufficient to 1445 justify the cost. This has been largely caused an inability of a very 1446 major router vendor up until recently to handle prefix lists of the 1447 size needed to specify routing policy on a per prefix basis. Another 1448 reason cited is that filtering on a prefix basis in an environment 1449 where routing registry information is incomplete or inaccurate can 1450 interfere with connectivity. 1452 There clearly is a critical mass issue with regard to the use of rout- 1453 ing registries. A minority of providers use the existing IRR to 1454 filter on a per prefix basis. Another minority of providers do not 1455 support the IRR and generally fail to register prefixes until con- 1456 nectivity problems are reported. The majority of providers register 1457 prefixes but do not implement strict prefix filtering. 1459 Deploying new authentication mechanisms has no adverse consequences. 1460 This has been proven with Merit's deployment of PGP. 1462 In deploying new authorization mechanisms, a major issue is dealing 1463 with existing data of very questionable origin. A very large number 1464 of route objects refer to prefixes that have not been announced for 1465 many years. Other route objects refer to prefixes that are no longer 1466 announced with the origin AS that they are registered with (some were 1467 incorrectly registered to start with). There are many causes for 1468 this. 1470 1. During the transition from the NSFNET PRDB to the RADB a large 1471 number of prefixes were registered with an origin AS correspond- 1472 ing to the border AS at which the NSFNET had once heard the route 1473 announcements. The PRDB did not support origin AS, so border 1474 AS was used. Many of these routes were no longer in use at the 1475 time and are now routed with a submitter listed as ``nsfnet- 1476 admin@merit.edu''. 1478 2. As CIDR was deployed, aggregates replaced previously separately 1479 announced more specific prefixes. The route objects for the more 1480 specific prefixes were never withdrawn from the routing registries. 1481 3. Some prefixes are simply no longer in use. Some networks have been 1482 renumbered. Some network no longer exist. Often the routing reg- 1483 istry information is not withdrawn. 1485 4. As provider AS adjacencies changed and as end customers switched 1486 providers often the actual origin AS changed. This was often not 1487 reflected by a change in the routing registry. 1489 Inaccuracies will continue to occur due to the reasons above, except 1490 the first. The hierarchical authorization provides greater account- 1491 ability. In the event that the contacts for specific objects become 1492 unresponsive traversal up the authorization hierarchy should help 1493 identify the parties having previous provided authorization. These 1494 contacts may still have sufficient authorization to perform the neces- 1495 sary cleanup. This issue is discussed in Section C. 1497 A great deal of information is currently missing in the IRR. Quite a 1498 few AS have no aut-num. Quite a lot of data has no maintainer and the 1499 vast majority of maintainers use only the weakest of authentication 1500 methods. Very little can be done by the registries to correct this. 1501 The defaults in the cases of missing objects needed for authorization 1502 has to be to make no authentication checks at all. 1504 The transition can be staged as follows: 1506 1. Add and make use of stronger authorization models. 1508 2. Make schema modifications necessary to support delegations. 1510 3. Add delegation attributes needed for query traversal. 1511 4. Base query traversal on delegations rather than a search of all 1512 known registries. 1514 5. Obtain the cooperation of the address registries for the purpose of 1515 populating the ``inetnum'' entries on an ongoing basis. 1517 6. Add hierarchical authorization support for critical object types, 1518 ``aut-num'', ``inetnum'' and ``route''. 1519 7. Add the requirement that database object either be in use or have 1520 valid contact information and if queries are made by the registry a 1521 response from a contact indicating that the object serves a purpose 1522 if it is not clear what its use is. 1524 8. Begin to purge data which is clearly not in use and for which there 1525 is no valid contact information or no response from the contacts. 1527 Deployment of hierarchical authorization requires cooperation among 1528 the existing routing registries. New code will have to be deployed. 1529 In some cases minimal development resources are available and substan- 1530 tial inertia exists due to the reliance on the current repository and 1531 the need to avoid disruption. 1533 If hierarchical authorization of route objects depends on the exis- 1534 tence of address registration information, minimal cooperation of 1535 the currently separate address registries is required. The extent 1536 of the cooperation amounts to sending cryptographically signed trans- 1537 actions from the address registry to the number registry as address 1538 allocations are made or providing equivalent access to new address 1539 allocations. 1541 Currently most registries return query results from all of the known 1542 repositories using their mirrored copies. Cross registry authoriza- 1543 tions are not yet implemented. Minimal schema changes have to be made 1544 to support the ability to delegate objects for which there is an au- 1545 thorization hierarchy and to support queries and references to other 1546 repositories. In the case of AS delegations, ``as-block'' need to be 1547 created solely for the purpose of traversal. 1549 F Route Object Authorization Pseudocode 1551 The following list provides a brief review of basic concepts. 1553 1. The route object submission must satisfy two authentication cri- 1554 teria. It must match the authentication specified in the aut-num 1555 and the authentication specified in either a route object or if no 1556 applicable route object is found, then an inetnum. 1558 2. When checking for prefix authorization, an exact route object pre- 1559 fix match is checked for first. If there is not an exact match 1560 then a longest prefix match that is less specific than the prefix 1561 is searched for. If the route prefix search fails, then a search 1562 is performed for an inetnum that exactly matches the prefix or for 1563 the most specific inetnum that is less specific than the route ob- 1564 ject submission. 1565 The search for an inetnum should never fail but it may return an 1566 unallocated or reserved range. The inetnum status must be ``allo- 1567 cated'' and the submission must pass it's maintainer authorization 1568 in order to get authorization from an inetnum. So an unallocated 1569 or reserved range inetnum will cause the route object submission to 1570 fail. 1572 3. A route object must pass authorization from both the referenced 1573 aut-num object and the route or inetnum object. 1574 Authorization shall be tested using the maintainer(s) referenced 1575 in the ``mnt-routes'' attribute(s) first. If that check fails, 1576 the ``mnt-lower'' attributes are checked. If that check fails the 1577 ``mnt-by'' attributes are used for the authorization check. 1579 4. The ``reclaim'' attribute can appear in inetnum, route and as-block 1580 objects and provides a means to support address lending. ``re- 1581 claim'' gives authorization over more specific objects, regardless 1582 of the ``mnt-by'' in the object. The value of a ``reclaim'' at- 1583 tribute can be a list or set of objects to provide finer grain 1584 control. 1585 The ``reclaim'' attribute is important to this discussion since 1586 it affects prefix/origin authentication when a new route object is 1587 submitted. 1589 The ``no-reclaim'' attribute is used to provide explicit excep- 1590 tions. 1592 The following pseudocode outlines the algorithm used to check for 1593 proper authorization of a route object submission. 1595 Case #1. Route object add 1596 (ie, no exact prefix/origin match exists). 1598 /* first check the aut-num authorization */ 1600 if ( the referenced aut-num object does not exist or 1601 the aut-num authorization fails ) 1602 authorization fails 1604 /* next we check for prefix authorization */ 1606 if ( a less specific route(s) with the longest prefix is found ) [ 1607 if ( authorization does not pass for at least one of the less 1608 specific route(s) ) 1609 authorization fails 1611 /* now check for a "reclaim" attr */ 1613 if ( the object has a "reclaim" attribute ) [ 1614 if ( no more-specifics exist 1615 OR a less specific exists which passes 1616 authorization and has a "reclaim" attribute 1617 OR all more specifics routess pass modify authorization ) 1618 authorization passes 1619 else 1620 authorization fails 1621 ] else 1622 authorization passes 1623 ] 1625 /* there are no less specific routes to check for prefix 1626 authentication, so we need to try and get authorization from an 1627 inetnum object */ 1629 if ( ( an inetnum is found that is an exact match 1630 OR is less specific and it's status is "allocated" ) 1631 AND a maintainer referenced by the inetnum 1632 passes authorization ) 1633 authorization succeeds 1635 /* if there is no inetnum or route object then then 1636 authorization fails. This should never happen if 1637 the DB is initialized properly. */ 1639 authorization fails. 1641 Case #2. Route object modify/delete 1642 (ie, exact prefix/origin match exists). 1644 if ( the mnt-by passes authorization ) 1645 authorization succeeds 1647 /* if the authorization did not pass from the matched object, 1648 we can still get authorization from a less specific route if it 1649 has a "reclaim" attribute and we pass authorization */ 1651 if ( a less specific route or inetnum object passes authorization 1652 AND has a "reclaim" attribute applicable to 1653 the object to be modified ) 1654 authorization succeeds 1655 else 1656 authorization fails 1658 Acknowledgments 1660 This document draws ideas from numerous discussions and contributions 1661 of the IETF Routing Policy System Work Group and RIPE Routing Work 1662 Group. Earlier drafts of this document listed Carol Orange as a co- 1663 author. Carol Orange made contributions to this document while at 1664 RIPE. 1666 Gerald Winters provided the pseudocode in an email message to the 1667 RIPE dbsec mailing list that was the basis of the pseudocode found 1668 in appendix F. Susan Harris provided comments and numerous editorial 1669 corrections. 1671 References 1673 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 1674 M. Terpstra, and C. Villamizar. Routing Policy Specification 1675 Language (RPSL). Technical Report RFC 2280, Internet Engineering 1676 Task Force, 1998. ftp://ftp.isi.edu/in-notes/rfc2280.txt. 1678 [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Kar- 1679 renberg, M. Terpstra, and J. Yu. Representation of IP Rout- 1680 ing Policies in a Routing Registry (ripe-81++). Techni- 1681 cal Report RFC 1786, Internet Engineering Task Force, 1995. 1682 ftp://ftp.isi.edu/in-notes/rfc1786.txt. 1684 [3] H. Berkowitz. Router Renumbering Guide. Technical Re- 1685 port RFC 2072, Internet Engineering Task Force, 1997. 1686 ftp://ftp.isi.edu/in-notes/rfc2072.txt. 1687 [4] H.W. Braun. Models of policy based routing. Technical 1688 Report RFC 1104, Internet Engineering Task Force, 1989. 1689 ftp://ftp.isi.edu/in-notes/rfc1104.txt. 1691 [5] H.W. Braun and Y. Rekhter. Advancing the NSFNET routing archi- 1692 tecture. Technical Report RFC 1222, Internet Engineering Task 1693 Force, 1991. ftp://ftp.isi.edu/in-notes/rfc1222.txt. 1695 [6] D.D. Clark. Policy routing in Internet protocols. Techni- 1696 cal Report RFC 1102, Internet Engineering Task Force, 1989. 1697 ftp://ftp.isi.edu/in-notes/rfc1102.txt. 1699 [7] D. Crocker. Standard for the format of ARPA Internet text mes- 1700 sages. Technical Report RFC 822, Internet Engineering Task 1701 Force, 1982. ftp://ftp.isi.edu/in-notes/rfc822.txt. 1703 [8] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless Inter-Domain 1704 Routing (CIDR): an Address Assignment and Aggregation Strat- 1705 egy. Technical Report RFC 1519, Internet Engineering Task Force, 1706 1993. ftp://ftp.isi.edu/in-notes/rfc1519.txt. 1708 [9] Internet Engineering Steering Group and R. Hinden. Applicability 1709 Statement for the Implementation of Classless Inter-Domain Rout- 1710 ing (CIDR). Technical Report RFC 1517, Internet Engineering Task 1711 Force, 1993. ftp://ftp.isi.edu/in-notes/rfc1517.txt. 1712 [10] J. Hawkinson and T. Bates. Guidelines for creation, selec- 1713 tion, and registration of an Autonomous System (AS). Techni- 1714 cal Report RFC 1930, Internet Engineering Task Force, 1996. 1715 ftp://ftp.isi.edu/in-notes/rfc1930.txt. 1717 [11] K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, and J. Pos- 1718 tel. Internet Registry IP Allocation Guidelines. Techni- 1719 cal Report RFC 2050, Internet Engineering Task Force, 1996. 1720 ftp://ftp.isi.edu/in-notes/rfc2050.txt. 1722 [12] M. Knopper and S. Richardson. Aggregation Support in the NSFNET 1723 Policy-Based Routing Database. Technical Report RFC 1482, In- 1724 ternet Engineering Task Force, 1993. ftp://ftp.isi.edu/in- 1725 notes/rfc1482.txt. 1726 [13] David Meyer, Mark Prior, Cengiz Alaettinoglu, J. Schmitz, and 1727 Carol Orange. Using RPSL in Practice. Internet Draft (Work in 1728 Progress) draft-ietf-rps-appl-rpsl-06, Internet Engineering Task 1729 Force, 6 1999. ftp://ftp.isi.edu/internet-drafts/draft-ietf-rps- 1730 appl-rpsl-06.txt. 1732 [14] Y. Rekhter. Routing in a Multi-provider Internet. Techni- 1733 cal Report RFC 1787, Internet Engineering Task Force, 1995. 1734 ftp://ftp.isi.edu/in-notes/rfc1787.txt. 1736 [15] Y. Rekhter and T. Li. An Architecture for IP Address Allocation 1737 with CIDR. Technical Report RFC 1518, Internet Engineering Task 1738 Force, 1993. ftp://ftp.isi.edu/in-notes/rfc1518.txt. 1739 [16] Y. Rekhter and T. Li. Implications of Various Address Alloca- 1740 tion Policies for Internet Routing. Technical Report RFC 2008, 1741 Internet Engineering Task Force, 1996. ftp://ftp.isi.edu/in- 1742 notes/rfc2008.txt. 1744 [17] Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, and J. Pos- 1745 tel. An IPv6 Provider-Based Unicast Address Format. Techni- 1746 cal Report RFC 2073, Internet Engineering Task Force, 1997. 1747 ftp://ftp.isi.edu/in-notes/rfc2073.txt. 1749 [18] Janos Zsako. PGP authentication for RIPE database updates. 1750 Internet Draft (Work in Progress) draft-ietf-rps-dbsec- 1751 pgp-authent-01, Internet Engineering Task Force, 4 1999. 1752 ftp://ftp.isi.edu/internet-drafts/draft-ietf-rps-dbsec-pgp- 1753 authent-01.txt. 1755 Security Considerations 1757 This document primarily addresses authorization rules for making ad- 1758 ditions, deletions, and changes to routing policy information repos- 1759 itories. The authentication of these transactions through strong 1760 cryptographic means are addressed by [18], referenced thorughout this 1761 document. The authorization rules are designed such that the inte- 1762 grety of any transaction can be verified independently by any party 1763 mirroring a repository to insure that rules are adhered to. To accom- 1764 plish this the mirror must contain data already known to be properly 1765 authorized. In other words, the mirror must be complete and authenti- 1766 cation and authorization checks must be made continuously as changes 1767 to the repository are recieved and processed in order. 1769 Authentication alone does not provide a complete security model. Cur- 1770 rent practice specifies authorization for deletions and changes only, 1771 not for additions. The authorization rules provide here complete 1772 the security model for additions, deletions, and changes by very ex- 1773 plicitly defining rules for addition and clarifying procedures for 1774 handling exception cases such as organizations which have ceased to 1775 exist and therefore become entirely unresponsive. 1777 Authentication and authorization of queries is explicitly stated to be 1778 out of scope of this document. 1780 Author's Addresses 1782 Curtis Villamizar 1783 Avici Systems 1784 1786 Cengiz Alaettinoglu 1787 ISI 1788 1790 David M. Meyer 1791 Cisco 1792 1794 Sandy Murphy 1795 Trusted Information Systems 1796 1798 Full Copyright Statement 1800 Copyright (C) The Internet Society (June 23, 1999). All Rights Re- 1801 served. 1803 This document and translations of it may be copied and furnished to 1804 others, and derivative works that comment on or otherwise explain it 1805 or assist in its implmentation may be prepared, copied, published and 1806 distributed, in whole or in part, without restriction of any kind, 1807 provided that the above copyright notice and this paragraph are in- 1808 cluded on all such copies and derivative works. However, this doc- 1809 ument itself may not be modified in any way, such as by removing the 1810 copyright notice or references to the Internet Society or other In- 1811 ternet organizations, except as needed for the purpose of developing 1812 Internet standards in which case the procedures for copyrights defined 1813 in the Internet Standards process must be followed, or as required to 1814 translate it into languages other than English. 1816 The limited permissions granted above are perpetual and will not be 1817 revoked by the Internet Society or its successors or assigns. 1819 This document and the information contained herein is provided on an 1820 ``AS IS'' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEER- 1821 ING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUD- 1822 ING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1823 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1824 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.