idnits 2.17.1 draft-ietf-rps-dist-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 29, 1998) is 9341 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) ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '2') == Outdated reference: A later version (-04) exists of draft-ietf-rps-auth-01 Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Curtis Villamizar 3 INTERNET-DRAFT ANS 4 draft-ietf-rps-dist-00 Cengiz Alaettinoglu 5 ISI 6 Ramesh Govindan 7 ISI 8 David M. Meyer 9 University of Oregon 10 September 29, 1998 12 Distributed Routing Policy System 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To view the entire list of current Internet-Drafts, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 The RIPE database specifications [2] and RPSL language [1] define 35 languages used as the basis for representing information in a routing 36 policy system. A repository for routing policy system information is 37 known as a routing registry. A routing registry provides a means of 38 exchanging information needed to address many issues on importance to 39 the operation of the Internet. The implementation and deployment of a 40 routing policy system must maintain some degree of integrety to be of 41 any use. The Routing Policy System Security internet-draft [3] 42 addresses the need to assure integrety of the data by proposing an 43 authentication and authorization model. This document addresses the 44 need to distribute data over multiple repositories and delegate author- 45 ity for data subsets to multiple repositories without compromising the au- 46 thorization model extablished in [3]. 48 1 Overview 50 A routing registry must maintain some degree of integrety to be of any 51 use. The IRR is increasingly used for purposes that have a stronger 52 requirement for data integrety and security. There is also a desire 53 to further decentralize the IRR. This document proposes a means of de- 54 centralizing the routing registry in a way that is consistent with the 55 usage of the IRR and which avoids compromising data integrety and se- 56 curity even if the IRR is distributed among less trusted repositories. 58 Two methods of authenticating the routing registry information have 59 been proposed. 61 authorization and authentication checks on transactions: The itegrety 62 of the routing registry data is insured by repeating authorization 63 checks as transactions are processed. As transactions are flooded 64 each remote registry has the option to repeat the authorization and 65 authentication checks. This scales with the total number of 66 changes to the registry regardless of how many registries exist. 67 When querying, the integrety of the repository must be such that it 68 can be trusted. If an organization is unwilling to trust any of 69 the available repositories or mirrors they have the option to run 70 their own mirror and repeat authorization checks at that mirror 71 site. Queries can then be directed to a mirror under their own admin- 72 istration which presumably can be trusted. 73 signing routing registry objects: An alternate which appears on the 74 surface to be attractive is signing the objects themselves. Closer 75 examination reveals that the approach of signing objects by itself 76 is flawed and when used in addition to signing transactions and 77 rechecking authorizations as changes are made adds nothing. In 78 order for an insertion of critical objects such as inetnums and 79 routes to be valid, authorization checks must be made which allow 80 the insertion. The objects on which those authorization checks are 81 made may later change. In order to later repeat the authorization 82 checks the state of other objects, possibly in other repositories 83 would have to be known. If the repository were not trusted then the 84 change history on the object would have to be traced back to the ob- 85 ject's insertion. If the repository were not trusted, the change his- 86 tory of any object that was depended upon for authorization would also 87 have to be rechecked. This trace back would have to go back to the epoch 88 or at least to a point where only trusted objects were being relied upon 89 for the authorizations. If the depth of the search is at all limited, 90 authorization could be falsified simply by exceeding the search depth 91 with a chain of authorization references back to falsified objects. This 92 would be grossly inefficient. Simply verifying that an object is signed 93 provides no assurance that addition of the object addition was prop- 94 erly authorized. 96 A distinction is made between a repository and a mirror. A repository 97 has responsibility for the initial authorization and authentication 98 checks for transsactions related to its local objects which are then 99 flooded to adjacent repositories (either by unicast flooding or by 100 multicast in subsets of the topology of repository adjacencies). A 101 mirror receives flooded transactions from remote repositories but 102 contains no local objects. From a protocl standpoint, repositories 103 and mirrors appear identical in the flooding topology. 105 Either a repository or a mirror may recheck all or a subset of 106 transactions that are flooded to it. A repository or mirror may elect 107 not to recheck authorization and authentication on transactions 108 received from a trusted adjacency on the grounds that the adjacent 109 repository is trusted and would not have flooded the information 110 unless authorization and authentication checks had been made. 112 If it can be arranged that all adjacencies are trusted for a given 113 mirror, then there is no need to implement the code to check autho- 114 rization and authentication. There is only a need to be able to check 115 the signatures on the flooded transactions of the adjacent repository. 116 This is an important special case because it could allow a router to 117 act as a mirror. Only changes to the registry database would be 118 recieved thorugh flooding, which is a very low volume. Only the sig- 119 nature of the adjacent mirror or repocitory would have to be checked. 121 2 Data Representation 123 RPSL provides a complete description of the contents of a routing 124 repository [1]. Many RPSL data objects remain unchanged from the RIPE 125 and RPSL references the RIPE-181 specification as recorded in RFC-1786 126 [2]. RPSL provides external data representation. Data may be stored 127 differently internal to an routing registry. 129 Some form of encapsulation must be used to exchange data. The defacto 130 encapsulation has been that which the RIPE tools accept, a plain text 131 file or plain text in the body of an RFC-822 formatted mail message 132 with information needed for authentication derived from the mail head- 133 ers. Merit has slightly modified this using the PGP signed portion of 134 a plain text file or PGP signed portion of the body of a mail message. 136 The exchange that occurs during flooding differs from the initial 137 submission. In order to repeat the authorization checks the state of 138 all repositories containing objects referenced by the authorization 139 checks needs to be known. To accomplish this a sequence number is 140 associated with each transaction in a repository and the flooded 141 transactions must contain the sequence number of each repository on 142 which authorization of the transaction depends. 144 In order to repeat authorization checks it must be possible to re- 145 trieve back revisions of objects. How this is accomplished is a mat- 146 ter local to the implementation. One method which is quite simple is 147 to keep the traversal data structures to all current objects even if 148 the state is deleted, keep the sequence number that the version of the 149 object became effective and keep back links to prior versions of the 150 objects. Finding a prior version of an object involves looking back 151 through the references until the sequence number of the version of the 152 object is less than or equal to the seqence number being searched for. 154 The existing very simple forms of encapsulation are adequate for the 155 initial submission of a database transaction and should be retained as 156 long as needed for backward compatibility. A more robust 157 encapsulation and submission protocol, with optional confirmation is 158 defined in Section 5.1. An encapsulation suitable for exchange of 159 transaction between repositories is addressed in Section 5. Query 160 encapsulation and protocol is outside the scope of this document. 162 3 Athentication and Authorization 164 Control must be exercised over who can make changes and what changes 165 they can make. The distinction of who vs what separates 166 authentication from authorization. 168 o Authentication is the means to determine who is attempting to make 169 a change. 171 o Authorization is the determination of whether a transaction passing 172 a specific authentication check is allowed to perform a given 173 operation. 175 A submitted transaction contains a claimed identity. Depending on the 176 type of transaction, the authorization will depend on related objects. 177 The ``mnt-by'' or ``mnt-routes'' attributes in those related objects 178 reference ``maintainer'' objects. Those maintainer objects contain 179 ``auth'' attributes. The auth attributes contain an authorization 180 method and data which generally contains the claimed identity and some 181 form of public encryption key used to authenticate the claim. 183 Authentication is done on transactions. Authentication should also be 184 done between repositories to insure the integrety of the information 185 exchange. In order to comply with import, export, and use 186 restrictions throughout the world no encryption capability is 187 specified. Transactions must not be encrypted because it may be 188 illegal to use decryption software in some parts of the world. 190 4 Repository Hierachy 192 With multiple repositories, ``repository'' objects are needed to 193 propogate the existance of new repositories and provide an automated 194 means to determine the supported methods of access and other 195 characteristics of the repository. 197 The repository object is described in [3]. 199 In each repository there should be a special repository object named 200 ROOT. This should point to the root repository or to a higher level 201 repository. This is to allow queries to be directed to the local 202 repository but refer to the full set of registries for resolution of 203 hierarchically allocated objects. 205 Each repository may have a ``refresh'' and an ``expire'' attribute. 206 The refresh attribute may be used if transactions are exchanged in a 207 polling mode. Flooding is preferred. The expire attribute is used to 208 determine if a repository must be updated before a local transaction 209 can that depends on it can proceed. 211 The repository object also contains attributes describing the access 212 methods and supported authentication methods of the repository. The 213 ``query-address'' attribute provides a host name and a port number 214 used to direct queries. The ``response-auth-type'' attribute provides 215 the authentication types that may be used by the repository when 216 responding to queries. The ``submit-address'' attribute provides a 217 host name and a port number used to submit objects to the repository. 218 The ``submit-auth-type'' attribute provides the authentication types 219 that may be used by the repository when responding to queries. 221 5 Interactions with a Repository or Mirror 223 There are a few different types of interactions between routing 224 repositories or mirrors. 226 Initial submission of transactions: Transactions may include 227 additions, changes, and deletions. A transaction may operate on 228 more than one object and must be treated as an atomic operation. 229 By definition initial submission of transactions is not applicable 230 to a mirror. Initial submission of transactions is described in 231 Section 5.1. 233 Redistribution of Transactions: The primary purpose of the interac- 234 tions between registries is the redistribution of transactions. 235 There are a number of ways to redistribute transactions. Transac- 236 tions can also be recinded. This is discussed in Section 5.2. 238 Queries: Query interactions are outside the scope of this document. 239 Recinding Transactions Although it is hoped that the feature is never 240 needed, it may be necessary to recind transactions (Section 5.3). 242 Transaction Commit and Confirmation: Repositories may optionally 243 implement a commit protocol and a completion indication that gives 244 the submitter of a transaction an response that indicates that a 245 transaction has been successful and will not be lost by a crash of 246 the local repository. A submitter may optionally request such a 247 confirmation. This is discussed in Section 5.4. 249 5.1 Initial Transaction Submission 251 The simplest form of transaction submission is an object or set of 252 objects submitted with RFC--822 encapsulation. This form is still 253 supported for backwards compatibility. A preferred form allows some 254 meta-information to be included in the submission, such as a preferred 255 form of confirmation. Where either encapsulation is used, the 256 submitter will connect to a host and port specified in the repository 257 object. This allows immediate confirmation. If an email interface 258 similar to the interface provided by the existing RIPE code is 259 desired, then an external program can provide the email interface. 261 The encapsulation of a transaction submission and response is 262 described in detail in Section 6. 264 5.2 Redistribution of Transactions 266 Redistribution of transactions can be accomplished using unicast or 267 optionally using multicast capabilities. There are three types of 268 requests for redistribution of transactions. 270 1. A repository snapshots is a request for the complete contents of a 271 given repository. This is usually done when starting up a new 272 repository or mirror or when recovering from a disaster. 274 2. A transaction sequence exchange is a request for a specific set of 275 transactions. Often the request is for the most recent sequence 276 number known to a mirror to the last transactions. This is used in 277 polling. 279 3. Transaction flooding requests may be of two types. One type is a 280 request for a direct unicast feed. The other type of request is 281 for a multicast group on which a particular repository is flooded 282 using reliable multicast. 284 This section describes the operations somewhat qualitatively. Data 285 formats and state diagrams are provided in Section 6. 287 5.3 Recinding Transactions 289 Recinding a transaction is a manual intervention. The administrators 290 of a repository may find it necessary to request that a specific set 291 of transactions be removed. Database mirrors would have to roll back 292 the entire database to the first transaction being recinded and then 293 roll forward the transaction log from that point forward. 294 Authorizations in other repositories may be affected. 296 There are many reasons for having to recind a transaction whose cause 297 is outside the control of the operator of the repository. For exam- 298 ple, a disgruntled employee at a client of the repository may remove 299 all authorization from that clients database objects. There may be 300 opportunities for malicious entries in objects for which there is no 301 authorization hierarchy (See [3]). An example is the anonymous regis- 302 tration of falsified person objects or liablous or obescene person or 303 role objects. In addition, mistakes or program bugs are inevitable. 305 5.4 Transaction Commit and Confirmation 307 If a submission requires a strong confirmation of completion, or if a 308 higher degree of protection against false positive confirmation is 309 desired as a matter of repository policy, a commit may be performed. 311 A commit request is a request from the repository processing an 312 initial transaction submission to another repository to confirm that 313 they have been able to advance the transaction sequence up to the 314 sequence number immediately below the transaction in the request and 315 are willing to accept the transaction in the request as a further 316 advance in the sequence. This indicates that either the authorization 317 was rechecked by the responding repository and passed or that the 318 responding repository trusts the requesting repository and has 319 accepted the transaction. 321 A commit request can be sent to more than one alternate repository. 322 One commit completion response is sufficient to respond to the 323 submitter with a positive confirmation that the transaction has been 324 completed however the repository or submitter may optionally require 325 more than one. 327 6 Data Format Summaries 329 @@ This draft is in an early stage. This actual formats are likely to 330 change. @@ 332 RIPE-181 [2] and RPSL [1] data is represented externally as ASCII 333 text. Objects consist of a set of attributes. Attributes are name 334 value pairs. A single attribute is represented as a single line with 335 the name followed by a colon followed by whitespace characters (space, 336 tab, or line continuation) and followed by the value. Within a value 337 all whitespace is equivalent to a single space. Line continuation is 338 supported by a backslash at the end of a line or the following line 339 beginning with whitespace. When transferred externally attributes are 340 generally broken into shorter lines using line continuation though 341 this is not a requirement. An object is externally represented as a 342 series of attributes. Objects are separated by blank lines. 344 There are about 80 attribute types in the current RIPE schema and 345 about 15 object types. Some of the attributes are manditory in 346 certain objects. Some attributes may appear multiple times. One or 347 more attributes may for a key. Some attributes or sets of attributes 348 may be required to be unique. Some of the attributes may reference a 349 key field in an object type and may be required to be a valid 350 reference. Some attributes may be used in inverse lookups. 352 A review of the entire RIPE or RPSL schema would be too lengthy to 353 include here. Only the differences in the schema are described. 355 Interactions with the registry either use a legacy format or are 356 encapsulated using sets of name and value pairs that are formated like 357 RPSL objects. These are not part of RPSL and are referred to as 358 meta-objects. The meta-objects serve mostly as delimiters to the 359 transactions and to carry information about the type of operation. 361 6.1 Transaction Submit and Confirm 363 The defacto method for submitting database changes has been via email. 364 This method should be supported by an external application for back- 365 wards compatibility only. Merit has added the pgp-from authentication 366 method to the RADB (replaced by pgp-key in [3]), where the mail 367 headers are essentially ignored and the body of the mail message must 368 be PGP signed. For backwards compatibility objects submitted in an 369 email message, even if signed as a group, should be treated as 370 separate transactions as they are today. RFC--822 encapsulated 371 messages should default to a confirmation of type ``LEGACY''. 373 The meta-objects ``transaction-submit-begin'' and 374 ``transaction-submit-end'' delimit a transaction. A transaction is 375 handled as an atomic operation. If any part of the transaction fails 376 none of the changes take effect. For this reason a transaction can 377 only operate on a single database. 379 A socket connection is used to request queries or submit transactions. 380 An email interface may be provided by an external program that con- 381 nects to the socket. A socket connection must use the ``transaction- 382 submit-begin'' and ``transaction-submit-end'' delimiters but can 383 request a legacy style confirmation. Use of the email interface is 384 discouraged and the email interface will eventually be depricated. 385 Multiple transactions may be sent prior to the response for any single 386 transaction. Transactions may not complete in the order sent. 388 The ``transaction-submit-begin'' meta-object may contain the following 389 attributes. 391 transaction-submit-begin This attribute is manditory and single. The 392 value of the attribute contains name of the database and an identi- 393 fier that must be unique over the course of the socket connection. 394 response-auth-type See Section 6.6. 396 date-time-stamp See Section 6.6. 397 transaction-confirm-type This attribute is optional and single. A 398 confirmation type keyword must be provided. Keywords are ``none'', 399 ``legacy'', ``normal'', ``commit''. The confirmation type can be 400 followed by the option ``verbose''. 402 The ``transaction-submit-end'' meta-object consists of a single 403 attribute by the same name. It must contain the same database name 404 and identifier as the corresponding ``transaction-submit-begin'' 405 attribute. 407 Unless the confirmation type is ``none'' a confirmation is sent. If 408 the confirmation type is ``legacy'', then an email message of the form 409 currently sent by the RIPE database code will be returned on the 410 socket (suitable for submission to the sendmail program). 412 A ``normal'' confirmation does not require completion of the commit 413 protocol. A ``commit'' confirmation does. A ``verbose'' confirmation 414 may contains additional detail. 416 A transaction confirmation is returned as a ``transaction-confirm'' 417 meta-object. The ``transaction-confirm'' meta-object may have the 418 following attributes. 420 transaction-confirm This attribute is manditory and single. It 421 contains the database name and identifier associated with the 422 transaction. 424 confirmed-operation This attribute is optional and multiple. It 425 contains one of the keywords ``add'', ``delete'' or ``modify'' fol- 426 lowed by the object type and key fields of the object operated on. 427 commit-status See Section 6.6. 429 date-time-stamp See Section 6.6. 431 6.2 Transaction Commit 433 The commit protocol consists of two steps. 435 1. commit request 437 2. commit completion 439 The ``commit request'' consists of a set of delimiters around a single 440 transaction that has yet to be committed. The delimiters are the 441 ``mirror-request-begin'' meta-object and ``mirror-request-end'' 442 meta-object. The ``mirror-request-begin'' meta-object may contain the 443 following attributes. 445 mirror-request-begin This attribute is manditory and single. It 446 contains the database name and sequence number of the transaction 447 about to be committed. 449 date-time-stamp See Section 6.6. 451 The ``mirror-request-end'' meta-object consists of a single attribute 452 of the same name containing the same database name and sequence number 453 provided by the corresponding ``mirror-request-begin''. 455 The ``commit-completion'' meta-object is sent in response to a 456 ``commit request''. Prior to attempting completion the remote 457 database may have some catching up to do to reach the requested 458 sequence number. If so, the remote database will send a 459 ``transaction-request'' (Section 6.4) to bring its database copy to 460 the sequence number below the transaction being commited. 462 The ``commit-completion'' meta-object may contain the following 463 attributes. 465 commit-completion This attribute is manditory and single. It 466 contains the same name sequence number provided by the 467 corresponding ``mirror-request-begin''. 469 date-time-stamp See Section 6.6. 470 commit-status See Section 6.6. 472 6.3 Database Snapshot 474 A database snapshot provides a complete copy of a database. It is 475 intended only for repository initialization and and disaster recovery. 477 A database snapshot request is represented by a ``snapshot-request'' 478 meta-object. The ``snapshot-request'' meta-object may contain the the 479 following attributes. 481 snapshot-request This attribute is manditory and single. It contains 482 the database name of the database being requested. 484 response-auth-type See Section 6.6. 486 A database snapshot is returned. The database snapshot is delimited 487 by a ``shapshot-begin'' and ``shapshot-end'' meta-object. The 488 ``shapshot-begin'' meta-object may contain the following attributes. 490 shapshot-begin This attribute is manditory and single. It contains 491 the database name and sequence number of the database snapshot 492 being returned. 493 date-time-stamp See Section 6.6. 495 The ``shapshot-end'' meta-object contains a single attribute by the 496 same name containing the same database name and sequence number 497 provided in the corresponding ``shapshot-begin''. 499 6.4 Redistribution of Transactions 501 There are three ways to track database changes. One method is to join 502 a multicast group where a repository multicasts changes for a specific 503 database (see Section 6.4.3). The multicasting repository is not 504 necessarily the authoritative repository for the database). Another 505 method is to make a unicast connection and request unicast mirroring 506 for a specific repository (see Section 6.4.2). A third method is to 507 poll by requesting a transaction sequence (see Section 6.4.1). To get 508 updated to the current state of the database a request can be made 509 with the end sequence number set to the special value ``last''. 511 6.4.1 Polling for Specific Transaction Sequences 513 A transaction sequence can be requested by sending a 514 ``transaction-request'' meta-object. A ``transaction-request'' 515 meta-object may contain the following attributes. 517 transaction-request This attribute is manditory and single. It 518 contains the database name and a sequence list. The sequence list 519 is two sequence numbers separated by a dash. The keyword ``last'' 520 may be used in place of a number to indicate the last sequence 521 number available. The sequence list ``last-last'' can be requested 522 to simply get the last sequence number in an empty transaction 523 sequence. 524 response-auth-type See Section 6.6. 526 6.4.2 Unicast Flooding Redistribution 528 A unicast mirror request is represented by a ``unicast-mirror- 529 request'' meta-object which may contain the following attributes. 531 unicast-mirror-request This attribute is manditory and single. It 532 contains the database and next sequence number needed. This may 533 optionally followed by an maximum update frequency in seconds, a 534 heartbeat rate in minutes, and an idle timeout in minutes. If 535 there are no new transactions during the heartbeat period an empty 536 transaction sequence is sent. If there are no new transactions and 537 no other activity on the socket before the idle period the 538 connection is dropped. 540 response-auth-type See Section 6.6. 542 A unicast mirror request is answered by a unicast mirror response. 543 This is represented in a ``unicast-mirror-response'' meta-object, 544 which may contain one of the following attributes. 546 unicast-mirror-response This attribute is manditory and single. It 547 contains the name of the database. 549 unicast-mirror-status This attribute is optional and single. It may 550 contain the word ``rejected''. 551 unicast-referal This attribute is optional and multiple. It contains 552 the name of a that are known or likely to provide a unicast feed of 553 the requested database. 555 A repository may reject a request for a unicast feed for a variety of 556 reasons. Offering an alternative place to look may be helpful to the 557 requestor. The alternative could be adjacent repositories providing a 558 feed. 560 A unicast feed may be cancelled without disrupting other use of the 561 socket. See Section 6.4.6. 563 6.4.3 Multicast Redistribution 565 A multicast mirror request is represented by a ``multicast-mirror- 566 request'' meta-object which may contain the following attributes. 568 multicast-mirror-request This attribute is manditory and single. It 569 contains the database name to be mirrored. 570 response-auth-type See Section 6.6. 572 A multicast mirror request is answered with a multicast mirror 573 response. This is represented in a ``multicast-mirror-response'' 574 meta-object, which may contain one of the following attributes. 576 multicast-mirror-response This attribute is manditory and single. It 577 contains the name of the database to be mirrored. 578 multicast-mirror This attribute is optional and multiple. It cotains 579 a multicast group and the authentication type arguments of the 580 authentication methods used when multicasting. 582 multicast-referal This attribute is optional and multiple. It 583 contains the name of a repository that is known or likely to 584 multicast the requested database. 586 A ``multicast-mirror-response'' will be returned even if the database 587 is not being multicast or the requested authentication type is not 588 being used. The response may contain a zero or more 589 ``multicast-mirror'' attributes and zero or more ``multicast-referal'' 590 attributes. An empty response means the repository is not 591 multicasting the database requested and does not know of any other 592 repository which is doing so. 594 If an object intended to be multicast is too big to fit inside a 595 single packet, it may be necessary to send the object as a 596 multipart-compressed object (Section 6.4.5). 598 A multicast feed can be cancelled simply by leaving the multicast 599 group. 601 If listenning on a multicast group, loss is detected by the receipt of 602 sequences beyond the current sequence number. When loss is detected, 603 a unicast connection can be used to request the missing transaction 604 sequence. [@@ alt method to be provided by ISI?] 606 6.4.4 Transaction Sequence Format 608 A transaction sequence may contain one or more transactions. Whether 609 obtaining transactions through unicast or multicast, transactions are 610 encapsulated as transaction sequences. 612 A transaction sequence is delimited by a ``sequence-begin'' and 613 ``sequence-end'' meta-object. If the sequence is sent via multicast 614 and requires multiple packets, reliable, in-order delivery is not 615 assured as it is for TCP. To overcome this, each subsequent packets in 616 a transaction sequence not sent using TCP must begin with a 617 ``sequence-continue''. The complete transaction sequence should be 618 treated as an atomic operation. 620 The following attributes may be contained in a ``sequence-begin'' 621 meta-object. 623 sequence-begin This attribute is manditory and single. It contains 624 the database name and the next available sequence number. This 625 sequence number will be used for the first transaction in the 626 sequence if the sequence in not empty. 628 database-sequence This attribute is optional and multiple. It 629 contains the database name and sequence number of a database that 630 is needed for authorization of one or more transaction in the 631 sequence. 633 date-time-stamp See Section 6.6. 635 The ``sequence-continue'' and ``sequence-end'' meta-objects contain an 636 attribute by the same name. A ``sequence-continue'' attribute 637 contains the the database name and the next available sequence number 638 followed by a fragment number. The first fragment is numbered one 639 (the sequence-begin can be considered fragment zero). The fragment 640 number can be followed by the word ``append'' which means that the 641 current fragment should be appended to the last object in the prior 642 fragment. A ``sequence-end'' attribute contains the the database name 643 and the next available sequence number. The next available sequence 644 number must be followed by the number of fragments if any ``sequence- 645 continue'' fragments were sent. These meta-objects may also contain a ``date- 646 time-stamp'' attribute. 648 Transactions are encapsulated by embedding the initial transaction 649 submission intact including any authentication. 651 Transactions can also be recinded. The operation of recinding a 652 transaction is represented by a ``transaction-recind'' meta-object 653 which itself consumes one sequence number. The ``transaction-recind'' 654 meta-object contains one attribute by the same name. The value of the 655 attribute is the sequence number of the first transaction being 656 recinded and the sequence number following the last transaction 657 recinded. 659 6.4.5 Compressed and Multipart Objects 661 It may be necessary or advantageous to compress, ascii encode, and 662 sometimes split a message into multiple parts. To accomplish this, a 663 ``transfer encoding'' is used. The transfer encoding consists of one 664 or more ``transfer-encoding'' meta-objects which may contain the 665 following attribues: 667 transfer-encoding This attribute is manditory and single. It 668 contains only an identifier. 669 transfer-part This attribute is optional and single. It contains a 670 part number starting at one and the total number of parts. 672 transfer-method This attribute is manditory and single. It contains 673 one or more of the following keywords ``gzip'', ``uuencode'', 674 ``base50'', ``radix64''. 676 transfer-contents This attribute is manditory and single. The 677 contents being transferred is contained in this attribute. A 678 single leading space can be used for line continuation. 680 6.4.6 Cancelling Operations 682 A request can be made to cancel most operations. The most common 683 would be to cancel a ``query'' which is returning too much information 684 or cancel a long running operation like a ``unicast-mirror-request''. 686 A ``cancel-operation'' meta object contains only an attribute by the 687 same name. The attribute contains the operation type represented by 688 the key attribute name in the request without the trailing ``-begin''. 689 The remainder of the ``cancel-operation'' attribute contains the key 690 field of the request. 692 When an operation is cancelled a ``cancel-confirm'' meta-object is 693 returned. Any response in progress is ended by the ``cancel-confirm'' 694 and a ``-end'' meta-object should not be expected. The 695 ``cancel-confirm'' attribute contains the same operation type and key 696 field as the corresponding ``cancel-operation''. 698 6.5 Authenticating Operations 700 PGP normally encapsulates text by starting with a line containing 701 ``-----BEGIN PGP SIGNED MESSAGE-----'' and a blank line and then 702 ending with the signature block. The signature block consists of a 703 blank line, then a line with ``-----BEGIN PGP SIGNATURE-----'', then a 704 block containing the ASCII radix-64 signature and ending with a line 705 containing ``-----END PGP SIGNATURE-----''. This encapsulation can be 706 recognized as a meta-objects allowing pgp to be used in normal pipe 707 plumbing using the PGPPASSFD feature to provide a pass phrase. 709 Alternately, the the PGP delimiters can be replaced with meta-objects 710 and then restored to the format compatible with the PGP code. This is 711 preferable. The meta-objects ``signed-object-begin'' and 712 ``signed-object-end'' can be used. The attributes 713 ``signed-object-begin'' and ``signed-object-end'' contain only the 714 authentication method name. The interpretation of any additional 715 attributes depend on the authentication method. 717 Any objects can be signed, including large sequences of meta-objects 718 and objects such as transaction sequences. Objects may be signed by 719 more than one method. If more than one method is used to sign an 720 object, then either method can be used to authenticate the object, 721 ignore one of them. 723 Note that the RPSL objects themselves are not signed. What is signed 724 by the submitter is the transaction. When exchanging transactions 725 among registries, the objects that make up requests are signed by one 726 registry and the transaction sequences returned are signed by the 727 other registry. Within the transaction sequences there may be signed 728 transactions. There is additional meta-information within the 729 transaction sequences that falls outside of the submitter's signature. 731 Transactions must remain intact, including the signatures, even if an 732 authentication method provided by the submitter is not used by a 733 repository handling the message. It is also useful to retain the 734 transaction sequence signatures and add an addition signature when 735 encapsulating a received transaction sequence. 737 Normally repositories will sign transactions between repositories. 738 When unwrapping the authentication encapsulations, the identities of 739 the signatures must be retained to establish authorization. If at any 740 point the signature of a trusted repository is encountered, no further 741 authorization or authentication is needed and any further nested 742 ``signed-object-begin'' and ``signed-object-end'' can be ignored. 744 6.6 Attributes Common to Meta-Objects 746 A number of attributes are used by numerous meta-objects. They are 747 described here rather than repeating their descriptions elsewhere. 749 date-time-stamp This attribute is manditory and single except were it 750 is noted as being optional. The date and time are given in the 751 form ``YYYYMMDD HHMMSS'' with an optional numeric timezone 752 represented as ``[+-]H''. The upper case letters are digits 753 corresponding to the year, month, day of month, hour, minute, 754 second, and hours before or after UTC. 756 response-auth-type This attribute is optional and multiple. The 757 remainder of the line specifies an authentication type that would 758 be acceptable in the response. This is used to request a response 759 cryptographically signed by the repository. 760 commit-status This attribute is manditory and single. It contains 761 one of the keywords ``timeout'', ``error'', or ``commit''. The 762 ``error'' keyword must be followed by a numeric code and an 763 optional text string. 765 @@ list of error codes ... yech 767 A Technical Discussion 769 A.1 Server Processing 771 This document does not mandate any particular software design, 772 programming language choice, or underlying database or underlying op- 773 erating system. Examples are given solely for illustrative purposes. 775 A.1.1 getting connected 777 There are two primary methods of communicating with a repository 778 server. E-mail can be sent to the server. This method may be 779 depricated but at least needs to be supported during transition. The 780 second method is preferred, connect directly to a TCP socket. 781 Multicast is a third method, but this is limited to use in data 782 replication between repositories. 784 Traditionally the whois service is supported for simple queries. It 785 might be wise to retain the whois port connection solely for simple 786 queries and use a second port not in the reserved number space for all 787 other operations including queries except those queries using the 788 whois unstructured single line query format. 790 There are two styles of handling connection initiation is the 791 dedicated daemon, in the style of BSD sendmail, or launching through a 792 general purpose daemon such as BSD inetd. E-mail is normally handled 793 sequentially and can be handled by a front end program which will make 794 the connection to a socket in the process as acting as a mail delivery 795 agent. 797 A.1.2 rolling transaction logs forward and back 799 There is a need to be able to easily look back at previous states of 800 any database in order to repeat authorization checks at the time of a 801 transaction. This is difficult to do with the RIPE database 802 implementation, which uses a sequentially written ASCII file and a set 803 of Berkeley DB maintained index files for traversal. At the very 804 minimum, the way in which deletes or replacements are implemented 805 would need to be altered. 807 In order to easily support a view back at prior versions of objects, 808 the sequence number of the transaction at which each object was 809 entered would need to be kept with the object. A pointer would be 810 needed back to the previous state of the object. A deletion would 811 need to be implemented as a new object with a deleted attribute, 812 replacing the previous version of the object but retaining a pointer 813 back to it. 815 A separate transaction log needs to be maintained. Beyond some age, 816 the older versions of objects and the the older transaction log 817 entries can be removed although it is probably wise to archive them. 819 A.1.3 commiting or disposing of transactions 821 The ability to commit large transaction, or reject them as a whole 822 poses problems for simplistic database designs. This form of commit 823 operation can be supported quite easily using memory mapped files. 824 The changes can be made in virtual memory only and then either 825 committed or disposed of. 827 A.1.4 dealing with concurrency 829 Multiple connections may be active. In addition, a single connection 830 may have multiple outstanding operations. It makes sense to have a 831 single process or thread coordinate the responses for a given 832 connection and have multiple processes or threads each tending to a 833 single operation. The operations may complete in random order. 835 Locking on reads is not essential. Locking before write access is 836 essential. The simplest approach to locking is to lock at the 837 database granularity or at the database and object type granularity. 838 Finer locking granularity can also be implemented. Because there are 839 multiple databases, deadlock avoidance must be considered. The usual 840 deadlock avoidance mechanism is to acquire all necessary locks in a 841 single operation or acquire locks in a prescribed order. 843 A.2 Repository Mirroring for Redundancy 845 There are numerous reasons why the operator of a repository might 846 mirror their own repository. Possibly the most obvious are redundancy 847 and the relative ease of disaster recovery. Another reason might be 848 the widespread use of a small number of implementations (but more than 849 one) and the desire to insure that the major repository software 850 releases will accept a transaction before fully commiting to the 851 transaction. This may avoid the need to recind transactions in the 852 face of a newly discovered bug. 854 The operation of a repository mirror used for redundancy is quite 855 straightforward. The transactions of the primary repository host can 856 be immediately fed to the redundant repository host. For tighter 857 assurances that false positive confirmations will be sent, as a matter 858 of policy the primary repository host can require commit confirmation 859 before making a transaction sequence publicly available. 861 There are many ways in which the integrety of local data can be 862 assured regardless of a local crash in the midst of transaction disk 863 writes. For example, transactions can be implemented as memory mapped 864 file operations, with disk synchronization used as the local commit 865 mechanism, and disposal of memory copies of pages used to handle 866 commit failures. The old pages can be written to a separate file, the 867 new pages written into the database. The transaction can be logged 868 and old pages file can then be removed. In the event of a crash, the 869 existence of a old pages file and the lack of a record of the 870 transaction completing would trigger a transaction roll back by 871 writing the old pages back to the database file. 873 The primary repository host can still sustain severe damage such as a 874 disk crash. If the primary repository host becomes corrupted, the use 875 of a mirror repository host provides a backup and can provide a rapid 876 recovery from disaster by simply reversing roles. 878 If a mirror is set up using a different software implementation with 879 commit mirror confirmation required, any transaction which fails due a 880 software bug will be deferred indefinitely allowing other transactions 881 to proceed rather than halting the remote processing of all 882 transactions until the bug is fixed everywhere or the offending 883 transaction is recinded. 885 A.3 Trust Relationships 887 If all repositories trust each other then there is never a need to 888 repeat authorization checks. This enables a convenient interim step 889 for deployment prior to the completion of software supporting that 890 capability. The opposite case is where no repository trusts any other 891 repository. In this case, all repositories must roll forward 892 transactions gradually, checking the authorization of each remote 893 transaction. 895 It is likely that repositories will trust a subset of other 896 repositories. This trust can reduce the amount of processing a 897 repository required to maintain mirror images of the full set of data. 898 For example, a subset of repositories might be trustworthy in that 899 they take reasonable security measures, the organizations themselves 900 have the integrety not to alter data, and these repositories trust 901 only a limited set of similar repositories. If any one of these 902 repositories receives a transaction sequence and repeats the 903 authorization checks, other major repositories which trusts that 904 repository need not repeat the checks. In addition, trust need not be 905 mutual to reap some benefit in reduced processing. 907 As a transaction sequence is passed from repository to repository each 908 repository signs the transaction sequence before forwarding it. If a 909 receiving repository finds that any trusted repository has signed the 910 transaction sequence it can be considered authorized since the trusted 911 repository either trusted a preceeding repository or repeated the 912 authorization checks. 914 This reduction in processing made possible by redistributing the 915 transaction sequences at the application level favors flooding or 916 query mechanisms of distribution rather than IP multicast 917 redictribution. It might make sense to incorporate both application 918 leve flooding and multicast. A repository can redistribute to a 919 limited multicast group taking into account both network topology and 920 the trust relationships. 922 A.4 A Router as a Minimal Mirror 924 A router could serve as a minimal repository mirror. The following 925 simplifications can be made. 927 1. No support for repeating authorization checks or transaction 928 authentication checks need be coded in the router. 930 2. The router must be adjacent only to trusted mirrors, generally 931 operated by the same organization. 932 3. The router would only check the authentication of the adjacent 933 repository mirrors. 935 4. No support for transaction submission or query need be coded in the 936 router. No commit support is needed. 938 5. The router can dispose of any object types or attributes not needed 939 for configuration of route filters. 941 The need to update router configurations could be significantly 942 reduced if the router were capable of acting as a limited repository 943 mirror. 945 A significant amount of non-volitile storage would be needed. There 946 are currently an estimated 100 transactions per day. If storage were 947 flash memory with a limited number of writes, or if there were some 948 other reason to avoid writing to flash, the router could only update 949 the non-volitile copy every few days. A transaction sequence request 950 can be made to get an update in the event of a crash, returning only a 951 few hundred updates after losing a few days of deferred writes. The 952 routers can still take a frequent or continuous feed of transactions. 954 Alternately, router filters can be reconfigured periodically as they 955 are today. 957 A.5 Dealing with Errors 959 If verification of an authorization check fails, the entire sequence 960 must be rejected and no further advancement of the repository can 961 occur until the originating repository corrects the problem. If the 962 problem is due to a software bug, the offending transaction can be 963 removed manually once the problem is corrected. If a software bug 964 exists in the receiving software, then the transaction sequence is 965 stalled until the bug is corrected. It is better for software to 966 error on the side of denying a transaction than acceptance, since an 967 error on the side of acceptance will require recinding transactions 968 and rolling forward only those that were valid. 970 B Deployment Considerations 972 This section described deployment considerations. The intention is to 973 raise issues rather than to provide a deployment plan. 975 This document calls for a transaction exchange mechanism similar to 976 but not identical to the existing ``near real time mirroring'' sup- 977 ported by the code base widely used by the routing registries. As an 978 initial step, the transaction exchange can be implemented without the 979 commit protocol or the ability to recheck transaction authorization. 980 This is a fairly minimal step from the existing capabilities. 982 The transition can be staged as follows: 984 1. Modify the format of ``near real time mirroring'' transaction 985 exchange to conform to the specifications of this document. 986 2. Implement commit protocol and confirmation support. 988 3. Implement remote recheck of authorization. Prior to this step all 989 repositories must be trusted. 991 4. Allow further decentralization of the repositories. 993 Whether to use unicast or multicast as a means of distributing 994 transactions is somewhat orthogonal to this deployment. Currently 995 transactions are distributed on a query basis or a unicast connection 996 basis. Where many repositories receive the same transaction 997 information it may make sense to distribute transactions via 998 multicast. A query method will need to be supported for the purpose 999 of obtaining transaction sequences lost when multicasting and in the 1000 short term to accomodate discontinuity in the multicast topology or 1001 inadequate performance of deployed multicast service. 1003 Acknowledgements 1005 @@ Will fill in later. @@ 1007 References 1009 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, 1010 D. Meyer, M. Terpstra, and C. Villamizar. Routing policy specifi- 1011 cation language (rpsl). Technical Report RFC 2280, Internet Engi- 1012 neering Task Force, 1998. ftp://ds.internic.net/rfc/rfc2280.txt. 1013 [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, 1014 D. Karrenberg, M. Terpstra, and J. Yu. Representation of ip rout- 1015 ing policies in a routing registry 1016 (ripe-81++). Technical Report RFC 1786, Internet Engineering Task 1017 Force, 1995. ftp://ds.internic.net/rfc/rfc1786.txt. 1019 [3] David Meyer, C. Villamizar, Cengiz Alaettinoglu, S. Murphy, 1020 and Carol Orange. Routing policy system security. Internet Draft 1021 (Work in Progress) draft-ietf-rps-auth-01, Internet Engineering 1022 Task Force, 5 1998. ftp://ds.internic.net/internet-drafts/draft- 1023 ietf-rps-auth-01.txt. 1025 Security Considerations 1027 @@ later for this too. 1029 Author's Addresses 1031 Curtis Villamizar Cengiz Alaettinoglu 1032 ANS Communications ISI 1033 1035 Ramesh Govindan David M. Meyer 1036 ISI University of Oregon 1037