idnits 2.17.1 draft-ietf-rps-auth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 32 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 786 has weird spacing: '... key manda...' == Line 787 has weird spacing: '...ndatory multi...' == Line 788 has weird spacing: '...th-type mand...' == Line 789 has weird spacing: '...ndatory multi...' == Line 790 has weird spacing: '...ndatory multi...' == (20 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 1998) is 9541 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 1369, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2072 (ref. '3') ** Downref: Normative reference to an Unknown state RFC: RFC 1104 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1222 (ref. '5') ** Downref: Normative reference to an Unknown state RFC: RFC 1102 (ref. '6') ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1519 (ref. '8') (Obsoleted by RFC 4632) ** Downref: Normative reference to an Historic RFC: RFC 1517 (ref. '9') ** Obsolete normative reference: RFC 2050 (ref. '11') (Obsoleted by RFC 7020) -- Possible downref: Normative reference to a draft: ref. '12' ** Downref: Normative reference to an Historic RFC: RFC 1482 (ref. '13') -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-06) exists of draft-ietf-rps-appl-rpsl-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '16') ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '17') ** Obsolete normative reference: RFC 2073 (ref. '19') (Obsoleted by RFC 2374) Summary: 26 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Curtis Villamizar 3 INTERNET-DRAFT ANS 4 draft-ietf-rps-auth-00 Cengiz Alaettinog 5 ISI 6 David M. Meyer 7 University of Oregon 8 Sandy Murphy 9 TIS 10 Carol Orange 11 RIPE 12 March 5, 1998 14 Routing Policy System Security 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 The RIPE database specifications [2] and RPSL language [1] define 37 languages used as the basis for representing information in a routing 38 policy system. A repository for routing policy system information is 39 known as a routing registry. A routing registry provides a means of 40 exchanging information needed to address many issues on importance to 41 the operation of the Internet. The implementation and deployment of a 42 routing policy system must maintain some degree of integrity to be of 43 any use. This document addresses the need to assure integrity of the 44 data by providing an authentication and authorization model. 46 1 Overview 48 The Internet Routing Registry (IRR) has evolved to meet a need for 49 Internet-wide coordination. This need was described in RFC-1787, an 50 informational RFC prepared on behalf of the IAB [16]. The following 51 summary appears in Section 7 of RFC-1787. 53 While ensuring Internet-wide coordination may be more and more 54 difficult, as the Internet continues to grow, stability and con- 55 sistency of the Internet-wide routing could significantly benefit 56 if the information about routing requirements of various organi- 57 zations could be shared across organizational boundaries. Such 58 information could be used in a wide variety of situations ranging 59 from troubleshooting to detecting and eliminating conflicting 60 routing requirements. The scale of the Internet implies that the 61 information should be distributed. Work is currently underway to 62 establish depositories of this information (Routing Registries), 63 as well as to develop tools that analyze, as well as utilize this in- 64 formation. 66 A routing registry must maintain some degree of integrity to be of any 67 use. The degree of integrity required depends on the usage of the 68 routing policy system. 70 An initial intended usage of routing policy systems such as the RIPE 71 database had been in an advisory capacity, documenting the intended 72 routing policies for the purpose of debugging. In this role a very 73 weak form of authentication was deemed sufficient. 75 The IRR is increasingly used for purposes that have a stronger 76 requirement for data integrity and security. This document addresses 77 issues of data integrity and security that is consistent with the 78 usage of the IRR and which avoids compromising data integrity and se- 79 curity even if the IRR is distributed among less trusted repositories. 81 2 Background 83 An early routing policy system used in the T3--NSFNET, the policy 84 routing database (PRDB), provided a means of determining who was 85 authorized to announce specific prefixes to the NSFNET backbone. The 86 need for a policy database was recognized as far back as 1989 [6, 4]. 87 By 1991 the database was in place [5]. Authentication was 88 accomplished by requiring confirmation and was a manually intensive 89 process. This solved the problem for the NSFNET, but was oriented 90 toward holding the routing policy of a single organization. 92 The problem since has become more difficult. New requirements have 93 emerged. 95 1. The need to represent the routing policies of many organizations, 96 2. CIDR and overlapping prefixes, the increasing complexity of routing 97 policies and the needs of aggregation, 99 3. the need to assure integrity of the data and delegate authority for 100 the data representing specifically allocated resources to multiple 101 persons or organizations. 102 4. the need to assure integrity of the data and distribute the storage 103 of data subsets to multiple repositories. 105 The RIPE effort specificly focused on the first issue [2]. Its 106 predecessor, the PRDB, addressed the needs of a single organization, 107 while the RIPE database was initially intended to address the needs of 108 the European Internet community. The RIPE database formats as 109 described in [2] are the basis of current IRR. 111 Routing protocols themselves provide no assurance that the origination 112 of a route is legitimate and can actually reach the stated 113 destination. The nature of CIDR allows more specific prefixes to 114 override less specific prefixes [9, 17, 8]. Even with signed route 115 origination, there is no way to determine if a more specific prefix is 116 legitimate and should override a less specific route announcement 117 without a means of determining who is authorized to announce specific 118 prefixes. Failing to do so places no assurance of integrity of global 119 routing information and leaves an opportunity for a very effective 120 form of denial of service attack. 122 The Routing Policy System Language (RPSL) [1, 15, 14] was a fairly 123 substantial evolutionary step in the data representation which was 124 largely targeted at addressing the second group of needs. The PRDB 125 accommodated CIDR in 1993 [13] and the RIPE database accommodated the 126 entry of CIDR prefixes from inception, but RPSL provides many needed 127 improvements including explicit support for aggregation. Transition 128 of the IRR to RPSL is expected to occur later this year [12]. 130 This document addresses the third group of needs identified above. To 131 some extent existing practice is documented in the area of 132 authentication where Merit has already implemented PGP authentication 133 in the RADB (one registry of the five comprising the IRR). 135 3 Organization of this Document 137 Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this 138 document. Goals are described in Section 4. Section 5 through 139 Section 7 provide descriptions of the changes and discussion. 140 Section 8 provides a concise summary of data formats and semantics. 141 Section A through Section C provide additional technical discussion, 142 examples, and deployment considerations. 144 Goals and Requirements Section 4 provides a more detailed 145 description of the issues and identifies specific problems that can 146 be solved, some of which require a degree of cooperation in the 147 Internet community. 149 Data Representation Section 5 provides some characteristics of 150 RPSL, and proposes formats for external representations of 151 meta-information such as signed bulk data exchanges, and signed 152 transaction and commit stage confirmation exchanges. 154 Authentication Model Section 6 describes current practice, the 155 Merit PGP extensions, proposes an additional authentication method, 156 and describes the extension mechanism if additional methods are 157 needed. 159 Authorization Model Section 7 describes the means of determining 160 whether a transaction contains the authorization needed to add, 161 modify, or delete specific data objects, based on stated 162 authentication requirements in related data objects. 164 Data Format Summaries Section 8 provides a concise reference to the 165 data formats and steps in transaction processing. 167 Technical Discussion Section A contains some discussion of 168 technical tradeoffs. 170 Common Operational Cases Section B provides some examples drawn 171 from past operational experience with the IRR. 173 Deployment Considerations Section C describes some deployment 174 issues and discusses possible means of resolution. 176 4 Goals and Requirements 178 The Internet is an open network. This openness and the large scale of 179 the Internet can present operational problems. Technical weaknesses 180 that allow misconfiguration or errant operation in part of the network 181 to propagate globally or which provide potentials for simple denial of 182 service attacks should be eliminated to the extent that it is 183 practical. The integrity of routing information is critical in 184 assuring that traffic goes where it is supposed to. 186 An accidental misconfiguration can direct traffic toward routers that 187 cannot reach a destination for which they are advertising 188 reachability. This is commonly caused by misconfigured static routes 189 though there are numerous other potential causes. Static routes are 190 often used to provide constant apparent reachability to single homed 191 destinations. Some of the largest ISPs literally have thousands of 192 static routes in their network. These are often entered manually by 193 technicians. Mistyping can divert traffic from a completely unrelated 194 destination to a router with no actual reachability to the advertised 195 destination. This can happen and does happen somewhat regularly. In 196 addition implementation bugs or severe misconfigurations that result in 197 the loss of BGP AS path information or alteration of prefix length can re- 198 sult in the advertisement of large sets of routes. Though considerably 199 more rare on a few occasions where this has occurred the results were catas- 200 trophic. 202 Where there is the potential for an accidental misconfiguration in a 203 remote part of the Internet affecting the global Internet there is 204 also the potential for malice. For example, it has been demonstrated 205 by accident that multiple hour outages at a major institution can be 206 caused a laptop and a dial account if proper precautions are not 207 taken. The dial account need not be with the same provider used by 208 the major institution. 210 The potential for error is increased by the CIDR preference for more 211 specific routes [8]. If an institution advertises a single route of a 212 given length and a distant router advertises a more specific router 213 covering critical hosts, the more specific route, if accepted at all, 214 is preferred regardless of administrative weighting or any routing 215 protocol attributes. 217 There is a need to provide some form of checks on whether a route 218 advertisement is valid. Today checks are typically made against the 219 border AS advertising the route. This prevents accepting routes from 220 border AS that could not be legitimately advertise the route. They 221 checks rely on the use of information in the IRR to generate lists of 222 prefixes that could be advertised by specific border AS. Checks can 223 also be made against the origin AS. If policy information were 224 sufficiently populated, checks could be made against the entire AS 225 path, but this is not yet feasible. 227 The use of a routing registry can also make it more difficult for 228 prefixes to be used without authorization such as unallocated prefixes 229 or prefixes allocated to another party. 231 In summary, some of the problems being addressed are: 233 o Localizing the impact of accidental misconfiguration. 235 o Reducing the potential to use malicious misconfiguration of routing 236 as a denial of service attack. 238 o Eliminating the unauthorized use of address space. 240 If the data within a routing registry is critical, then the ability to 241 change the data must be controlled. Centralized authorities can 242 provide control but centralization can leads to scaling problems (and 243 is politically distasteful). 245 Address allocation and name allocation is already delegated. Since 246 delegation can be to outside registries it is at least somewhat 247 distributed [11]. Autonomous System (AS) numbers are allocated by the 248 same authorities. It makes sense to delegate the routing number space 249 in a manner similar to the address allocation and AS number 250 allocation. The need for this of authority to numerous registries 251 increases the difficulty of maintaining the integrity of the body of 252 information as a whole. 254 As a first step, the database can be somewhat centrally administered 255 with authority granted to many parties to change the information. 256 This is the case with the current IRR. There are a very small number 257 of well trusted repositories and a very large number of parties 258 authorized to make changes. Control must be exercised over who can 259 make changes and what changes they can make. The distinction of who 260 vs what separates authentication from authorization. 262 o Authentication is the means to determine who is attempting to make 263 a change. 265 o Authorization is the determination of whether a transaction passing 266 a specific authentication check is allowed to perform a given 267 operation. 269 Different portions of the database will require different methods of 270 authentication. Some applications will require authentication based 271 on strong encryption. In other cases software supporting strong 272 encryption may not be necessary or may not be legally available. For 273 this reason multiple authentication methods must be supported, 274 selected on a per object basis. The authentication methods may range 275 from very weak data integrity checks to cryptographicly strong 276 signatures. The authorization model must insure that the use of weak 277 integrity checks in parts of the database does not compromise the 278 overall integrity of the database. 280 Additional requirements are placed on the authorization model if the 281 database is widely distributed with delegations made to parties that 282 may not be trustworthy or whose security practices may be lacking. 283 This problem must be addressed in the authorization model in order to 284 enable later evolution to a more distributed routing registry. 286 Autonomous system numbers can be delegated in blocks and subdelegated 287 as needed and then individual AS numbers assigned. Address allocation 288 is a simple numeric hierarchy. Route allocation is somewhat more 289 complicated. The key attributes in a route object (key with regard to 290 database indexing) contains both an address prefix and an AS number, 291 known as the origin AS. The addition of a route object must be vali- 292 dated against both the authorization criteria for the AS and autho- 293 rization criteria appropriate for the address prefix. Route objects 294 may exist for the same prefix with multiple origin AS values due to a 295 common multihoming practice that does not require a unique origin AS. 296 There is often no correlation between the origin AS of a prefix and the 297 origin AS of overlapping prefixes. 299 There are numerous operational cases that must be accommodated. Some 300 of the more common are listed below. These are explored in greater 301 detail in Section B with discussion of technical tradeoffs in 302 Section A. 304 o simple hierarchical address allocation and route allocation 306 o aggregation and multihomed more specific routes 307 o provider independent addresses and multiple origin AS 309 o change in Internet service provider 311 o renumbering grace periods 313 The authorization model must accommodate a variety of policies 314 regarding the allocation of address space and cannot mandate the use 315 of any one model. There is no standardization of address allocation 316 policies and considerable variation though guidelines do exist 317 [11, 18]. Whether authorization allows the recovery of address space 318 must be selectable on a per object basis and may differ in parts the 319 database. This issue is discussed further in Section A. 321 5 Data Representation 323 RPSL provides a complete description of the contents of a routing 324 repository [1]. Many RPSL data objects remain unchanged from the RIPE 325 and RPSL references the RIPE-181 specification as recorded in RFC-1786 327 [2]. RPSL provides external data representation. Data may be stored 328 differently internal to an routing registry. 330 Some database object types or database attributes must be added to 331 RPSL to accommodate recording the delegation of authority and to 332 improve the authentication and authorization capabilities. These 333 additions are very few and are described in Section 6 and Section 7. 335 Some form of encapsulation must be used to exchange data. The 336 de-facto encapsulation has been that which the RIPE tools accept, a 337 plain text file or plain text in the body of an RFC-822 formatted mail 338 message with information needed for authentication derived from the 339 mail headers. Merit has slightly modified this using the PGP signed 340 portion of a plain text file or PGP signed portion of the body of a 341 mail message. These very simple forms of encapsulation are suitable 342 for the initial submission of a database transaction. 344 The encapsulation of registry transaction submissions, registry 345 queries and registry responses and exchanges between registries is 346 outside the scope of this document. 348 6 Authentication Model 350 The maintainer objects serve as a container to hold authentication 351 filters. A reference to a maintainer within another object defines 352 authorization to perform operations on the object or on a set of 353 related objects. The maintainer can be referenced by name in mnt-by 354 and other attributes in other objects. Further details on the use of 355 maintainers are provided in Section 7.1. 357 The maintainer specifies a list of authentication method and 358 authentication information pairs in ``auth'' attributes. An ``auth'' 359 attribute begins with a keyword identifying the authentication method, 360 with the rest of the attribute interpreted according to the 361 authentication method. Where the method is a public/private key 362 cryptographic system, the authentication information is the name of 363 the signature identifier if an external collection of keys is used or 364 could be the full public key. 366 Authentication methods currently supported include: 368 mail-from This is a very weak integrity check. The from or reply-to 369 fields in RFC-822 mail headers are checked. Since mail forgery is 370 quite easy, this is a very weak form of authentication. 371 crypt-pw This is another weak form of authentication. The ``auth'' 372 attribute contains a fixed encrypted password following the 373 ``crypt-pw'' keyword. Since the password is fixed, it can be 374 captured by snooping. Since the encrypted form of the password is 375 exposed, it is subject to password guessing attacks. 377 pgp-from This is Merit's PGP extension. Only the PGP signed portion 378 of a mail message is considered. The remainder of the ``auth'' 379 attribute in Merit's implementation is the signature identity. The 380 public keys are held in an external key ring. 382 Any digital signature technique can be used for authentication. 383 Objects can be signed using multiple digital signature techniques to 384 allow repositories or mirrors that only use a subset of the techniques 385 to verify at least one of the signatures. A few digital signature 386 techniques that would be applicable and may be supported in the future 387 are: 389 1. RSA (note: PGP uses RSA) 391 2. DSA is a NIST public key algorithm 393 3. El Gamal 395 @@ [Still need references for these. Sandy!] @@ 397 7 Authorization Model 399 The authorization model must accommodate the requirements outlined in 400 Section 4. A key feature of the authorization model is the 401 recognition that authorization for the addition of certain types of 402 data objects must be derived from related data objects. 404 With multiple repositories, objects not found in RPSL are needed to 405 control AS delegations and attributes are needed in existing objects 406 to control subdelegation. Objects are also needed to provide query 407 information for other repositories. 409 The following might be used to identify a repository. A root 410 repository must be agreed upon. Ideally such a repository would 411 contain only top level delegations and repository objects and it would 412 be wise to allow only cryptographicly strong submissions. 414 repository: RIPE 415 query-address: whois.ripe.net 43 416 response-auth-type: rsa-pubkey some-incredibly-long-public-key 417 response-auth-type: none 418 remarks: you can request rsa signature on queries 419 submit-address: mail auto-dbm@ripe.net 420 submit-address: query whois.ripe.net:43 421 submit-auth-type: pgp-from rsa-signed crypt-pw mail-from 422 remarks: these are the authentication types supported 423 mnt-by: maint-ripe-db 424 refresh: 3600 425 expire: 14400 426 remarks: refresh and expire same as in DNS SOA 427 ... 428 remarks: admin and technical contact, etc 429 source: IANA 431 In each repository there should be a special repository object named 432 ROOT. This should point to the root repository or to a higher level 433 repository. This is to allow queries to be directed to the local 434 repository but refer to the full set of registries for resolution of 435 hierarchically allocated objects. 437 The ``repository'' object and its usage is described in greater detail 438 in Section 8. 440 7.1 Maintainer Objects 442 The maintain objects serve as a container to hold authentication 443 filters. The authentication methods are described in Section 6. The 444 maintainer can be referenced by name in other attributes in other 445 objects, most notably in the mnt-by attributes of those objects. 447 Maintainers themselves contain mnt-by attributes. In some cases the 448 mnt-by in a maintainer will reference the maintainer itself. In this 449 case, authorization to modify the maintainer is provided to a (usually 450 very limited) set of identities. A good practice is to create a 451 maintainer containing a long list of identities authorized to make 452 specific types of changes but have the maintainer's mnt-by attribute 453 reference a far more restrictive maintainer more tightly controlling 454 changes to the maintainer object itself. 456 The mnt-by attribute should be mandatory in all objects. Some data 457 already exists without mnt-by attributes. A missing mnt-by attribute 458 is interpreted as the absence of any control over changes. This is 459 highly inadvisable and most repositories will no longer allow this. 461 The ``mnt-routes'' attribute are needed to reference maintainer 462 objects to provide specific permissions related to the object. This 463 is an extensions to RPSL and RIPE-181 proposed in this document and 464 are described in detail in Section 8. 466 A mnt-routes attribute is needed in the aut-num and inetnum to allow 467 addition of route objects with that AS number or covered by that pre- 468 fix range but still disallowing changes to the aut-num or inetnum ob- 469 ject. A mnt-routes attribute in the route object would allow addition 470 of exact matches or more specific routes but would not enable modifi- 471 cation or deletion of the route object containing the mnt-routes. 473 7.2 The reclaim attribute 475 A reclaim attribute is needed in inetnum and route objects. The 476 reclaim attribute allows a control to be retained over more specific 477 address or route space by allowing modify and delete privileges 478 regardless of the mnt-by in the attribute itself. 480 The reclaim attribute provides the means to enforce address lending. 481 It allows cleanup in cases where entities cease to exist or as a last 482 resort means to correct errors such as parties locking themselves out 483 of access to their own objects. To allow finer control a set of pre- 484 fixes can be specified. A no-reclaim attribute can be used to provide 485 explicit exceptions. In order to add reclaim attribute to an existing 486 object, there must be no existing exact matches or more specific 487 objects overlapped by the new reclaim attribute unless the prefix is 488 listed in a no-reclaim attribute or unless the submitter has permis- 489 sion to modify in the maintainer of the overlapped object. Similarly 490 a no-reclaim attribute cannot be deleted unless there are no overlapped 491 objects for which the submitter has no authorization to modify. 493 7.3 AS-block and aut-num objects 495 An AS-block object is needed to delegate a range of AS numbers to a 496 given repository. This is needed for authorization and it is needed 497 to avoid having to make an exhaustive search of all repositories to 498 find a specific AS. This search would not be a problem now but would 499 be if a more distributed routing repository is used. 501 as-block: AS1321 - AS1335 502 delegated: ANS 503 ... 505 The ``aut-num'' describes the routing policy for an AS and is critical 506 for router configuration of that AS and for analysis performed by 507 another AS. For the purpose of this document it is sufficient to 508 consider the aut-num solely as a place holder identifying the 509 existence of an AS and providing a means to associate authorization 510 with that AS for the purpose of adding ``route'' objects. 512 The ``as-block'' object is proposed here solely as a means of record- 513 ing the delegation of blocks of AS numbers to alternate registries and 514 in doing so providing a means to direct queries and a means to support 515 hierarchical authorization across multiple repositories. 517 7.4 inetnum objects 519 A delegation attribute is needed in the inetnum and route object. 520 This will accommodate the delegation of address space from IANA to 521 regional IP registries. When the routing registry becomes more widely 522 distributed a delegation attribute is needed to support any 523 subdelegations to more localized registries or delegations to Internet 524 provider operated registries or organizations who may prefer to run 525 their own routing registry. The delegation attribute for an inetnum 526 or a route object can be multi-valued and refers to all registries in 527 which more specific route objects can be found. 529 inetnum: 193.0.0.0 - 193.0.0.255 530 delegated: RIPE 531 ... 532 source: IANA 534 This inetnum simply delegates the storage of any more specific inetnum 535 objects overlapping the stated range to the RIPE repository. An exact 536 match of this inetnum may exist in the RIPE repository to provide 537 hooks for the attributes referencing maintainer objects. 539 The ``inetnum'' exists to support address allocation. For external 540 number registries, such as those using ``[r]whoisd[++]'' the 541 ``inetnum'' can serve as a secondary record that is added when an 542 address allocation is made in the authoritative database. Such 543 records could be added by a address registry such as ARIN as a 544 courtesy to the corresponding routing registry. 546 7.5 route objects 548 Currently there are a quite few route objects in more than one 549 registry. Quite a few are registered with origin AS for which they 550 have never been announced. There is a legitimate reason to be in more 551 than one origin AS. This could result in a legitimate route object for 552 the same prefix in more than one database. The example below is a 553 route registered differently in two databases (and registered 554 incorrectly). This would now require a delegation attribute. 556 route: 128.32.0.0/16 557 delegated: MCI RADB 559 The ``route'' object is used to record routes which may appear in the 560 global routing table. Explicit support for aggregation is provided. 561 Route objects exist both for the configuration of routing information 562 filters used to contain incidents of erroneous route announcements 563 (Section 4) and to support network problem diagnosis. 565 7.6 Other Objects 567 Many of the RPSL ancillary objects have no natural hierarchy the way 568 AS numbers, Internet addresses and routes have a numeric hierarchy. 569 Some examples are ``maintainers'', ``people'' and ``role'' objects. 570 For these objects, lack of any hierarchy leads to two problems. 572 1. There is no hierarchy that can be exploited to direct queries to 573 alternate registries. At some point the query strategy of 574 searching all known registries becomes impractical. 575 2. There is no hierarchy on which authorizations of additions can be 576 based. 578 The first problem can be addressed by considering the name space for 579 each of the ancillary objects to be unique only within the local 580 database and to use explicit references to an external repository 581 where needed. A possible syntax is to precede the object key with the 582 name of the repository and a delimiter. For example, the delimiter 583 ``::'' can be used to form the NIC handle ``RIPE::CO19''. Currently 584 there is a desire to keep NIC handles unique so the naming convention 585 of appending a dash and the repository name is used. Prepending the 586 repository name provides the unique name space since an object in the 587 RIPE database referencing ``CO19'' would be interpreted as 588 ``RIPE::CO19'' by default, but it would still be possible to query or ref- 589 erence ``IANA::CO19''. There is no possibility of accidentally forget- 590 ting to adhere to the conventions when making an addition and the exist- 591 ing objects are accommodated, including cases where name conflicts have 592 already occurred. 594 The second problem can be partially addressed by using a referral 595 system for the addition of maintainers and requiring that any other 596 object be submitted by a registered maintainer. The referral system 597 would allow any existing maintainer to add another maintainer. This 598 can be used in parallel with the addition of other object types to 599 support the maintenance of those objects. For example, when adding a 600 subdomain to the ``domain'' hierarchy (in the RIPE repository where 601 domains are also handled), even when adding a new domain to a rela- 602 tively flat domain such as ``com'', there is already a maintainer for 603 the existing domain. The existing maintainer can add the maintainer 604 that will be needed for the new domain in addition to adding the new do- 605 main and giving the new maintainer the right to modify it. 607 An organization gaining a presence on the Internet for the first time 608 would be given a maintainer. This maintainer may list a small number 609 of very trusted employees that are authorized to modify the maintainer 610 itself. The organization itself can then add another maintainer 611 listing a larger set of employees but listing the more restrictive 612 maintainer in the mnt-by attributes of the maintainers themselves. 613 The organization can then add people and role objects as needed and 614 any other objects as needed and as authorization permits. 616 7.7 Query Processing 618 A query may have to span multiple repositories. All queries should be 619 directed toward a local repository which may mirror the root 620 repository and others. Currently each IRR repository mirrors all 621 others repositories. In this way, the query may be answered by the 622 local repository but draw data from others. 624 For object types that have a natural hierarchy, such as aut-num, 625 inetnum, and route, the search begins at the root database and follows 626 the hierarchy. For objects types that have no natural hierarchy, such 627 as maintainers, people, and roles, the search is confined to a default 628 database unless a database is specified. The default database is the 629 same database as an object from which a reference is made if the query 630 is launched through the need to follow a reference. Otherwise the 631 default is generally the local database or a default set by the 632 repository. The default can be specified in the query itself. 634 In searching for an AS, the AS blocks can be consulted, moving the 635 search to data from other repositories. Eventually the AS is either 636 found or the search fails. 638 The search for an inetnum is similar. Less specific inetnums may 639 refer the search to other databases. Eventually the most specific 640 inetnum is found and its status can be determined and assignment 641 determined if it is assigned. 643 The search for a route is similar except the search may branch to more 644 than one repository. The most specific route in one repository may be 645 more specific than the most specific in another. In looking for a 646 route object it makes sense to return the most specific route that is 647 not more specific than the query requests regardless of which 648 repository that route is in rather than return one route from each 649 repository that contains a less specific overlap. 651 7.8 Adding to the Database 653 The root repository must be initially populated at some epoch with a 654 few entries. An initial maintainer is needed to add more maintainers. 655 The referral-by and referral-to attribute can be set to refer to 656 itself in this special case (Section 8 describes the referral-by and 657 referral-to). When adding an inetnum or a route object an existing 658 exact match or a less specific overlap must exist. A route object may 659 be added based on an exact match or a less specific inetnum. The root 660 repository must be initially populated with the allocation of an 661 inetnum covering the prefix 0/0, indicating that some address 662 allocation authority exists. Similarly an initial as-block is needed 663 covering the full AS number range. 665 When adding an object with no natural hierarchy, the search for an 666 existing object follows the procedure outlined in Section 7.7. 668 When adding an aut-num (an AS), the same procedure used in a query is 669 used to determine the appropriate repository for the addition and to 670 determine which maintainer applies. The sequence of AS-block objects 671 and repository delegations is followed. If the aut-num does not 672 exist, then the submission must match the authentication specified in 673 the maintainer for the most specific AS-block in order to be added. 675 The procedure for adding an inetnum is similar. The sequence of 676 inetnum blocks is followed until the most specific is found. The 677 submission must match the authentication specified in the maintainer 678 for the most specific inetnum overlapping the addition. 680 Adding a route object is somewhat more complicated. The route object 681 submission must satisfy two authentication criteria. It must match 682 the authentication specified in the aut-num and the authentication 683 specified in either a route object or if no applicable route object is 684 found, then an inetnum. 686 An addition is submitted with an AS number and prefix as its key. If 687 the object already exists, then the submission is treated as a modify 688 (see Section 7.9). If the aut-num does not exist on a route add, then 689 the addition is rejected (see Section A for further discussion of 690 tradeoffs). If the aut-num exists then the submission is checked 691 against the applicable maintainer. A search is then done for the 692 prefix first looking for an exact match. If the search for an exact 693 match fails, a search is made for the longest prefix match that is 694 less specific than the prefix specified. If this search succeeds it 695 will return one or more route objects. The submission must match an 696 applicable maintainer in at least one of these route objects for the ad- 697 dition to succeed. If the search for a route object fails, then a search 698 is performed for an inetnum that exactly matches the prefix or for the most 699 specific inetnum that is less specific than the route object submission. 700 The search for an inetnum should never fail but it may return an unallo- 701 cated or reserved range. The inetnum status must be ``allocated'' and the 702 submission must match the maintainer. 704 Having found the AS and either a route object or inetnum, the 705 authorization is taken from these two objects. The applicable 706 maintainer object is any referenced by the mnt-routes attributes. If 707 one or more mnt-routes attributes are present in an object, the mnt-by 708 attributes are not considered. In the absence of a mnt-routes 709 attribute in a given object, the mnt-by attributes are used for that 710 object. The authentication must match one of the authorizations in 711 each of the two objects. 713 If the addition of a route object or inetnum contains a reclaim 714 attribute, then any more specific objects of the same type must be 715 examined. The reclaim attribute can only be added if there are no 716 more specific overlaps or if the authentication on the addition is 717 present in the authorization of a less specific object that already 718 has a reclaim attribute covering the prefix range, or if the 719 authentication on the addition is authorized for the modification of 720 all existing more specific prefixes covered by the addition. 722 7.9 Modifying or Deleting Database Objects 724 When modifying or deleting any existing object a search for the object 725 is performed as described in Section 7.7. If the submission matches 726 the applicable maintainer for the object, then the operation can 727 proceed. The applicable maintainer for a modification is always the 728 maintainer referenced by the mnt-by attribute in the object. 730 If the submission is for a route object, a search is done for all less 731 specific route objects and inetnums. If the submission is for an 732 inetnum, a search is done for all less specific inetnums. If the 733 submission fails the authorization in the object itself but matches 734 the reclaim attribute in any of the less specific objects, then the 735 operation can proceed. Section A contains discussion of the rationale 736 behind the use of the reclaim attribute. 738 A modification to an inetnum object that adds a reclaim attribute or 739 removes a no-reclaim attribute must be checked against all existing 740 inetnums that are more specific. The same check of the reclaim 741 attribute that is made during addition must be made when a reclaim 742 attribute is added by a modification (see Section 7.8). 744 A deletion is considered a special case of the modify operation. The 745 deleted object may remain in the database with a ``deleted'' attribute 746 in which case the mnt-by can still be consulted to remove the 747 ``deleted'' attribute. 749 8 Data Format Summaries 751 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII 752 text. Objects consist of a set of attributes. Attributes are name 753 value pairs. A single attribute is represented as a single line with 754 the name followed by a colon followed by whitespace characters (space, 755 tab, or line continuation) and followed by the value. Within a value 756 all whitespace is equivalent to a single space. Line continuation is 757 supported by a backslash at the end of a line or the following line 758 beginning with whitespace. When transferred, externally attributes 759 are generally broken into shorter lines using line continuation though 760 this is not a requirement. An object is externally represented as a 761 series of attributes. Objects are separated by blank lines. 763 There are about 80 attribute types in the current RIPE schema and 764 about 15 object types. Some of the attributes are mandatory in 765 certain objects. Some attributes may appear multiple times. One or 766 more attributes may form a key. Some attributes or sets of attributes 767 may be required to be unique across all repositories. Some of the 768 attributes may reference a key field in an object type and may be 769 required to be a valid reference. Some attributes may be used in 770 inverse lookups. 772 A review of the entire RIPE or RPSL schema would be too lengthy to 773 include here. Only the differences in the schema are described. 775 8.1 Changes to the RIPE/RPSL Schema 777 Two object types are added to the RIPE/RPSL schema. A few attributes 778 are added to existing object types. There are significant changes to 779 the rules which determine if the addition of an object is authorized. 780 Additional keywords representing new authentication types are added to 781 the semantics of the existing ``auth'' attribute. 783 The new object types are listed below. The first attribute listed is 784 the key attribute and also serves as the name of the object type. 786 repository key mandatory single unique 787 query-address mandatory multiple 788 response-tuth-type mandatory multiple 789 submit-address mandatory multiple 790 submit-auth-type mandatory multiple 791 refresh optional single 792 expire mandatory single 793 descr optional multiple 794 remarks optional multiple 795 admin-c mandatory multiple 796 tech-c mandatory multiple 797 notify optional multiple 798 mnt-by mandatory multiple 799 changed mandatory multiple 800 source mandatory single 802 as-block key mandatory single unique 803 delegated optional single 804 descr optional multiple 805 remarks optional multiple 806 admin-c mandatory multiple 807 tech-c mandatory multiple 808 notify optional multiple 809 mnt-by mandatory multiple 810 changed mandatory multiple 811 source mandatory single 813 In the above object types only a small number of the attribute types 814 are new to RIPE. These are: 816 repository This attribute provides the name of the repository. This 817 is the same name used in the source attribute of all objects in 818 that repository. This is the key field for the object and is 819 single and must be globally unique. 821 query-address This attribute provides a host name and a port number 822 used to direct queries. Optional fields may follow the port number 823 at a later time and should be ignored. 824 response-auth-type This attribute provides the authentication types 825 that may be used by the repository when responding to queries. 827 submit-address This attribute provides a host name and a port number 828 used to submit objects to the repository. Optional fields may 829 follow the port number at a later time and should be ignored. 831 submit-auth-type This attribute provides the authentication types 832 that may be used by the repository when responding to queries. 834 refresh Near real time flooding of repository updates is recommended 835 as a method of distributing database changes. The refresh suggests 836 a time interval for processing updates. Time is in seconds if 837 expressed as an integer. Alternately, the letters ``h'', ``m'', or 838 ``s'' can be used to indicate hours, minutes, and seconds. 839 expire If near real time flooding is temporarily not operational, 840 objects should be considered non-authoritative after this interval, 841 and cannot be used for authorization purposes. 843 as-block This attribute provides the AS number range for an 844 ``as-block'' object. 845 delegated This attribute indicates that further searches for object 846 in the hierarchy must be made in one or more alternate 847 repositories. The current repository may be listed. 849 In order to support stronger authentication, the following keywords 850 are added to the ``auth'' attribute: 852 pgp-from The remainder of the attribute gives the string identifying 853 a PGP identity whose public key is held in an external keyring. 855 rsa-pubkey The remainder of the attribute provides an RSA public key 856 block in ASCII radix-64 format (the format used by PGP). 858 person Refer to the ``auth'' attributes in a person object. The 859 remainder of the attribute provides a list of NIC handles (the 860 person object key field). 862 An additional change is the ``auth'' attribute is allowed to exist in 863 a ``person'' object. 865 A few attributes are added to the schema. These are: 867 mnt-routes The mn-routes attribute may appear in an aut-num, inetnum, 868 or route object. This attribute references a maintainer object 869 which is used in determining authorization for the addition of 870 inetnum and route objects. If a mnt-routes object is absent, the 871 mnt-by attribute is used for this purpose. The mnt-routes 872 attribute is optional and multiple. 874 reclaim The reclaim attribute may appear in as-block, aut-num, 875 inetnum, or route objects. Any object of the same type below in 876 the hierarchy may be modified or deleted by the maintainer of the 877 object containing a reclaim attribute. The value of the attribute 878 is a set or range of objects of the same type. 880 no-reclaim The no-reclaim attribute is used with the reclaim 881 attribute. The no-reclaim attribute negates any reclaim attribute 882 it overlaps. 884 delegated The delegated attribute is allowed in any object type with 885 a hierarchy. This attribute indicates that further searches for 886 object in the hierarchy must be made in one or more alternate 887 repositories. The current repository may be listed. 888 referral-by This attribute is required in the maintainer object. It 889 may never be altered after the addition of the maintainer. This 890 attribute refers to the maintainer that created this maintainer. 891 It may be multiple if more than one signature appeared on the 892 object submission. 894 referral-in This attribute may appear in a maintainer object. It is 895 multiple. Each time the maintainer object is used to add another 896 maintainer, a referral-in referencing the new maintainer is 897 automatically added. 899 Each repository must identify itself with a ``repository'' object. 900 The repository must also contain a special ``repository'' whose key is 901 ``ROOT''. The root repository is where all non-local queries are 902 directed, including where hierarchical object queries start. The 903 query methods listed for the root repository may actually be a subset 904 of those offered by that repository if efficiency considerations and 905 topologic distance make some methods less useful. 907 The root repository must contain a copy of the repository objects in 908 any repository considered valid. The repository objects will be 909 essential when the routing registry becomes more widely distributed. 911 The existing ``mnt-by'' attribute references the ``maintainer'' object 912 type. The ``mnt-by'' attribute is now mandatory in all object types. 913 A new maintainer may be added by any existing maintainer. The 914 ``referral-by'' attribute is now mandatory in the ``maintainer'' 915 object to keep a record of which maintainer made the addition and can 916 never be changed. Maintainers cannot be deleted as long as they are 917 referenced by a ``referral-by'' attribute elsewhere. In order to add 918 a maintainer to another database, a ``referral-in'' attribute is 919 needed, containing the name of the external database. A ``referral- 920 in'' attribute cannot be deleted unless there are no ``referral-by'' 921 references to the maintainer in the named external databases. 923 A Technical Discussion 925 A few design tradeoffs exist. Some of these tradeoffs, the selected 926 solution, and the alternatives are discussed here. Some of the issues 927 are listed below. 929 1. Whether to error on the side of permissiveness and weaken 930 authorization controls or risk the possibility of erecting barriers 931 to registering information. 933 2. Whether to support enforcible address lending or provide the 934 smaller or end user with ultimate control over the registration of 935 the prefixes they are using. 936 3. What to do with older objects that either don't conform to newer 937 requirements regarding minimum authorization, authentication, and 938 accountability, or are of questionable validity. 940 A.1 Relaxing requirements for ease of registry 942 If the requirement that an aut-num exists is relaxed, then it is 943 possible for anyone to make use of an unassigned AS number or make use 944 of an assigned AS number for which the aut-num has not been entered. 945 Placing requirements on the entry of aut-num presumes cooperation of 946 the Internet address allocation authority (if separate from the rout- 947 ing registry). The address allocation authority must be willing to 948 field requests to populate skeleton aut-nums from the party for which 949 the allocation has been made. These aut-num must include a reference 950 to a maintainer. A request to the address allocation authority must 951 therefore include a reference to an existing maintainer. 953 The ability to add route objects is also tied to the existence of less 954 specific route objects or inetnums. The Internet address allocation 955 authority (if separate from the routing registry) must also be willing 956 to field requests to add inetnum records for the party already 957 allocated the address space. 959 The Internet address allocation authority should also add inetnums and 960 aut-nums for new allocations. In order to do so, a maintainer must 961 exist. If a party is going to connect to the Internet, they can get a 962 maintainer by making a request to the Internet service provider they 963 will be connecting to. Once they have a maintainer they can make a 964 request for address space or an AS number. The maintainer can contain 965 a public key for a cryptographicly strong authorization method or 966 could contain a ``crypt-key'' or ``mail-to'' authorization check if 967 that is considered adequate by the registering party. Furthermore an 968 address allocation authority should verify that the request for an AS 969 number or for address space matches the authorization criteria in the main- 970 tainer. 972 Currently only the registry themselves may add maintainers. This 973 becomes a problem for the registry particularly verifying public keys. 974 This requirement is relaxed by allowing existing maintainers to add 975 maintainers. Unfortunately the accountability trail does not exist 976 for existing maintainers. The requirement then should be relaxed such 977 that existing maintainers may remain but only existing maintainers 978 that have a ``referral-by'' attribute can add maintainers. The 979 ``referral-by'' and ``referral-in'' cannot be modified. This require- 980 ment can be relax slightly so that a ``referral-by'' can be added to a 981 maintainer by an existing maintainer with a ``referral-by''. This 982 will allow the accountability trail to be added to existing maintainers 983 and these maintainers can then add new maintainers. 985 Verifying that a party is who they claim to be on initial addition, is 986 one of the problems that currently falls upon the AS number and 987 address registry. This problem is reduced by allowing existing 988 maintainers to add maintainers. This may actually make it easier to 989 get maintainers and therefore easier to register. The number 990 authority still must verify that the AS or address space is actually 991 needed by the party making a request. 993 Authorization checks made during the addition of route objects that 994 refer to AS objects and inetnum strongly rely on the cooperation of 995 the Internet address allocation authorities. The number authorities 996 must register as-blocks, aut-nums, or inetnums as AS numbers or ad- 997 dress space is allocated. If only a subset of the number authorities 998 cooperate, then either an inetnum or as-block can be created covering 999 the space that registry allocates and essentially requiring null allo- 1000 cation (for example a ``crypt-pw'' authentication where the password 1001 is given in the remarks in the object or its maintainer) or those ob- 1002 taining addresses from that number authority will have trouble regis- 1003 tering in the routing registry. The authorization model supports either 1004 option, though it would be preferable if the number authorities cooper- 1005 ated and the issue never surfaced in practice. 1007 The maintainer requirements can be relaxed slightly for existing 1008 maintainers making it easier to register. Relaxing requirements on 1009 other objects may defeat the authorization model. 1011 A.2 The address lending issue 1013 The issue of whether lending contracts should be enforcible is an 1014 issue of who should ultimately be able to exercise control over allo- 1015 cations of address space. The routing registry would be wise to stay 1016 as neutral as possible with regard to disputes between third parties. 1017 The ``reclaim'' and ``no-reclaim'' are designed to allow either out- 1018 come to the decision as to whether the holder of a less specific inet- 1019 num or route object can exercise control over suballocations in the 1020 registry. The routing registry itself must decide whether to retain 1021 control themselves and if so, should very clearly state under what 1022 conditions the registry would intervene. A registry could even go to 1023 the extreme of stating that they will intervene in such a dispute only af- 1024 ter the dispute has been resolved in court and a court order has been is- 1025 sued. 1027 When an allocation is made by a registry, the registry should keep a 1028 ``reclaim'' attribute in the less specific object and make a strong 1029 policy statement that the reclaim privilege will not be used except 1030 under very clearly defined special circumstances (which at the very 1031 minimum would include a court order). If the allocation is further 1032 subdivided the party subdividing the allocation and the party accept- 1033 ing the suballocation must decide whether a ``reclaim'' can be kept by 1034 the holder of the less specific allocation or whether a ``no-reclaim'' 1035 must be added transferring control to the holder of the more specific. 1036 The registry is not involved in that decision. Different pairs of 1037 third parties may to different decisions regarding the ``reclaim'' and any 1038 contractual restrictions on its use that may be expressed outside of the 1039 registry in the form of a legal contract and ultimately resolved by the 1040 courts in the event of a bitter dispute. 1042 By retaining ``reclaim'' rights the registry retains the ability to 1043 abide by a court order. This may only truly become an issue in a 1044 distributed registry environment where registries will be rechecking 1045 the authorization of transactions made elsewhere and may fail to 1046 process the attempt of another registry to abide by a court order by 1047 overriding normal authorization to change the registry contents if a 1048 reclaim is not present. 1050 A.3 Dealing with non-conformant or questionable older data 1052 Some of the newer requirements include requiring that all objects 1053 reference a maintainer object responsible for the integrity of the 1054 object and requiring accountability for the creation of maintainers to 1055 be recorded in the maintainer objects so that accountability can be 1056 traced back from an unresponsive maintainer. In the event that 1057 contact information is absent or incorrect from objects and there is 1058 any question regarding the validity of the objects, the maintainer can 1059 be contacted. If the maintainer is unresponsive, the maintainer that 1060 authorized the addition of that maintainer can be contacted to either 1061 update the contact information on the maintainer or confirm that the 1062 entity no longer exists or is no longer actively using the Internet or the 1063 registry. 1065 Many route objects exist for which there are no maintainers and for 1066 which inetnum and AS objects do not exist. Some contain the now 1067 obsoleted guardian attribute rather than a mnt-by. 1069 It is not practical to unconditionally purge old data that does not 1070 have maintainers or does not conform to the authorization hierarchy. 1071 New additions must be required to conform to the new requirements 1072 (otherwise the requirements are meaningless). New requirements can be 1073 phased in by requiring modifications to conform to the new 1074 requirements. 1076 A great deal of questionable data exists in the current registry. The 1077 requirement that all objects have maintainers and the requirements for 1078 improved accountability in the maintainers themselves may make it 1079 easier to determine contact information even where the objects are not 1080 updated to reflect contact information changes. 1082 It is not unreasonable to require valid contact information on 1083 existing data. A great deal of data appears to be unused, such as 1084 route objects for which no announcement has been seen in many months 1085 or years. An attempt should be made to contact the listed contacts in 1086 the object, in the maintainer if there is one, then up the maintainer 1087 referral-by chain if there is one, and using the number registry or 1088 origin AS contact information if there is no maintainer accountability 1089 trail to follow. Experience so far indicates that the vast majority 1090 of deletions identified by comparing registered prefixes against route 1091 dumps will be positively confirmed (allowing the deletion) or there 1092 will be no response due to invalid contact information (in many cases the 1093 IRR contact information points to nsfnet-admin@merit.edu). 1095 By allowing the registry to modify (or delete) any objects which are 1096 disconnected from the maintainer accountability trail, cleanup can be 1097 made possible (though mail header forging could in many cases have the 1098 same effect it is preferable to record the fact that the registry 1099 itself made the cleanup). Similarly, a mechanism may be needed in the 1100 future to allow the maintainer in the referral-by to override 1101 maintainer privileges in a referred maintainer if all contacts have 1102 become unresponsive for a maintainer. One possibility is to allow the 1103 referral-by maintainer to add an ``auth-override'' attribute which be- 1104 comes usable as an ``auth'' within 30 or 60 days from the time of ad- 1105 dition. The maintainer themselves would be notified of the change and could 1106 remove the ``auth-override'' attribute before it becomes effective and in- 1107 quire as to why it was added and correct whatever problem existed. This 1108 can be supported immediately or added later if needed. 1110 B Common Operational Cases 1112 In principle address allocation and route allocation should be 1113 hierarchical with the hierarchy corresponding to the physical 1114 topology. In practice this is often not the case for numerous 1115 reasons. The primary reasons are the topology is not strictly tree 1116 structured and the topology can change. More specificly: 1118 1. The Internet topology is not strictly tree structured. 1120 o At the top level the network more closely resembles a moderately 1121 dense mesh. 1122 o Near the bottom level many attachments to the Internet are 1123 multihomed to more than one Internet provider. 1125 2. The Internet topology can and does change. 1126 o Many attachments switch providers to obtain better service or 1127 terms. 1129 o Service providers may modify adjacencies to obtain better transit 1130 service or terms. 1131 o Service providers may disappear completely scattering attachments 1132 or merge. 1134 Renumbering is viewed as a practical means to maintain a strict 1135 numeric hierarchy [18]. It is also acknowledged that renumbering IPv4 1136 networks can be difficult [18, 3, 19]. We examine first the simple 1137 case where hierarchy still exists. We then examine the operational 1138 cases where either initial topology is not tree structured or cases 1139 where topology changes. 1141 B.1 simple hierarchical address allocation and route allocation 1143 This is the simplest case. Large ranges of inetnums are assigned to 1144 address registries. These registries in turn assign smaller ranges 1145 for direct use or to topologically large entities where allocations 1146 according to topology can reduce the amount of routing information 1147 needed (promote better route aggregation). 1149 AS objects are allocated as topology dictates the need for additional 1150 AS [10]. Route objects can be registered by those with authorization 1151 given by the AS and by the address owner. This is never an issue 1152 where the maintainer of the AS and the inetnum are the same. Where 1153 they differ, either the provider can give permission to add route 1154 objects for their AS, or the party allocated the address space can 1155 give the provider permission to add router objects for their address 1156 space, or both parties can sign the transaction. Permission is 1157 provided by adding to maintainer attributes. 1159 B.2 aggregation and multihomed more specific routes 1161 Aggregation is normally not a problem if a provider is aggregating 1162 address space allocated to the provider and then suballocated 1163 internally and/or to customers. In fact, the provider would be 1164 expected to do so. This is not a problem even if the route object for 1165 the aggregation is added after the more specific route objects since 1166 only less specific objects are considered. 1168 Aggregation is potentially a problem if a provider or a set of 1169 providers plan to aggregate address space that was never explicitly 1170 allocated as a block to those providers but rather remains the 1171 allocation of a address registry. These large aggregations can be 1172 expected to be uncommon, but relatively easily dealt with. 1173 Superaggregates of this type will generally be formed by topologically 1174 close entities who have also managed to draw adjacent address 1175 allocations. In effect, the registry must give permission to form 1176 such as superaggregate by either giving permission to do so in an 1177 inetnum or by signing the submission along with the other parties. 1179 A more common case is where a more specific route object must be 1180 registered with a different AS than the aggregate due to the prefix 1181 being multihomed. In this case, the maintainer of the aggregate can 1182 create a more specific route object with their own AS marked withdrawn 1183 so as not to be routable. The new AS can be included in the 1184 maintainer solely for the purpose of allowing them to create a new 1185 route object with their own AS. Again, alternately both parties can 1186 sign the submission for the addition with the new AS. 1188 B.3 provider independent addresses and multiple origin AS 1190 Provider independent addresses and multihoming arrangement using 1191 multiple origin AS present a similar problem to multihoming. The 1192 maintainer of the address space and the maintainer of the AS is not 1193 the same. Permission can be granted using additions to the maintainer 1194 or multiple signatures can appear on the submission. 1196 B.4 change in Internet service provider 1198 A change in Internet service providers is similar to multihoming. A 1199 minor difference is that the AS for the more specific route will be 1200 the AS of the new provider rather than the AS of the multihomed 1201 customer. A provider may be hesitant to give permissions to their 1202 competitor to make additions with their AS. There is no potential for 1203 harm in giving permission to a withdrawn exact match of the more 1204 specific so the maintainer of the aggregate could more easily in 1205 effect grant permission to the maintainers of the new AS. 1207 B.5 renumbering grace periods 1209 Renumbering grace periods allow a provider who wants to keep an 1210 address allocation intact to allow a customer who has chosen to go to 1211 another provider to renumber their network gradually and then return 1212 the address space after renumbering is completed. The issue of 1213 whether to require immediate renumbering or offer renumbering grace 1214 periods and how long they should be or whether they should be 1215 indefinite has been topic of bitter disputes. The authorization model 1216 can support no renumbering grace period, a finite renumbering grace 1217 period, or an indefinite renumbering grace period. The ``reclaim'' 1218 attribute described in Section 7.1 provides a means to end the grace 1219 period. 1221 C Deployment Considerations 1223 This section described deployment considerations. The intention is to 1224 raise issues and discuss approaches rather than to provide a 1225 deployment plan. 1227 The use of routing registries is not yet universally accepted. There 1228 still remain Internet providers who see no reason to provide the added 1229 assurance of accurate routing information described in Section 4. 1230 More accurately, these benefits are viewed as being insufficient to 1231 justify the cost. This has been largely caused an inability of a very 1232 major router vendor up until recently to handle prefix lists of the 1233 size needed to specify routing policy on a per prefix basis. Another 1234 reason cited is that filtering on a prefix basis in an environment 1235 where routing registry is incomplete or inaccurate can interfere with 1236 connectivity. 1238 There clearly is a critical mass issue with regard to the use of 1239 routing registries. A minority of providers use the existing IRR to 1240 filter on a per prefix basis. Another minority of providers do not 1241 support the IRR and generally fail to register prefixes until 1242 connectivity problems are reported. The majority of providers 1243 register prefixes but do not implement strict prefix filtering. 1245 Deploying new authentication mechanisms has no adverse consequences. 1246 This has been proven with Merit's deployment of PGP. 1248 In deploying new authorization mechanisms, a major issue is dealing 1249 with existing data of very questionable origin. A very large number 1250 of route objects refer to prefixes that have not been announced for 1251 many years. Other route objects refer to prefixes that are no longer 1252 announced with the origin AS that they are register with (some were 1253 incorrectly registered to start with). There are many causes for 1254 this. 1256 1. During the transition from the NSFNET PRDB to the RADB a large 1257 number of prefixes were registered with an origin AS corresponding 1258 to the border AS at which the NSFNET had once heard the route 1259 announcements. The PRDB did not support origin AS, so border AS 1260 was used. Many of these routes were no longer in use at the time 1261 and are now routed with a submitter listed as 1262 ``nsfnet-admin@merit.edu''. 1264 2. As CIDR was deployed aggregates replaced previously separately 1265 announced more specific prefixes. The route objects for the more 1266 specific prefixes were never withdrawn from the routing registries. 1267 3. Some prefixes are simply no longer in use. Some networks have been 1268 renumbered. Some network no longer exist. Often the routing 1269 registry information is not withdrawn. 1271 4. As provider AS adjacencies changed and as end customers switched 1272 providers often the actual origin AS changed. This was often not 1273 reflected by a change in the routing registry. 1275 Inaccuracies will continue to occur due to the reasons above, except 1276 the first. The hierarchical authorization provides greater 1277 accountability. In the event that the contacts for specific objects 1278 become unresponsive traversal up the authorization hierarchy should 1279 help identify the parties having previous provided authorization. 1280 These contacts may still have sufficient authorization to perform the 1281 necessary cleanup. This issue is discussed in Section A. 1283 A great deal of information is currently missing in the IRR. Quite a 1284 few AS have no aut-num. Quite a lot of data has no maintainer and the 1285 vast majority of maintainers use only the weakest of authentication 1286 methods. Very little can be done by the registries to correct this. 1287 The defaults in the cases of missing objects needed for authorization 1288 has to be to make no authentication checks at all. 1290 The transition can be staged as follows: 1292 1. Add and make use of stronger authorization models. 1294 2. Make schema modifications necessary to support delegations. 1296 3. Add delegation objects needed for query traversal. 1298 4. Base query traversal on delegations rather than search of all known 1299 registries. 1301 5. Obtain the cooperation of the address registries for the purpose of 1302 populating the ``inetnum'' entries on an ongoing basis. 1304 6. Add hierarchical authorization support for critical object types, 1305 ``aut-num'', ``inetnum'' and ``route''. 1306 7. Add the requirement that database object either be in use or have 1307 valid contact information and if queries are made by the registry a 1308 response from a contact indicating that the object serves a purpose 1309 if it is not clear what its use is. 1311 8. Begin to purge data which is clearly not in use and for which there 1312 is no valid contact information or no response from the contacts. 1314 Deployment of hierarchical authorization requires cooperation among 1315 the existing routing registries. New code will have to be deployed. 1316 In some cases very little development resources are available and 1317 substantial inertia exists due to the reliance on the current 1318 repository and the need to avoid disruption. 1320 If hierarchical authorization of route objects depends on the 1321 existence of address registration information, minimal cooperation of 1322 the currently separate address registries is required. The extent of 1323 the cooperation amounts to sending cryptographically signed 1324 transactions from the address registry to the number registry as 1325 address allocations are made or providing equivalent access to new 1326 address allocations. 1328 Currently most registries returns query results from all of the known 1329 repositories using their mirrored copies. Cross registry 1330 authorizations are not yet implemented. Minimal schema changes have 1331 to be made to support the ability to delegate objects for which there 1332 is an authorization hierarchy and the support queries and references 1333 to other repositories. In the case of AS delegations, ``as-block'' 1334 need to be created solely for the purpose of traversal. 1336 Acknowledgments 1338 This document draws ideas from numerous discussions and contributions 1339 of the IETF Routing Policy System Work Group and RIPE Routing Work 1340 Group. 1342 References 1344 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 1345 M. Terpstra, and C. Villamizar. Routing policy specification 1346 language (rpsl). Technical Report RFC 2280, Internet Engineering 1347 Task Force, 1998. ftp://ds.internic.net/rfc/rfc2280.txt. 1348 [2] T. Bates, E. Gerich, L. Joncheray, J-M. 1349 Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu. Representation 1350 of ip routing policies in a routing reg- 1351 istry (ripe-81++). Technical Report RFC 1786, Internet Engineer- 1352 ing Task Force, 1995. ftp://ds.internic.net/rfc/rfc1786.txt. 1354 [3] H. Berkowitz. Router 1355 renumbering guide. Technical Report RFC 2072, Internet Engineer- 1356 ing Task Force, 1997. ftp://ds.internic.net/rfc/rfc2072.txt. 1358 [4] H.W. Braun. Models of policy based routing. Technical Report RFC 1359 1104, Internet Engineering Task Force, 1989. 1360 ftp://ds.internic.net/rfc/rfc1104.txt. 1361 [5] H.W. Braun and Y. Rekhter. Advancing the nsfnet routing ar- 1362 chitecture. Technical Report RFC 1222, Internet Engineering Task 1363 Force, 1991. ftp://ds.internic.net/rfc/rfc1222.txt. 1365 [6] D.D. Clark. Policy routing in internet protocols. Technical Re- 1366 port RFC 1102, Internet Engineering Task Force, 1989. 1367 ftp://ds.internic.net/rfc/rfc1102.txt. 1369 [7] D. Crocker. Standard for the format of arpa 1370 internet text messages. Technical Report RFC 822, Internet Engi- 1371 neering Task Force, 1982. ftp://ds.internic.net/rfc/rfc822.txt. 1372 [8] V. Fuller, T. Li, J. Yu, and K. Varadhan. Classless inter-domain 1373 routing (cidr): an address assignment and aggregation strat- 1374 egy. Technical Report RFC 1519, Internet Engineering Task Force, 1375 1993. ftp://ds.internic.net/rfc/rfc1519.txt. 1377 [9] Internet Engineering Steering Group and R. Hinden. Applicability 1378 statement for the implementation of classless inter-domain rout- 1379 ing (cidr). Technical Report RFC 1517, Internet Engineering Task 1380 Force, 1993. ftp://ds.internic.net/rfc/rfc1517.txt. 1382 [10] J. Hawkinson and T. Bates. Guidelines for creation, selection, 1383 and registration of an autonomous system (as). Technical Report 1384 RFC 1930, Internet Engineering Task Force, 1996. 1385 ftp://ds.internic.net/rfc/rfc1930.txt. 1386 [11] K. Hubbard, M. Kosters, D. Con- 1387 rad, D. Karrenberg, and J. Postel. Internet registry ip alloca- 1388 tion guidelines. Technical Report RFC 2050, Internet Engineering 1389 Task Force, 1996. ftp://ds.internic.net/rfc/rfc2050.txt. 1391 [12] David Kessens and Carol Or- 1392 ange. Ripe-181 to rpsl transition plan. Internet Draft (Work in 1393 Progress) draft-ietf-rps-transition-02, Internet 1394 Engineering Task Force, 11 1997. ftp://ds.internic.net/internet- 1395 drafts/draft-ietf-rps-transition-02.txt. 1397 [13] Mark Knopper and Steven J. 1398 Richardson. Aggregation support in the nsfnet policy-based rout- 1399 ing database. Technical Report RFC 1482, Internet Engineering 1400 Task Force, 1993. ftp://ds.internic.net/rfc/rfc1482.txt. 1402 [14] David Meyer, Cengiz Alaettinoglu, and David 1403 Kessens. Guidelines for extending rpsl. Internet Draft (Work in 1404 Progress) draft-ietf-rps-extending-00, Internet 1405 Engineering Task Force, 11 1997. ftp://ds.internic.net/internet- 1406 drafts/draft-ietf-rps-extending-00.txt. 1407 [15] David Meyer, Cengiz Alaettinoglu, and J. Schmitz. Application of 1408 routing policy specification language (rpsl) on the 1409 internet. Internet Draft (Work in Progress) draft-ietf-rps-appl- 1410 rpsl-01, Internet Engineering Task Force, 7 1411 1997. ftp://ds.internic.net/internet-drafts/draft-ietf-rps-appl- 1412 rpsl-01.txt. 1414 [16] Y. Rekhter. Routing in a multi-provider internet. Technical Re- 1415 port RFC 1787, Internet Engineering Task Force, 1995. 1416 ftp://ds.internic.net/rfc/rfc1787.txt. 1418 [17] Y. Rekhter and T. Li. An architecture for ip address allocation 1419 with cidr. Technical Report RFC 1518, Internet Engineering Task 1420 Force, 1993. ftp://ds.internic.net/rfc/rfc1518.txt. 1421 [18] Y. Rekhter and T. Li. Implications of various address allocation 1422 policies for internet routing. Technical Report RFC 2008, Inter- 1423 net Engineering Task Force, 1996. 1424 ftp://ds.internic.net/rfc/rfc2008.txt. 1426 [19] Y. Rekhter, P. Lothberg, R. Hinden, S. Deer- 1427 ing, and J. Postel. An ipv6 provider-based unicast address for- 1428 mat. Technical Report RFC 2073, Internet Engineering Task Force, 1429 1997. ftp://ds.internic.net/rfc/rfc2073.txt. 1431 Security Considerations 1433 @@ This entire document is about security so what belongs here? 1435 Author's Addresses 1437 Curtis Villamizar 1438 ANS Communications 1439 1441 Cengiz Alaettinoglu 1442 ISI 1443 1445 David M. Meyer 1446 University of Oregon 1447 1449 Sandy Murphy 1450 Trusted Information Systems 1451 1453 Carol Orange 1454 RIPE NCC 1455