idnits 2.17.1 draft-ietf-rps-dist-05.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: ---------------------------------------------------------------------------- ** 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? == 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 102 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 42 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. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 364 has weird spacing: '... key manda...' == Line 365 has weird spacing: '...ndatory multi...' == Line 366 has weird spacing: '...th-type mand...' == Line 367 has weird spacing: '...ndatory multi...' == Line 368 has weird spacing: '...ndatory multi...' == (11 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 (October 13, 1999) is 8962 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) ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '2') == Outdated reference: A later version (-02) exists of draft-ietf-rps-dbsec-pgp-authent-01 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Curtis Villamizar 2 Expires April 13, 2000 Avici Systems 3 draft-ietf-rps-dist-05.txt Cengiz Alaettinoglu 4 ISI 5 Ramesh Govindan 6 ISI 7 David M. Meyer 8 Cisco 9 October 13, 1999 11 Routing Policy System Replication 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 month- 23 s and may be updated, replaced, or obsoleted by other documents at 24 any time. It is inappropriate to use Internet- Drafts as reference 25 material 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 (October 13, 1999). All Rights 34 Reserved. 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119. 40 Abstract 42 The RIPE database specifications and RPSL define languages used as 43 the basis for representing information in a routing policy system. A 44 repository for routing policy system information is known as a routing 45 registry. A routing registry provides a means of exchanging informa- 46 tion needed to address many issues of importance to the operation of 47 the Internet. The implementation and deployment of a routing policy 48 system must maintain some degree of integrity to be of any use. The 49 Routing Policy System Security RFC [3] addresses the need to assure 50 integrity of the data by proposing an authentication and authoriza- 51 tion model. This document addresses the need to distribute data over 52 multiple repositories and delegate authority for data subsets to other 53 repositories without compromising the authorization model established 54 in Routing Policy System Security RFC. 56 Contents 58 1 Overview 5 60 2 Data Representation 6 62 3 Authentication and Authorization 7 64 4 Repository Hierarchy 8 66 5 Additions to RPSL 8 68 5.1 repository object . .. . . . .. . . . .. . . . . .. . . . . 9 70 5.2 delegated attribute .. . . . .. . . . .. . . . . .. . . . . 11 72 5.3 integrity attribute .. . . . .. . . . .. . . . . .. . . . . 12 74 6 Interactions with a Repository or Mirror 13 76 6.1 Initial Transaction Submission. . . . .. . . . . .. . . . . 14 78 6.2 Redistribution of Transactions. . . . .. . . . . .. . . . . 14 80 6.3 Transaction Commit and Confirmation . .. . . . . .. . . . . 14 82 7 Data Format Summaries, Transaction Encapsulation and Processing 15 84 7.1 Transaction Submit and Confirm. . . . .. . . . . .. . . . . 15 86 7.2 Redistribution of Transactions. . . . .. . . . . .. . . . . 18 88 7.3 Redistribution Protocol Description . .. . . . . .. . . . . 18 90 7.3.1 Explicitly Requesting Transactions . . . . .. . . . . 22 92 7.3.2 Heartbeat Processing . .. . . . .. . . . . .. . . . . 23 94 7.4 Transaction Commit .. . . . .. . . . .. . . . . .. . . . . 24 96 7.5 Database Snapshot . .. . . . .. . . . .. . . . . .. . . . . 25 98 7.6 Authenticating Operations . .. . . . .. . . . . .. . . . . 26 100 A Examples 27 102 A.1 Initial Object Submission and Redistribution . . .. . . . . 28 104 A.2 Transaction Redistribution Encoding . .. . . . . .. . . . . 30 106 A.3 Transaction Protocol Encoding . . . . .. . . . . .. . . . . 31 108 A.4 Transaction Redistribution . .. . . . .. . . . . .. . . . . 33 110 B Technical Discussion 35 112 B.1 Server Processing . .. . . . .. . . . .. . . . . .. . . . . 35 114 B.1.1 getting connected . . .. . . . .. . . . . .. . . . . 35 116 B.1.2 rolling transaction logs forward and back .. . . . . 35 118 B.1.3 committing or disposing of transactions . .. . . . . 36 120 B.1.4 dealing with concurrency. . . . .. . . . . .. . . . . 36 122 B.2 Repository Mirroring for Redundancy . .. . . . . .. . . . . 36 124 B.3 Trust Relationships .. . . . .. . . . .. . . . . .. . . . . 37 126 B.4 A Router as a Minimal Mirror .. . . . .. . . . . .. . . . . 38 128 B.5 Dealing with Errors .. . . . .. . . . .. . . . . .. . . . . 38 130 C Deployment Considerations 39 132 D Privacy of Contact Information 39 133 1 Overview 135 A routing registry must maintain some degree of integrity to be of any 136 use. The IRR is increasingly used for purposes that have a stronger 137 requirement for data integrity and security. There is also a desire 138 to further decentralize the IRR. This document proposes a means of 139 decentralizing the routing registry in a way that is consistent with 140 the usage of the IRR and which avoids compromising data integrity and 141 security even if the IRR is distributed among less trusted reposito- 142 ries. 144 Two methods of authenticating the routing registry information have 145 been proposed. 147 authorization and authentication checks on transactions: The integri- 148 ty of the routing registry data is insured by repeating authoriza- 149 tion checks as transactions are processed. As transactions are 150 flooded each remote registry has the option to repeat the autho- 151 rization and authentication checks. This scales with the total 152 number of changes to the registry regardless of how many registries 153 exist. When querying, the integrity of the repository must be such 154 that it can be trusted. If an organization is unwilling to trust 155 any of the available repositories or mirrors they have the option 156 to run their own mirror and repeat authorization checks at that 157 mirror site. Queries can then be directed to a mirror under their 158 own administration which presumably can be trusted. 160 signing routing registry objects: An alternate which appears on the 161 surface to be attractive is signing the objects themselves. Closer 162 examination reveals that the approach of signing objects by itself 163 is flawed and when used in addition to signing transactions and 164 rechecking authorizations as changes are made adds nothing. In 165 order for an insertion of critical objects such as inetnums and 166 routes to be valid, authorization checks must be made which allow 167 the insertion. The objects on which those authorization checks are 168 made may later change. In order to later repeat the authorization 169 checks the state of other objects, possibly in other repositories 170 would have to be known. If the repository were not trusted then 171 the change history on the object would have to be traced back to 172 the object's insertion. If the repository were not trusted, the 173 change history of any object that was depended upon for autho- 174 rization would also have to be rechecked. This trace back would 175 have to go back to the epoch or at least to a point where only 176 trusted objects were being relied upon for the authorizations. If 177 the depth of the search is at all limited, authorization could be 178 falsified simply by exceeding the search depth with a chain of au- 179 thorization references back to falsified objects. This would be 180 grossly inefficient. Simply verifying that an object is signed 181 provides no assurance that addition of the object addition was 182 properly authorized. 184 A minor distinction is made between a repository and a mirror. A 185 repository has responsibility for the initial authorization and au- 186 thentication checks for transactions related to its local objects 187 which are then flooded to adjacent repositories. A mirror receives 188 flooded transactions from remote repositories but is not the authori- 189 tative source for any objects. From a protocol standpoint, reposito- 190 ries and mirrors appear identical in the flooding topology. 192 Either a repository or a mirror may recheck all or a subset of trans- 193 actions that are flooded to it. A repository or mirror may elect not 194 to recheck authorization and authentication on transactions received 195 from a trusted adjacency on the grounds that the adjacent repository 196 is trusted and would not have flooded the information unless autho- 197 rization and authentication checks had been made. 199 If it can be arranged that all adjacencies are trusted for a given 200 mirror, then there is no need to implement the code to check autho- 201 rization and authentication. There is only a need to be able to check 202 the signatures on the flooded transactions of the adjacent reposito- 203 ry. This is an important special case because it could allow a router 204 to act as a mirror. Only changes to the registry database would be 205 received through flooding, which is a very low volume. Only the sig- 206 nature of the adjacent mirror or repository would have to be checked. 208 2 Data Representation 210 RPSL provides a complete description of the contents of a routing 211 repository [1]. Many RPSL data objects remain unchanged from the 212 RIPE, and RPSL references the RIPE-181 specification as recorded in 213 RFC-1786 [2]. RPSL provides external data representation. Data may 214 be stored differently internal to a routing registry. The integrity 215 of the distributed registry data requires the use of the authorization 216 and authentication additions to RPSL described in [3]. 218 Some additions to RPSL are needed to locate all of the repositories 219 after having located one of them and to make certain parameters se- 220 lectable on a per repository basis readily available. These additions 221 are described in Section 5. 223 Some form of encapsulation must be used to exchange data. The de- 224 facto encapsulation has been that which the RIPE tools accept, a plain 225 text file or plain text in the body of an RFC-822 formatted mail mes- 226 sage with information needed for authentication derived from the mail 227 headers. Merit has slightly modified this using the PGP signed por- 228 tion of a plain text file or PGP signed portion of the body of a mail 229 message. 231 The exchange that occurs during flooding differs from the initial 232 submission. In order to repeat the authorization checks the state 233 of all repositories containing objects referenced by the authoriza- 234 tion checks needs to be known. To accomplish this a sequence number 235 is associated with each transaction in a repository and the flooded 236 transactions must contain the sequence number of each repository on 237 which authorization of the transaction depends. 239 In order to repeat authorization checks it must be possible to re- 240 trieve back revisions of objects. How this is accomplished is a mat- 241 ter local to the implementation. One method which is quite simple is 242 to keep the traversal data structures to all current objects even if 243 the state is deleted, keep the sequence number that the version of the 244 object became effective and keep back links to prior versions of the 245 objects. Finding a prior version of an object involves looking back 246 through the references until the sequence number of the version of 247 the object is less than or equal to the sequence number being searched 248 for. 250 The existing very simple forms of encapsulation are adequate for the 251 initial submission of a database transaction and should be retained 252 as long as needed for backward compatibility. A more robust encapsu- 253 lation and submission protocol, with optional confirmation is defined 254 in Section 6.1. An encapsulation suitable for exchange of transaction 255 between repositories is addressed in Section 6. Query encapsulation 256 and protocol is outside the scope of this document. 258 3 Authentication and Authorization 260 Control must be exercised over who can make changes and what changes 261 they can make. The distinction of who vs what separates authentica- 262 tion from authorization. 264 o Authentication is the means to determine who is attempting to make 265 a change. 267 o Authorization is the determination of whether a transaction pass- 268 ing a specific authentication check is allowed to perform a given 269 operation. 271 A submitted transaction contains a claimed identity. Depending on the 272 type of transaction, the authorization will depend on related objects. 273 The ``mnt-by'', ``mnt-routes'', or ``mnt-lower'' attributes in those 274 related objects reference ``maintainer'' objects. Those maintainer 275 objects contain ``auth'' attributes. The auth attributes contain an 276 authorization method and data which generally contains the claimed 277 identity and some form of public encryption key used to authenticate 278 the claim. 280 Authentication is done on transactions. Authentication should also be 281 done between repositories to insure the integrity of the information 282 exchange. In order to comply with import, export, and use restric- 283 tions throughout the world no encryption capability is specified. 284 Transactions must not be encrypted because it may be illegal to use 285 decryption software in some parts of the world. 287 4 Repository Hierarchy 289 With multiple repositories, ``repository'' objects are needed to prop- 290 agate the existence of new repositories and provide an automated means 291 to determine the supported methods of access and other characteristics 292 of the repository. The repository object is described in Section 5. 294 In each repository there should be a special repository object named 295 ROOT. This should point to the root repository or to a higher lev- 296 el repository. This is to allow queries to be directed to the local 297 repository but refer to the full set of registries for resolution of 298 hierarchically allocated objects. 300 Each repository may have an ``expire'' attribute. The expire at- 301 tribute is used to determine if a repository must be updated before a 302 local transaction that depends on it can proceed. 304 The repository object also contains attributes describing the access 305 methods and supported authentication methods of the repository. The 306 ``query-address'' attribute provides a host name and a port number 307 used to direct queries. The ``response-auth-type'' attribute provides 308 the authentication types that may be used by the repository when re- 309 sponding to queries. The ``submit-address'' attribute provides a host 310 name and a port number used to submit objects to the repository. The 311 ``submit-auth-type'' attribute provides the authentication types that 312 may be used by the repository when responding to submissions. 314 5 Additions to RPSL 316 There are very few additions to RPSL defined here. The additions to 317 RPSL are referred to as RPSL ``objects''. They reside in the repos- 318 itory database and can be retrieved with ordinary queries. Objects 319 consist of ``attributes'', which are name/value pairs. Attributes 320 may be mandatory or optional. They may be single or multiple. One or 321 more attributes may be part of a key field. Some attributes may have 322 the requirement of being unique. 324 Most of the data formats described in this document are encapsula- 325 tions used in transaction exchanges. These are referred to as ``meta- 326 objects''. These ``meta-objects'', unlike RPSL ``objects'' do not 327 reside in the database but some must be retained in a transaction log. 328 A similar format is used to represent ``meta-objects''. They also 329 consist of ``attributes'' which are name/value pairs. 331 This section contains all of the additions to RPSL described in this 332 document. This section describes only RPSL objects. Other sections 333 described only meta-objects. 335 5.1 repository object 337 A root repository must be agreed upon. Ideally such a repository 338 would contain only top level delegations and pointers to other repos- 339 itories used in these delegations. It would be wise to allow only 340 cryptographically strong transactions in the root repository [3]. 342 The root repository contains references to other repositories. An 343 object of the following form identifies another repository. 345 repository: RIPE 346 query-address: whois://whois.ripe.net 347 response-auth-type: PGPKEY-23F5CE35 # pointer to key-cert object 348 response-auth-type: none 349 remarks: you can request rsa signature on queries 350 remarks: PGP required on submissions 351 submit-address: mailto://auto-dbm@ripe.net 352 submit-address: rps-query://whois.ripe.net:43 353 submit-auth-type: pgp-key, crypt-pw, mail-from 354 remarks: these are the authentication types supported 355 mnt-by: maint-ripe-db 356 expire: 0000 04:00:00 357 heartbeat-interval: 0000 01:00:00 358 ... 359 remarks: admin and technical contact, etc 360 source: IANA 362 The attributes of the repository object are listed below. 364 repository key mandatory single 365 query-address mandatory multiple 366 response-auth-type mandatory multiple 367 submit-address mandatory multiple 368 submit-auth-type mandatory multiple 369 repository-cert mandatory multiple 370 expire mandatory single 371 heartbeat-interval mandatory single 372 descr optional multiple 373 remarks optional multiple 374 admin-c mandatory multiple 375 tech-c mandatory multiple 376 notify optional multiple 377 mnt-by mandatory multiple 378 changed mandatory multiple 379 source mandatory single 381 In the above object type only a small number of the attribute types 382 are new. These are: 384 repository This attribute provides the name of the repository. This 385 is the key field for the object and is single and must be globally 386 unique. This is the same name used in the source attribute of all 387 objects in that repository. 389 query-address This attribute provides a url for directing queries. 390 ``rps-query'' or ``whois'' can be used as the protocol identifier. 391 response-auth-type This attribute provides an authentication type 392 that may be used by the repository when responding to user queries. 393 Its syntax and semantics is same as the auth attribute of the main- 394 tainer class. 396 submit-address This attribute provides a url for submitting objects 397 to the repository. 399 submit-auth-type This attribute provides the authentication types 400 that are allowed by the repository for users when submitting regis- 401 trations. 402 repository-cert This attribute provides a reference to a public key 403 certificate in the form of an RPSL key-cert object. This attribute 404 can be multiple to allow the repository to use more than one method 405 of signature. 407 heartbeat-interval Heartbeat meta-objects are sent by this repos- 408 itory at the rate of one heartbeat meta-object per the interval 409 indicated. The value of this attribute shall be expressed in the 410 form ``dddd hh:mm:ss'', where the ``dddd'' represents days, ``hh'' 411 represents hours, ``mm'' minutes and ``ss'' seconds. 413 expire If no heartbeat or new registrations are received from a 414 repository for expire period, objects from this repository should 415 be considered non-authoritative, and cannot be used for authoriza- 416 tion purposes. The value of this attribute shall be expressed in 417 the form ``dddd hh:mm:ss'', where the ``dddd'' represents days, 418 ``hh'' represents hours, ``mm'' minutes and ``ss'' seconds. This 419 value should be bigger than heartbeat-interval. 421 Please note that the ``heartbeat'' meta-objects mentioned above, like 422 other meta-objects described in this document are part of the protocol 423 to exchange information but are not placed in the database itself. 424 See Section 7.3.2 for a description of the heartbeat meta-object. 426 The remaining attributes in the repository object are defined in RPSL. 428 5.2 delegated attribute 430 For many RPSL object types a particular entry should appear only in 431 one repository. These are the object types for which there is a natu- 432 ral hierarchy, ``as-block'', ``aut-num'', ``inetnum'', and ``route''. 433 In order to facilitate putting an object in another repository, a 434 ``delegated'' attribute is added. 436 delegated The delegated attribute is allowed in any object type with 437 a hierarchy. This attribute indicates that further searches for 438 object in the hierarchy must be made in one or more alternate 439 repositories. The current repository may be listed. The ability 440 to list more than one repository serves only to accommodate grand- 441 fathered objects (those created prior to using an authorization 442 model). The value of a delegated attribute is a list of repository 443 names. 445 If an object contains a ``delegated'' attribute, an exact key field 446 match of the object may also be contained in each repository listed in 447 the ``delegated'' attribute. For the purpose of authorizing changes 448 only the ``mnt-by'' in the object in the repository being modified is 449 considered. 451 The following is an example of the use of a ``delegated'' attribute. 453 inetnum: 193.0.0.0 - 193.0.0.255 454 delegated: RIPE 455 ... 456 source: IANA 458 This inetnum simply delegates the storage of any more specific inetnum 459 objects overlapping the stated range to the RIPE repository. An exact 460 match of this inetnum may also exist in the RIPE repository to pro- 461 vide hooks for the attributes referencing maintainer objects. In this 462 case, when adding objects to the RIPE repository, the ``mnt-lower'', 463 `mnt-routes'', and ``mnt-by'' fields in the IANA inetnum object will 464 not be considered, instead the values in the RIPE copy will be used. 466 5.3 integrity attribute 468 The ``integrity'' attribute can be contained in any RPSL object. It 469 is intended solely as a means to facilitate a transition period during 470 which some data has been moved from repositories prior to the use of a 471 strong authorization model and is therefore questionable, or when some 472 repositories are not properly checking authorization. 474 The ``integrity'' attribute may have the values ``legacy'', ``no- 475 auth'', ``auth-failed'', or ``authorized''. If absent, the integrity 476 is considered to be ``authorized''. The integrity values have the 477 following meanings: 479 legacy: This data existed prior to the use of an adequate authoriza- 480 tion model. The data is highly suspect. 482 no-auth: This data was added to a repository during an initial tran- 483 sition use of an authorization model but authorization depended 484 on other objects whose integrity was not ``authorized''. Such an 485 addition is being allowed during the transition but would be disal- 486 lowed later. 487 auth-failed: The authoritative repository is not checking autho- 488 rization. Had it been doing so, authorization would have failed. 489 This attribute may be added by a repository that is mirroring be- 490 fore placing the object in its local storage, or can add this at- 491 tribute to an encapsulating meta-object used to further propagate 492 the transaction. If the failure to enforce authorization is in- 493 tentional and part of a transition (for example, issuing warnings 494 only), then the authoritative repository may add this attribute to 495 the encapsulating meta-object used to further propagate the trans- 496 action. 498 authorized: Authorization checks were passed. The maintainer con- 499 tained a ``referral-by'' attribute, a form of authentication deemed 500 adequate by the repository was used, and all objects that were 501 needed for authorization were objects whose integrity was ``autho- 502 rized''. 504 Normally once an object is added to a repository another object cannot 505 overwrite it unless authorized to do so by the maintainers referenced 506 by the ``mnt-by'' attributes in the object itself. If the integrity 507 attribute is anything but ``authorized'', an object can be overwritten 508 or deleted by any transaction that would have been a properly autho- 509 rized addition had the object of lesser integrity not existed. 511 During such a transition grandfathered data and data added without 512 proper authorization becomes advisory until a properly authorized 513 addition occurs. After transition additions of this type would no 514 longer be accepted. Those objects already added without proper autho- 515 rization would remain but would be marked as candidates for replace- 516 ment. 518 6 Interactions with a Repository or Mirror 520 This section presents an overview of the transaction distribution 521 mechanisms. The detailed format of the meta-objects for encapsulating 522 and distributing transactions, and the rules for processing meta- 523 objects are described in Section 7. There are a few different types 524 of interactions between routing repositories or mirrors. 526 Initial submission of transactions: Transactions may include addi- 527 tions, changes, and deletions. A transaction may operate on more 528 than one object and must be treated as an atomic operation. By 529 definition initial submission of transactions is not applicable 530 to a mirror. Initial submission of transactions is described in 531 Section 6.1. 533 Redistribution of Transactions: The primary purpose of the inter- 534 actions between registries is the redistribution of transactions. 535 There are a number of ways to redistribute transactions. This is 536 discussed in Section 6.2. 538 Queries: Query interactions are outside the scope of this document. 539 Transaction Commit and Confirmation: Repositories may optionally im- 540 plement a commit protocol and a completion indication that gives 541 the submitter of a transaction a response that indicates that a 542 transaction has been successful and will not be lost by a crash of 543 the local repository. A submitter may optionally request such a 544 confirmation. This is discussed in Section 6.3. 546 6.1 Initial Transaction Submission 548 The simplest form of transaction submission is an object or set of 549 objects submitted with RFC--822 email encapsulation. This form is 550 still supported for backwards compatibility. A preferred form al- 551 lows some meta-information to be included in the submission, such 552 as a preferred form of confirmation. Where either encapsulation is 553 used, the submitter will connect to a host and port specified in the 554 repository object. This allows immediate confirmation. If an email 555 interface similar to the interface provided by the existing RIPE code 556 is desired, then an external program can provide the email interface. 558 The encapsulation of a transaction submission and response is de- 559 scribed in detail in Section 7. 561 6.2 Redistribution of Transactions 563 Redistribution of transactions can be accomplished using one of: 565 1. A repository snapshot is a request for the complete contents of 566 a given repository. This is usually done when starting up a new 567 repository or mirror or when recovering from a disaster, such as a 568 disk crash. 569 2. A transaction sequence exchange is a request for a specific set of 570 transactions. Often the request is for the most recent sequence 571 number known to a mirror to the last transactions. This is used in 572 polling. 574 3. Transaction flooding is accomplished through a unicast adjacency. 576 This section describes the operations somewhat qualitatively. Data 577 formats and state diagrams are provided in Section 7. 579 6.3 Transaction Commit and Confirmation 581 If a submission requires a strong confirmation of completion, or if 582 a higher degree of protection against false positive confirmation is 583 desired as a matter of repository policy, a commit may be performed. 585 A commit request is a request from the repository processing an ini- 586 tial transaction submission to another repository to confirm that 587 they have been able to advance the transaction sequence up to the se- 588 quence number immediately below the transaction in the request and are 590 willing to accept the transaction in the request as a further advance 591 in the sequence. This indicates that either the authorization was 592 rechecked by the responding repository and passed or that the respond- 593 ing repository trusts the requesting repository and has accepted the 594 transaction. 596 A commit request can be sent to more than one alternate repository. 597 One commit completion response is sufficient to respond to the sub- 598 mitter with a positive confirmation that the transaction has been com- 599 pleted. However, the repository or submitter may optionally require 600 more than one. 602 7 Data Format Summaries, Transaction Encapsulation and Processing 604 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII tex- 605 t. Objects consist of a set of attributes. Attributes are name/value 606 pairs. A single attribute is represented as a single line with the 607 name followed by a colon followed by whitespace characters (space, 608 tab, or line continuation) and followed by the value. Within a val- 609 ue all consecutive whitespace characters is equivalent to a single 610 space. Line continuation is supported by putting a white space or 611 '+' character to the beginning of the continuation lines. An object 612 is externally represented as a sequence of attributes. Objects are 613 separated by blank lines. 615 Protocol interactions between registries are activated by passing 616 ``meta objects''. Meta objects are not part of RPSL but conform to 617 RPSL object representation. They serve mostly as delimiters to the 618 protocol messages or to carry the request for an operation. 620 7.1 Transaction Submit and Confirm 622 The de-facto method for submitting database changes has been via e- 623 mail. This method should be supported by an external application. 624 Merit has added the pgp-from authentication method to the RADB (re- 625 placed by ``pgpkey'' in [4]), where the mail headers are essentially 626 ignored and the body of the mail message must be PGP signed. 628 This specification defines a different encapsulation for transaction 629 submission. When submitting a group of objects to a repository, a 630 user MUST append to that group of objects, exactly one ``timestamp'' 631 and one or more ``signature'' meta-objects, in that order. 633 The ``timestamp'' meta-object contains a single attribute: 635 timestamp This attribute is mandatory and single-valued. This at- 636 tribute specifies the time at which the user submits the transac- 637 tion to the repository. The format of this attribute is ``YYYYMMDD 638 hh:mm:ss [+/-]xx:yy'', where ``YYYY'' specifies the four digit 639 year, ``MM'' represents the month, ``DD'' the date, ``hh'' the 640 hour, ``mm'' the minutes, ``ss'' the seconds of the timestamp, and 641 ``xx'' and ``yy'' represents the hours and minutes respectively 642 that that timestamp is ahead or behind UTC. 644 A repository may reject a transaction which does not include the 645 ``timestamp'' meta-object. The timestamp object is used to prevent 646 replaying registrations. How this is actually used is a local matter. 647 For example, a repository can accept a transaction only if the value 648 of the timestamp attribute is greater than the timestamp attribute 649 in the previous registration received from this user (maintainer), or 650 the repository may only accept transactions with timestamps within its 651 expire window. 653 Each ``signature'' meta-object contains a single attribute: 655 signature This attribute is mandatory and single-valued. This at- 656 tribute, a block of free text, contains the signature corresponding 657 to the authentication method used for the transaction. When the 658 authentication method is a cryptographic hash (as in PGP-based au- 659 thentication), the signature must include all text upto (but not 660 including) the last blank line before the first ``signature'' meta- 661 object. 663 A repository must reject a transaction that does not include any 664 ``signature'' meta-object. 666 The group of objects submitted by the user, together with the ``times- 667 tamp'' and ``signature'' meta-objects, constitute the ``submitted 668 text'' of the transaction. 670 The protocol used for submitting a transaction, and for receiving con- 671 firmation of locally committed transactions, is not specified in this 672 document. This protocol may define additional encapsulations around 673 the submitted text. The rest of this section gives an example of one 674 such protocol. Implementations are free to choose another encapsula- 675 tion. 677 The meta-objects ``transaction-submit-begin'' and ``transaction- 678 submit-end'' delimit a transaction. A transaction is handled as an 679 atomic operation. If any part of the transaction fails none of the 680 changes take effect. For this reason a transaction can only operate 681 on a single database. 683 A socket connection is used to request queries or submit transactions. 684 An email interface may be provided by an external program that con- 685 nects to the socket. A socket connection must use the ``transaction- 686 submit-begin'' and ``transaction-submit-end'' delimiters but can re- 687 quest a legacy style confirmation. Multiple transactions may be sent 688 prior to the response for any single transaction. Transactions may 689 not complete in the order sent. 691 The ``transaction-submit-begin'' meta-object may contain the following 692 attributes. 694 transaction-submit-begin This attribute is mandatory and single. The 695 value of the attribute contains name of the database and an identi- 696 fier that must be unique over the course of the socket connection. 698 response-auth-type This attribute is optional and multiple. The re- 699 mainder of the line specifies an authentication type that would 700 be acceptable in the response. This is used to request a response 701 cryptographically signed by the repository. 702 transaction-confirm-type This attribute is optional and single. A 703 confirmation type keyword must be provided. Keywords are ``none'', 704 ``legacy'', ``normal'', ``commit''. The confirmation type can be 705 followed by the option ``verbose''. 707 The ``transaction-submit-end'' meta-object consists of a single at- 708 tribute by the same name. It must contain the same database name 709 and identifier as the corresponding ``transaction-submit-begin'' at- 710 tribute. 712 Unless the confirmation type is ``none'' a confirmation is sent. If 713 the confirmation type is ``legacy'', then an email message of the for- 714 m currently sent by the RIPE database code will be returned on the 715 socket (suitable for submission to the sendmail program). 717 A ``normal'' confirmation does not require completion of the commit 718 protocol. A ``commit'' confirmation does. A ``verbose'' confirmation 719 may contain additional detail. 721 A transaction confirmation is returned as a ``transaction-confirm'' 722 meta-object. The ``transaction-confirm'' meta-object may have the 723 following attributes. 725 transaction-confirm This attribute is mandatory and single. It con- 726 tains the database name and identifier associated with the transac- 727 tion. 728 confirmed-operation This attribute is optional and multiple. It 729 contains one of the keywords ``add'', ``delete'' or ``modify'' fol- 730 lowed by the object type and key fields of the object operated on. 732 commit-status This attribute is mandatory and single. It contain- 733 s one of the keywords ``succeeded'', ``error'', or ``held''. The 734 ``error'' keyword may be followed by an optional text string. The 735 ``held'' keyword is returned when a repository containing a depen- 736 dent object for authorization has expired. 738 7.2 Redistribution of Transactions 740 In order to redistribute transactions, each repository maintains a 741 TCP connection with one or more other repositories. After locally 742 committing a submitted transaction, a repository assigns a sequence 743 number to the transaction, signs and encapsulates the transaction, and 744 then sends one copy to each neighboring (or ``peer'') repository. In 745 turn, each repository authenticates the transaction (as described in 746 Section 7.6), may re-sign the transaction and redistributes the trans- 747 action to its neighbors. We use the term ``originating repository'' 748 to distinguish the repository that redistributes a locally submitted 749 transaction. 751 This document also specifies two other methods for redistributing 752 transactions to other repositories: a database snapshot format used 753 for initializing a new registry, and a polling technique used by mir- 754 rors. 756 In this section, we first describe how a repository may encapsulate 757 the submitted text of a transaction. We then describe the proto- 758 col for flooding transactions or polling for transactions, and the 759 database snapshot contents and format. 761 7.3 Redistribution Protocol Description 763 The originating repository must first authenticate a submitted trans- 764 action using methods described in [3]. 766 Before redistributing a transaction, the originating repository must 767 encapsulate the submitted text of the transaction with several meta- 768 objects, which are described below. 770 The originating repository must prepend the submitted text with exact- 771 ly one ``transaction-label'' meta-object. This meta-object contains 772 the following attributes: 774 transaction-label This attribute is mandatory and single. The value 775 of this attribute conforms to the syntax of an RPSL word, and rep- 776 resents a globally unique identifier for the database to which this 777 transaction is added. 779 sequence This attribute is mandatory and single. The value of this 780 attribute is an RPSL integer specifying the sequence number as- 781 signed by the originating repository to the transaction. Succes- 782 sive transactions distributed by the same originating repository 783 have successive sequence numbers. The first transaction originat- 784 ed by a registry is assigned a sequence number 1. Each repository 785 must use sequence numbers drawn from a range at least as large as 786 64 bit unsigned integers. 788 timestamp This attribute is mandatory and single-valued. This at- 789 tribute specifies the time at which the originating repository 790 encapsulates the submitted text. The format of this attribute is 791 ``YYYYMMDD hh:mm:ss [+/-]xx:yy'', where ``YYYY'' specifies the four 792 digit year, ``MM'' represents the month, ``DD'' the date, ``hh'' 793 the hour, ``mm'' the minutes, ``ss'' the seconds of the timestamp, 794 and ``xx'' and ``yy'' represents the hours and minutes respectively 795 that that timestamp is ahead or behind UTC. 796 integrity This attribute is optional and single-valued. It may have 797 the values ``legacy'', ``no-auth'', ``auth-failed'', or ``autho- 798 rized''. If absent, the integrity is considered to be ``autho- 799 rized''. 801 The originating repository may append to the submitted text one or 802 more ``auth-dependency'' meta-objects. These meta-objects are used 803 to indicate which other repositories' objects were used by the o- 804 riginating registry to authenticate the submitted text. The ``auth- 805 dependency'' meta-objects should be ordered from the most preferred 806 repository to the least preferred repository. This order is used by a 807 remote repository to tie break between the multiple registrations of 808 an object with the same level of integrity. The ``auth-dependency'' 809 meta-object contains the following attributes: 811 auth-dependency This attribute mandatory and single-valued. It e- 812 quals a repository name from which an object is used to autho- 813 rize/authenticate this transaction. 815 sequence This attribute mandatory and single-valued. It equals the 816 transaction sequence number of the dependent repository known at 817 the originating repository at the time of processing this transac- 818 tion. 819 timestamp This attribute mandatory and single-valued. It equals 820 the timestamp of the dependent repository known at the originating 821 repository at the time of processing this transaction. 823 If the originating repository needs to modify submitted objects in a 824 way that the remote repositories can not re-create, it can append an 825 ``override-objects'' meta-object followed by the modified versions of 826 these objects. An example modification can be auto assignment of NIC 827 handles. The ``override-objects'' meta-object contains the following 828 attributes: 830 override-objects A free text remark. 832 Other repositories may or may not honor override requests, or limit 833 the kinds of overrides they allow. 835 Following this, the originating repository must append exactly one 836 ``repository-signature'' meta-object. The ``repository-signature'' 837 meta-object contains the following attributes: 839 repository-signature This attribute is mandatory and single-valued. 840 It contains the name of the repository. 842 integrity This attribute is optional and single-valued. It may have 843 the values ``legacy'', ``no-auth'', ``auth-failed'', or ``au- 844 thorized''. If absent, the value is same as the value in the 845 transaction-label. If a different value is used, the value here 846 takes precedence. 848 signature This attribute is optional and single-valued. This at- 849 tribute, a block of free text, contains the repository's signa- 850 ture using the key in the repository-cert attribute of the repos- 851 itory object. When the authentication method is a cryptographic 852 hash (as in PGP-based authentication), the signature must include 853 all text upto (but not including) this attribute. That is, the 854 ``repository-signature'' and ``integrity'' attributes of this ob- 855 ject are included. This attribute is optional since cryptographic 856 authentication may not be available everywhere. However, its use 857 where it is available is highly reccomended. 859 A repository must reject a redistributed transaction that does not 860 include any ``repository-signature'' meta-object. 862 The transaction-label, the submitted text, the dependency objects, 863 the override-objects, the overriden objects, and the repository's 864 signature together constitute what we call the ``redistributed text''. 866 In preparation for redistributing the transaction to other reposito- 867 ries, the originating repository must perform the following protocol 868 encapsulation. This protocol encapsulation may involve transforming 869 the redistributed text according to one of the ``transfer-method''s 870 described below. 872 The transformed redistributed text is first prepended with exactly one 873 ``transaction-begin'' meta-object. One newline character separates 874 this meta-object from the redistributed text. This meta-object has 875 the following attributes: 877 transaction-begin This attribute is mandatory and single. The val- 878 ue of this attribute is the length, in bytes, of the transformed 879 redistributed text. 881 transfer-method This attribute is optional and single-valued. Its 882 value is either ``gzip'', or ``plain''. The value of the attribute 883 describes the kind of text encoding that the repository has per- 884 formed on the redistributed text. If this attribute is not speci- 885 fied, its value is assumed to be ``plain''. An implementation must 886 be capable of encoding and decoding both of these types. 888 The ``transaction-begin'' meta-object and the transformed redistribut- 889 ed text constitute what we call the ``transmitted text''. The origi- 890 nating repository may distribute the transmitted text to one or more 891 peer repositories. 893 When a repository receives the transmitted text of a transaction, 894 it must perform the following steps. After performing the following 895 steps, a transaction may be marked successful or failed. 897 1. It must decapsulate the ``transaction-begin'' meta-object, then de- 898 code the original redistributed text according to the value of the 899 transfer-method attribute specified in the ``transaction-begin'' 900 meta-object. 901 2. It should then extract the "transaction-label" meta-object from the 902 transmitted text. If this transaction has already been processed, 903 or is currently being held, the repository must silently discard 904 this incarnation of the same transaction. 906 3. It should verify that the signature of the originating reposito- 907 ry matches the first ``repository-signature'' meta-object in the 908 redistributed text following the ``auth-dependency'' meta-objects. 910 4. If not all previous (i.e., those with a lower sequence number) 911 transactions from the same repository have been received or com- 912 pletely processed, the repository must ``hold'' this transaction. 913 5. It may check whether any subsequent ``repository-signature'' meta- 914 objects were appended by a trusted repository. If so, this in- 915 dicates that the trusted repository verified the transaction's 916 integrity and marked its conclusion in the integrity attribute of 917 this object. The repository may verify the trusted repositories 918 signature and also mark the transaction with the same integrity, 919 and skip the remaining steps. 921 6. It should verify the syntactic correctness of the transaction. An 922 implementation may allow configurable levels of syntactic confor- 923 mance with RPSL [1]. This enables RPSL extensions to be incremen- 924 tally deployed in the distributed registry scheme. 926 7. The repository must authorize and authenticate this transaction. 927 To do this, it may need to reference objects and transactions from 928 other repositories. If these objects are not available, the repos- 929 itory must ``hold'' this transaction as described in Section 7.6, 930 until it can be authorized and authenticated later. In order to 932 verify authorization/authentication of this transaction, the repos- 933 itory must not use an object from a repository not mentioned in an 934 ``auth-dependency'' meta-obect. The repository should also only 935 use the latest objects (by rolling back to earlier versions if nec- 936 essary) which are within the transaction sequence numbers of the 937 ``auth-dependency'' meta-objects. 939 A non-originating repository must redistribute a failed transaction 940 in order not to cause a gap in the sequence. (If the transaction was 941 to fail at the originating registry, it would simply not be assigned a 942 sequence number). 944 To the redistributed text of a transaction, a repository may append 945 another ``repository-signature'' meta-object. This indicates that the 946 repository has verified the transaction's integrity and marked it in 947 the ``integrity'' attribute of this object. The signature covers the 948 new redistributed text from (and including) the transaction-label ob- 949 ject to this object's signature attribute (including the ``repository- 950 signature'' and ``integrity'' attributes of this object, but excluding 951 the ``signature'' attribute). The original redistributed text, to- 952 gether with the new ``repository-signature'' meta-object constitutes 953 the modified redistributed text. 955 To redistribute a successful or failed transaction, the repository 956 must encapsulate the (original or modified) redistributed text with 957 a ``transaction-begin'' object. This step is essentially the same as 958 that performed by the originating repository (except that the reposi- 959 tory is free to use a different ``transfer-method'' from the one that 960 was in the received transaction. 962 7.3.1 Explicitly Requesting Transactions 964 A repository may also explicitly request one or more transactions be- 965 longing to a specified originating repository. This is useful for 966 catching up after a repository has been off-line for a period of time. 967 It is also useful for mirrors which intermittently poll a repository 968 for recently received transactions. 970 To request a range of transactions from a peer, a repository must send 971 a ``transaction-request'' meta-object to the peer. A ``transaction- 972 request'' meta-object may contain the following attributes: 974 transaction-request This attribute is mandatory and single. It con- 975 tains the name of the database whose transactions are being re- 976 quested. 977 sequence-begin This attribute is optional and single. It contains 978 the sequence number of the first transaction being requested. 980 sequence-end This attribute is optional and single. It contains the 981 sequence number of the last transaction being requested. 983 Upon receiving a ``transaction-request'' object, a repository performs 984 the following actions. If the ``sequence-begin'' attribute is not 985 specified, the repository assumes the request first sequence number 986 to be 1. The last sequence number is the lesser of the value of the 987 ``sequence-end'' attributed and the highest completed transaction in 988 the corresponding database. The repository then, in order, transmits 989 the requested range of transactions. Each transaction is prepared 990 exactly according to the rules for redistribution specified in Sec- 991 tion 7.3. 993 After transmitting all the transactions, the peer repository must 994 send a ``transaction-response'' meta-object. This meta-object has the 995 following attributes: 997 transaction-response This attribute is mandatory and single. It 998 contains the name of the database whose transactions are were re- 999 quested. 1000 sequence-begin This attribute is optional and mandatory. It con- 1001 tains the value of the ``sequence-begin'' attribute in the original 1002 request. It is omitted if the corresponding attribute was not 1003 specified in the original request. 1005 sequence-end This attribute is optional and mandatory. It contains 1006 the value of the ``sequence-end attribute in the original request. 1007 It is omitted if the corresponding attribute was not specified in 1008 the original request. 1010 After receiving a ``transaction-response'' meta-object, a repository 1011 may tear down the TCP connection to its peer. This is useful for mir- 1012 rors that intermittently resynchronize transactions with a repository. 1013 If the TCP connection stays open, repositories exchange subsequen- 1014 t transactions according to the redistribution mechanism specified 1015 in Section 7.3. While a repository is responding to a transaction- 1016 request, it MAY forward heartbeats and other transactions from the 1017 requested repository towards the requestor. 1019 7.3.2 Heartbeat Processing 1021 Each repository that has originated at least one transaction must pe- 1022 riodically send a ``heartbeat'' meta-object. The interval between two 1023 successive transmissions of this meta-object is configurable but must 1024 be less than 1 day. This meta-object serves to indicate the liveness 1025 of a particular repository. The repository liveness determines how 1026 long transactions are held (See Section 7.6). 1028 The ``heartbeat'' meta-object contains the following attributes: 1030 heartbeat This attribute is mandatory and single. It contains the 1031 name of the repository which originates this meta-object. 1033 sequence This attribute is mandatory and single. It contains the 1034 highest transaction sequence number that has been assigned by the 1035 repository. 1036 timestamp This attribute is mandatory and single. It contains the 1037 time at which this meta-object was generated. The format of this 1038 attribute is ``YYYYMMDD hh:mm:ss [+/-]xx:yy'', where ``YYYY'' spec- 1039 ifies the four digit year, ``MM'' represents the month, ``DD'' the 1040 date, ``hh'' the hour, ``mm'' the minutes, ``ss'' the seconds of 1041 the timestamp, and ``xx'' and ``yy'' represents the hours and min- 1042 utes respectively that that timestamp is ahead or behind UTC. 1044 Upon receiving a heartbeat meta-object, a repository must first check 1045 the timestamp of the latest previously received heartbeat message. 1046 If that timestamp exceeds the timestamp in the received heartbeat 1047 message, the repository must silently discard the heartbeat message. 1048 Otherwise, it must record the timestamp and sequence number in the 1049 heartbeat message, and redistribute the heartbeat message, without 1050 modification, to each of its peer repositories. 1052 If the heartbeat message is from a repository previously unknown to 1053 the recipient, the recipient may send a ``transaction-request'' to 1054 one or more of its peers to obtain all transactions belonging to the 1055 corresponding database. If the heartbeat message contains a sequence 1056 number higher than the highest sequence number processed by the recip- 1057 ient, the recipient may send a ``transaction-request'' to one or more 1058 of its peers to obtain all transactions belonging to the corresponding 1059 database. 1061 7.4 Transaction Commit 1063 Submitters may require stronger confirmation of commit for their 1064 transactions (Section 6.3). This section describes a simple request- 1065 response protocol by which a repository may provide this stronger 1066 confirmation, by verifying if one or more other repositories have 1067 committed the transaction. Implementation of this request-response 1068 protocol is optional. 1070 After it has redistributed a transaction, the originating repository 1071 may request a commit confirmation from one or more peer repositories 1072 by sending to them a ``commit-request'' meta-object. The ``commit- 1073 request'' contains two attributes: 1075 commit-request This attribute is mandatory and single. It contains 1076 the name of the database for whom a commit confirmation is being 1077 requested. 1079 sequence This attribute is mandatory and single. It contains the 1080 transaction sequence number for which a commit confirmation is be- 1081 ing requested. 1083 A repository that receives a ``commit-request'' must not redistribute 1084 the request. It must delay the response until the corresponding 1085 transaction has been processed. For this reason, the repository must 1086 keep state about pending commit requests. It should discard this s- 1087 tate if the connection to the requester is lost before the response 1088 is sent. In that event, it is the responsibility of the requester to 1089 resend the request. 1091 Once a transaction has been processed (Section 7.3), a repository must 1092 check to see if there exists any pending commit request for the trans- 1093 action. If so, it must send a ``commit-response'' meta-object to the 1094 requester. This meta-object has three attributes: 1096 commit-response This attribute is mandatory and single. It contains 1097 the name of the database for whom a commit response is being sent. 1099 sequence This attribute is mandatory and single. It contains the 1100 transaction sequence number for which a commit response is being 1101 sent. 1103 commit-status This attribute is mandatory and single. It contain- 1104 s one of the keywords ``held'', ``error'', or ``succeeded''. The 1105 ``error'' keyword may be followed by an optional text string. The 1106 ``held'' keyword is returned when a repository containing a depen- 1107 dent object for authorization has expired. 1109 7.5 Database Snapshot 1111 A database snapshot provides a complete copy of a database. It is 1112 intended only for repository initialization or disaster recovery. A 1113 database snapshot is an out of band mechanism. A set of files are 1114 created periodically at the source repository. These files are then 1115 transferred to the requestor out of band (e.g. ftp transfer). The 1116 objects in these files are then registered locally. 1118 A snapshot of repository X contains the following set of files: 1120 X.db This file contains the RPSL objects of repository X, separated 1121 by blank lines. In addition to the RPSL objects and blank lines, 1122 comment lines can be present. Comment lines start with the charac- 1123 ter '#'. The comment lines are ignored. The file X.db ends in a 1124 special comment line ``# eof''. 1126 X..db This optional file if present contains the RPSL objects 1127 in X.db that are of class . The format of the file is same 1128 as that of X.db. 1129 X.transaction-label This file contains a transaction-label object 1130 that records the timestamp and the latest sequence number of the 1131 repository at the time of the snapshot. 1133 Each of these files can be optionally compressed uzing gzip. This is 1134 signified by appending the suffix .gz to the file name. Each of these 1135 files can optionally be PGP signed. In this case, the detached signa- 1136 ture with ASCII armoring and platform-independent text mode is stored 1137 in a file whose name is constructed by appending .sig to the file name 1138 of the file being signed. 1140 In order to construct a repository's contents from a snapshot, a 1141 repository downloads these files. After uncompressing and checking 1142 signatures, the repository records these objects in its database. 1143 No RPS authorization/authentication is done on these objects. The 1144 transaction-label object provides the seed for the replication pro- 1145 tocol to receive the follow on transactions from this repository. 1146 Hence, it is not crucial to download an up to the minute snapshot. 1148 After successfully playing a snapshot, it is possible that a repos- 1149 itory may receive a transaction from a third repository that has a 1150 dependency on an earlier version of one of the objects in the snap- 1151 shot. This can only happen within the expire period of the repository 1152 being downloaded, plus any possible network partition period. This 1153 dependency is only important if the repository wants to re-verify RPS 1154 authorization/authentication. There are three allowed alternatives 1155 in this case. The simplest alternative is for the repository to ac- 1156 cept the transaction and mark it with integrity ``no-auth''. The 1157 second choice is to only peer with trusted repositories during this 1158 time period, and accept the transaction with the same integrity as the 1159 trusted repository (possibly as ``authorized''). The most preferred 1160 alternative is not to download an up to the minute snapshot, but to 1161 download an older snapshot, at minimum twice the repositories expire 1162 time, in practice few days older. Upon replaying an older snapshot, 1163 the replication protocol will fetch the more current transactions 1164 from this repository. Together they provide the necessary versions of 1165 objects to re-verify rps authorization/authentication. 1167 7.6 Authenticating Operations 1169 The ``signature'' and ``repository-signature'' meta-objects represent 1170 signatures. Where multiple of these objects are present, the signa- 1171 tures should be over the original contents, not over other signatures. 1172 This allows signatures to be checked in any order. 1174 A maintainer can also sign a transaction using several authentication 1175 methods (some of which may be available in some repositories only). 1177 In the case of PGP, implementations should allow the signatures of the 1178 ``signature'' and ``repository-signature'' meta-objects to be either 1179 the detached signatures produced by PGP or regular signatures produced 1180 by PGP. In either case, ASCII armoring and platform-independent text 1181 mode should be used. 1183 Note that the RPSL objects themselves are not signed but the entire 1184 transaction body is signed. When exchanging transactions among reg- 1185 istries, the meta-objects (e.g. ``auth-dependency'') prior to the 1186 first ``repository-signature'' meta object in the redistributed text 1187 are also signed over. 1189 Transactions must remain intact, including the signatures, even if 1190 an authentication method provided by the submitter is not used by 1191 a repository handling the message. An originating repository may 1192 chose to remove clear text passwords signatures from a transaction, 1193 and replace it with the keyword ``clear-text-passwd'' followed by the 1194 maintainer's id. 1196 signature: clear-text-passwd 1198 Note that this does not make the system less secure since clear text 1199 password is an indication of total trust to the originating repository 1200 by the maintainer. 1202 A repository may sign a transaction that it verified. If at any point 1203 the signature of a trusted repository is encountered, no further au- 1204 thorization or authentication is needed. 1206 A Examples 1208 RPSL provides an external representation of RPSL objects and at- 1209 tributes. An attribute is a name/value pair. RPSL is line orient- 1210 ed. Line continuation is supported, however most attributes fit on 1211 a single line. The attribute name is followed by a colon, then any 1212 amount of whitespace, then the attribute value. An example of the 1213 ASCII representation of an RPSL attribute is the following: 1215 route: 140.222.0.0/16 1217 An RPSL object is a set of attributes. Objects are separated from 1218 each other by one or more blank lines. An example of a complete RPSL 1219 object follows: 1221 route: 140.222.0.0/16 1222 descr: ANS Communications 1223 origin: AS1673 1224 member-of: RS-ANSOSPFAGGREGATE 1225 mnt-by: ANS 1226 changed: tck@ans.net 19980115 1227 source: ANS 1229 A.1 Initial Object Submission and Redistribution 1231 Figure 1 outlines the steps involved in submitting an object and the 1232 initial redistribution from the authoritative registry to its flooding 1233 peers. 1235 If the authorization check requires objects from other repositories, 1236 then the sequence numbers of the local copies of those databases is 1237 required for mirrors to recheck the authorization. 1239 To simply resubmit the object from the prior example, the submitter 1240 or a client application program acting on the submitter's behalf must 1241 submit a transaction. The legacy method was to send PGP signed email. 1242 The preferred method is for an interactive program to encapsulate a 1243 request between ``transaction-submit-begin'' and ``transaction-submit- 1244 end'' meta-objects and encapsulate that as a signed block as in the 1245 following example: 1247 transaction-submit-begin: ANS 1 1248 response-auth-type: PGP 1249 transaction-confirm-type: normal 1251 route: 140.222.0.0/16 1252 descr: ANS Communications 1253 origin: AS1673 1254 member-of: RS-ANSOSPFAGGREGATE 1255 mnt-by: ANS 1256 changed: curtis@ans.net 19990401 1257 +--------------+ 1258 | Transaction | 1259 | signed by | 1260 | submitter | 1261 +--------------+ 1262 | 1263 | 1 1264 v 1265 +---------------------+ 2 1266 | Primary repository |---->+----------+ 1267 | identified by | | database | 1268 | RPSL source |<----+----------+ 1269 +---------------------+ 3 1270 | 1271 | 4 1272 v 1273 +----------------+ 1274 | Redistributed | 1275 | transaction | 1276 +----------------+ 1278 1. submit object 1279 2. authorization check 1280 3. sequence needed for authorization 1281 4. redistribute 1283 Figure 1: Initial Object Submission and Redistribution 1285 source: ANS 1287 timestamp: 19990401 10:30:00 +08:00 1289 signature: 1290 + -----BEGIN PGP SIGNATURE----- 1291 + Version: PGP for Personal Privacy 5.0 1292 + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI 1293 + 1294 + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U 1295 + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX 1296 + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv 1297 + PGBIEN3/NlM= 1298 + =c93c 1299 + -----END PGP SIGNATURE----- 1301 transaction-submit-end: ANS 1 1303 The signature covers the everything after the first blank line after 1304 the ``transaction-submit-begin'' object to the last blank line before 1305 the ``signature'' meta-object. If multiple signatures are needed, it 1306 would be quite easy to email this block and ask the other party to add 1307 a signature-block and return or submit the transaction. Because of 1308 delay in obtaining multiple signatures the accuracy of the ``times- 1309 tamp'' cannot be strictly enforced. Enforcing accuracy to within the 1310 ``expire'' time of the database might be a reasonable compromise. The 1311 tradeoff is between convenience, allowing a longer time to obtain 1312 multiple signatures, and increased time of exposure to replay attack. 1314 The ANS repository would look at its local database and make autho- 1315 rization checks. If the authorization passes, then the sequence num- 1316 ber of any other database needed for the authorization is obtained. 1318 If this operation was successful, then a confirmation would be re- 1319 turned. The confirmation would be of the form: 1321 transaction-confirm: ANS 1 1322 confirmed-operation: change route 140.222.0.0/16 AS1673 1323 commit-status: commit 1324 timestamp: 19990401 10:30:10 +05:00 1326 A.2 Transaction Redistribution Encoding 1328 Having passed the authorization check the transaction is given a se- 1329 quence number and stored in the local transaction log and is then 1330 flooded. The meta-object flooded to another database would be signed 1331 by the repository and would be of the following form: 1333 transaction-label: ANS 1334 sequence: 6666 1335 timestamp: 19990401 13:30:10 +05:00 1336 integrity: authorized 1338 route: 140.222.0.0/16 1339 descr: ANS Communications 1340 origin: AS1673 1341 member-of: RS-ANSOSPFAGGREGATE 1342 mnt-by: ANS 1343 changed: curtis@ans.net 19990401 1344 source: ANS 1346 timestamp: 19990401 10:30:00 +08:00 1347 signature: 1348 + -----BEGIN PGP SIGNATURE----- 1349 + Version: PGP for Personal Privacy 5.0 1350 + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI 1351 + 1352 + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U 1353 + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX 1354 + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv 1355 + PGBIEN3/NlM= 1356 + =c93c 1357 + -----END PGP SIGNATURE----- 1359 auth-dependency: ARIN 1360 sequence: 555 1361 timestamp: 19990401 13:30:08 +05:00 1363 auth-dependency: RADB 1364 sequence: 4567 1365 timestamp: 19990401 13:27:54 +05:00 1367 repository-signature: ANS 1368 signature: 1369 + -----BEGIN PGP SIGNATURE----- 1370 + Version: PGP for Personal Privacy 5.0 1371 + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI 1372 + 1373 + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U 1374 + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX 1375 + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv 1376 + PGBIEN3/NlM= 1377 + =c93c 1378 + -----END PGP SIGNATURE----- 1380 Note that the repository-signature above is a detached signature for 1381 another file and is illustrative only. The repository-signature cov- 1382 ers from the ``transaction-label'' meta-object (including) to the last 1383 blank line before the first ``repository-signature'' meta-object (ex- 1384 cluding the last blank line and the ``repository-signature'' object). 1386 A.3 Transaction Protocol Encoding 1388 transaction-begin: 1276 1389 transfer-method: plain 1391 transaction-label: ANS 1392 sequence: 6666 1393 timestamp: 19990401 13:30:10 +05:00 1394 integrity: authorized 1396 route: 140.222.0.0/16 1397 descr: ANS Communications 1398 origin: AS1673 1399 member-of: RS-ANSOSPFAGGREGATE 1400 mnt-by: ANS 1401 changed: curtis@ans.net 19990401 1402 source: ANS 1404 timestamp: 19990401 10:30:00 +08:00 1406 signature: 1407 + -----BEGIN PGP SIGNATURE----- 1408 + Version: PGP for Personal Privacy 5.0 1409 + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI 1410 + 1411 + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U 1412 + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX 1413 + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv 1414 + PGBIEN3/NlM= 1415 + =c93c 1416 + -----END PGP SIGNATURE----- 1418 auth-dependency: ARIN 1419 sequence: 555 1420 timestamp: 19990401 13:30:08 +05:00 1422 auth-dependency: RADB 1423 sequence: 4567 1424 timestamp: 19990401 13:27:54 +05:00 1426 repository-signature: ANS 1427 signature: 1428 + -----BEGIN PGP SIGNATURE----- 1429 + Version: PGP for Personal Privacy 5.0 1430 + MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI 1431 + 1432 + iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U 1433 + Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX 1434 + Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv 1435 + PGBIEN3/NlM= 1436 + =c93c 1437 + -----END PGP SIGNATURE----- 1439 Before the transaction is sent to a peer, the repository prepends a 1440 ``transaction-begin'' meta-object. The value of the ``transaction- 1441 begin'' attribute is the number of octets in the transaction, not 1442 counting the ``transaction-begin'' meta-object and the first blank 1443 line after it. 1445 Separating transaction-begin and transaction-label objects enables 1446 different encodings at different flooding peerings. 1448 A.4 Transaction Redistribution 1450 The last step in Figure 1 was redistributing the submitter's trans- 1451 action through flooding (or later through polling). Figure 2 illus- 1452 trates the further redistribution of the transaction. 1454 +----------------+ 1455 | Redistributed | 1456 | transaction | 1457 +----------------+ 1458 | 1459 | 1 1460 v 1461 +--------------------+ 2 1462 | |---->+----------+ 1463 | Mirror repository | | database | 1464 | |<----+----------+ 1465 +--------------------+ 3 1466 | 1467 | 4 1468 v 1469 +------------------+ 1470 |+----------------+| 1471 || Redistributed || 1472 || transaction || 1473 |+----------------+| 1474 | Optional | 1475 | signature | 1476 +------------------+ 1478 1. redistribute transaction 1479 2. recheck authorization against full DB at the 1480 time of the transaction using sequence numbers 1481 3. authorization pass/fail 1482 4. optionally sign then redistribute 1484 Figure 2: Further Transaction Redistribution 1486 If the authorization check was repeated, the mirror may optionally add 1487 a repository-signature before passing the transaction any further. A 1488 ``signature'' can be added within that block. The previous signatures 1489 should not be signed. 1491 Figure 3 illustrates the special case referred to as a ``lightweight 1492 mirror''. This is specifically intended for routers. 1494 +----------------+ 1495 | Redistributed | 1496 | transaction | 1497 +----------------+ 1498 | 1 1499 v 1500 +--------------------+ 2 1501 | |---->+----------+ 1502 | Mirror repository | | database | 1503 | |<----+----------+ 1504 +--------------------+ 3 1505 | 4 1506 v 1507 +----------------+ 1508 | Redistributed | 1509 | transaction | 1510 +----------------+ 1511 | 5 1512 v 1513 +--------------------+ 1514 | Lightweight | 6 +----------+ 1515 | Mirror repository |---->| database | 1516 | (router?) | +----------+ 1517 +--------------------+ 1519 1. redistribute transaction 1520 2. recheck authorization against full DB at the 1521 time of the transaction using sequence numbers 1522 3. authorization pass/fail 1523 4. sign and redistribute 1524 5. just check mirror signature 1525 6. apply change with no authorization check 1527 Figure 3: Redistribution to Lightweight Mirrors 1529 The lightweight mirror must trust the mirror from which it gets a 1530 feed. This is a safe assumption if the two are under the same admin- 1531 istration (the mirror providing the feed is a host owned by the same 1532 ISP who owns the routers). The lightweight mirror simply checks the 1533 signature of the adjacent repository to insure data integrity. 1535 B Technical Discussion 1537 B.1 Server Processing 1539 This document does not mandate any particular software design, pro- 1540 gramming language choice, or underlying database or underlying operat- 1541 ing system. Examples are given solely for illustrative purposes. 1543 B.1.1 getting connected 1545 There are two primary methods of communicating with a repository serv- 1546 er. E-mail can be sent to the server. This method may be deprecated 1547 but at least needs to be supported during transition. The second 1548 method is preferred, connect directly to a TCP socket. 1550 Traditionally the whois service is supported for simple queries. It 1551 might be wise to retain the whois port connection solely for simple 1552 queries and use a second port not in the reserved number space for 1553 all other operations including queries except those queries using the 1554 whois unstructured single line query format. 1556 There are two styles of handling connection initiation is the dedi- 1557 cated daemon, in the style of BSD sendmail, or launching through a 1558 general purpose daemon such as BSD inetd. E-mail is normally handled 1559 sequentially and can be handled by a front end program which will make 1560 the connection to a socket in the process as acting as a mail delivery 1561 agent. 1563 B.1.2 rolling transaction logs forward and back 1565 There is a need to be able to easily look back at previous states of 1566 any database in order to repeat authorization checks at the time of 1567 a transaction. This is difficult to do with the RIPE database imple- 1568 mentation, which uses a sequentially written ASCII file and a set of 1569 Berkeley DB maintained index files for traversal. At the very min- 1570 imum, the way in which deletes or replacements are implemented would 1571 need to be altered. 1573 In order to easily support a view back at prior versions of object- 1574 s, the sequence number of the transaction at which each object was 1575 entered would need to be kept with the object. A pointer would be 1576 needed back to the previous state of the object. A deletion would 1577 need to be implemented as a new object with a deleted attribute, re- 1578 placing the previous version of the object but retaining a pointer 1579 back to it. 1581 A separate transaction log needs to be maintained. Beyond some age, 1582 the older versions of objects and the the older transaction log en- 1583 tries can be removed although it is probably wise to archive them. 1585 B.1.3 committing or disposing of transactions 1587 The ability to commit large transaction, or reject them as a whole 1588 poses problems for simplistic database designs. This form of commit 1589 operation can be supported quite easily using memory mapped files. 1590 The changes can be made in virtual memory only and then either commit- 1591 ted or disposed of. 1593 B.1.4 dealing with concurrency 1595 Multiple connections may be active. In addition, a single connection 1596 may have multiple outstanding operations. It makes sense to have a 1597 single process or thread coordinate the responses for a given connec- 1598 tion and have multiple processes or threads each tending to a single 1599 operation. The operations may complete in random order. 1601 Locking on reads is not essential. Locking before write access is es- 1602 sential. The simplest approach to locking is to lock at the database 1603 granularity or at the database and object type granularity. Finer 1604 locking granularity can also be implemented. Because there are mul- 1605 tiple databases, deadlock avoidance must be considered. The usual 1606 deadlock avoidance mechanism is to acquire all necessary locks in a 1607 single operation or acquire locks in a prescribed order. 1609 B.2 Repository Mirroring for Redundancy 1611 There are numerous reasons why the operator of a repository might 1612 mirror their own repository. Possibly the most obvious are redundan- 1613 cy and the relative ease of disaster recovery. Another reason might 1614 be the widespread use of a small number of implementations (but more 1615 than one) and the desire to insure that the major repository soft- 1616 ware releases will accept a transaction before fully committing to the 1617 transaction. 1619 The operation of a repository mirror used for redundancy is quite s- 1620 traightforward. The transactions of the primary repository host can 1621 be immediately fed to the redundant repository host. For tighter as- 1622 surances that false positive confirmations will be sent, as a matter 1623 of policy the primary repository host can require commit confirmation 1624 before making a transaction sequence publicly available. 1626 There are many ways in which the integrity of local data can be as- 1627 sured regardless of a local crash in the midst of transaction disk 1628 writes. For example, transactions can be implemented as memory mapped 1629 file operations, with disk synchronization used as the local commit 1630 mechanism, and disposal of memory copies of pages used to handle com- 1631 mit failures. The old pages can be written to a separate file, the 1632 new pages written into the database. The transaction can be logged 1633 and old pages file can then be removed. In the event of a crash, the 1634 existence of a old pages file and the lack of a record of the transac- 1635 tion completing would trigger a transaction roll back by writing the 1636 old pages back to the database file. 1638 The primary repository host can still sustain severe damage such as a 1639 disk crash. If the primary repository host becomes corrupted, the use 1640 of a mirror repository host provides a backup and can provide a rapid 1641 recovery from disaster by simply reversing roles. 1643 If a mirror is set up using a different software implementation with 1644 commit mirror confirmation required, any transaction which fails due 1645 a software bug will be deferred indefinitely allowing other trans- 1646 actions to proceed rather than halting the remote processing of all 1647 transactions until the bug is fixed everywhere. 1649 B.3 Trust Relationships 1651 If all repositories trust each other then there is never a need to 1652 repeat authorization checks. This enables a convenient interim step 1653 for deployment prior to the completion of software supporting that 1654 capability. The opposite case is where no repository trusts any other 1655 repository. In this case, all repositories must roll forward trans- 1656 actions gradually, checking the authorization of each remote transac- 1657 tion. 1659 It is likely that repositories will trust a subset of other reposi- 1660 tories. This trust can reduce the amount of processing a repository 1661 required to maintain mirror images of the full set of data. For exam- 1662 ple, a subset of repositories might be trustworthy in that they take 1663 reasonable security measures, the organizations themselves have the 1664 integrity not to alter data, and these repositories trust only a lim- 1665 ited set of similar repositories. If any one of these repositories 1666 receives a transaction sequence and repeats the authorization checks, 1667 other major repositories which trusts that repository need not re- 1668 peat the checks. In addition, trust need not be mutual to reap some 1669 benefit in reduced processing. 1671 As a transaction sequence is passed from repository to repository each 1672 repository signs the transaction sequence before forwarding it. If 1673 a receiving repository finds that any trusted repository has signed 1674 the transaction sequence it can be considered authorized since the 1675 trusted repository either trusted a preceding repository or repeated 1676 the authorization checks. 1678 B.4 A Router as a Minimal Mirror 1680 A router could serve as a minimal repository mirror. The following 1681 simplifications can be made. 1683 1. No support for repeating authorization checks or transaction au- 1684 thentication checks need be coded in the router. 1686 2. The router must be adjacent only to trusted mirrors, generally op- 1687 erated by the same organization. 1688 3. The router would only check the authentication of the adjacent 1689 repository mirrors. 1691 4. No support for transaction submission or query need be coded in the 1692 router. No commit support is needed. 1694 5. The router can dispose of any object types or attributes not needed 1695 for configuration of route filters. 1697 The need to update router configurations could be significantly re- 1698 duced if the router were capable of acting as a limited repository 1699 mirror. 1701 A significant amount of non-volatile storage would be needed. There 1702 are currently an estimated 100 transactions per day. If storage were 1703 flash memory with a limited number of writes, or if there were some 1704 other reason to avoid writing to flash, the router could only update 1705 the non-volatile copy every few days. A transaction sequence request 1706 can be made to get an update in the event of a crash, returning only a 1707 few hundred updates after losing a few days of deferred writes. The 1708 routers can still take a frequent or continuous feed of transactions. 1710 Alternately, router filters can be reconfigured periodically as they 1711 are today. 1713 B.5 Dealing with Errors 1715 If verification of an authorization check fails, the entire trans- 1716 action must be rejected and no further advancement of the repository 1717 can occur until the originating repository corrects the problem. If 1718 the problem is due to a software bug, the offending transaction can 1719 be removed manually once the problem is corrected. If a software bug 1720 exists in the receiving software, then the transaction sequence is 1721 stalled until the bug is corrected. It is better for software to er- 1722 ror on the side of denying a transaction than acceptance, since an 1723 error on the side of acceptance will require later removal of the 1724 effects of the transaction. 1726 C Deployment Considerations 1728 This section described deployment considerations. The intention is to 1729 raise issues rather than to provide a deployment plan. 1731 This document calls for a transaction exchange mechanism similar to 1732 but not identical to the existing ``near real time mirroring'' sup- 1733 ported by the code base widely used by the routing registries. As an 1734 initial step, the transaction exchange can be implemented without the 1735 commit protocol or the ability to recheck transaction authorization. 1736 This is a fairly minimal step from the existing capabilities. 1738 The transition can be staged as follows: 1740 1. Modify the format of ``near real time mirroring'' transaction ex- 1741 change to conform to the specifications of this document. 1742 2. Implement commit protocol and confirmation support. 1744 3. Implement remote recheck of authorization. Prior to this step all 1745 repositories must be trusted. 1747 4. Allow further decentralization of the repositories. 1749 D Privacy of Contact Information 1751 The routing registries have contained contact information. The redis- 1752 tribution of this contact information has been a delicate issue and in 1753 some countries has legal implications. 1755 The person and role objects contain contact information. These ob- 1756 jects are referenced by NIC-handles. There are some attributes such 1757 as the "changed" and "notify" attributes that require an email ad- 1758 dress. All of the fields that currently require an email address must 1759 also accept a NIC-handle. 1761 The person and role objects should not be redistributed by default. 1762 If a submission contains an email address in a field such as a changed 1764 field rather than a NIC-handle the submitter should be aware that they 1765 are allowing that email address to be redistributed and forfeiting any 1766 privacy. Repositories which do not feel that prior warnings of this 1767 forfeiture are sufficient legal protection should reject the submis- 1768 sion requesting that a NIC-handle be used. 1770 Queries to role and person objects arriving at a mirror must be re- 1771 ferred to the authoritative repository where whatever authentication, 1772 restrictions, or limitations deemed appropriate by that repository can 1773 be enforced directly. 1775 Software should make it possible to restrict the redistribution of 1776 other entire object types as long as those object types are not re- 1777 quired for the authorization of additions of other object types. It 1778 is not possible to redistribute objects with attributes removed or 1779 altered since this would invalidate the submitter's signature and make 1780 subsequent authentication checks impossible. Repositories should not 1781 redistribute a subset of the objects of a given type. 1783 Software should also not let a transaction contain both redis- 1784 tributable (e.g. policy objects) and non-redustributable objects 1785 (e.g. person) since there is no way to verify the signature of these 1786 transactions without the non-redustributable objects. 1788 When redistributing legacy data, contact information in attributes 1789 such as "changed" and "notify" should be stripped to maintain privacy. 1790 The "integrity" attribute on these objects should already be set to 1791 "legacy" indicating that their origin is questionable, so the issue of 1792 not being able to recheck signatures is not as significant. 1794 References 1796 [1] C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, 1797 T. Bates, D. Karrenberg, and M. Terpstra. Routing Policy Spec- 1798 ification Language (RPSL). Technical Report RFC 2622, Internet 1799 Engineering Task Force, 1999. 1801 [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 1802 M. Terpstra, and J. Yu. Representation of IP Routing Policies 1803 in a Routing Registry (ripe-81++). Technical Report RFC 1786, 1804 Internet Engineering Task Force, 1995. 1806 [3] David Meyer, Curtis Villamizar, Cengiz Alaettinoglu, and S. Mur- 1807 phy. Routing Policy System Security. Internet Draft (Work in 1808 Progress) draft-ietf-rps-auth-04, Internet Engineering Task 1809 Force, 7 1999. 1810 [4] Janos Zsako. PGP authentication for RIPE database updates. Inter- 1811 net Draft (Work in Progress) draft-ietf-rps-dbsec-pgp-authent-01, 1812 Internet Engineering Task Force, 4 1999. 1814 Security Considerations 1816 An authentication and authorization model for routing policy object 1817 submission is provided by [3]. Cryptographic authentication is ad- 1818 dressed by [4]. This document provides a protocol for the exchange of 1819 information among distributed routing registries such that the autho- 1820 rization model provided by [3] can be adhered to by all registries and 1821 any deviation (hopefully accidental) from those rules on the part of a 1822 registry can be identified by other registries or mirrors. 1824 Author's Addresses 1826 Curtis Villamizar Cengiz Alaettinoglu 1827 Avici Systems ISI 1828 1830 Ramesh Govindan David M. Meyer 1831 ISI Cisco 1832 1834 Full Copyright Statement 1836 Copyright (C) The Internet Society (October 13, 1999). All Rights 1837 Reserved. 1839 This document and translations of it may be copied and furnished to 1840 others, and derivative works that comment on or otherwise explain it 1841 or assist in its implmentation may be prepared, copied, published and 1842 distributed, in whole or in part, without restriction of any kind, 1843 provided that the above copyright notice and this paragraph are in- 1844 cluded on all such copies and derivative works. However, this doc- 1845 ument itself may not be modified in any way, such as by removing the 1846 copyright notice or references to the Internet Society or other In- 1847 ternet organizations, except as needed for the purpose of developing 1848 Internet standards in which case the procedures for copyrights defined 1849 in the Internet Standards process must be followed, or as required to 1850 translate it into languages other than English. 1852 The limited permissions granted above are perpetual and will not be 1853 revoked by the Internet Society or its successors or assigns. 1855 This document and the information contained herein is provided on an 1856 ``AS IS'' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEER- 1857 ING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUD- 1858 ING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1859 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 1860 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1862 Notices 1864 The IETF takes no position regarding the validity or scope of any in- 1865 tellectual property or other rights that might be claimed to pertain 1866 to the implementation or use of the technology described in this doc- 1867 ument or the extent to which any license under such rights might or 1868 might not be available; neither does it represent that it has made 1869 any effort to identify any such rights. Information on the IETF's 1870 procedures with respect to rights in standards-track and standards- 1871 related documentation can be found in BCP-11. Copies of claims of 1872 rights made available for publication and any assurances of licenses 1873 to be made available, or the result of an attempt made to obtain a 1874 general license or permission for the use of such proprietary rights 1875 by implementors or users of this specification can be obtained from 1876 the IETF Secretariat. 1878 The IETF invites any interested party to bring to its attention any 1879 copyrights, patents or patent applications, or other proprietary 1880 rights which may cover technology that may be required to practice 1881 this standard. Please address the information to the IETF Executive 1882 Director.