rfc2769.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                      C. Villamizar
Request for Comments: 2769                                 Avici Systems
Category: Standards Track                                C. Alaettinoglu
                                                             R. Govindan
                                                                     ISI
                                                                D. Meyer
                                                                   Cisco
                                                           February 2000


                   Routing Policy System Replication

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

Abstract

   The RIPE database specifications and RPSL define languages used as
   the basis for representing information in a routing policy system.  A
   repository for routing policy system information is known as a
   routing registry.  A routing registry provides a means of exchanging
   information needed to address many issues of importance to the
   operation of the Internet.  The implementation and deployment of a
   routing policy system must maintain some degree of integrity to be of
   any use.  The Routing Policy System Security RFC [3] addresses the
   need to assure integrity of the data by proposing an authentication
   and authorization model.  This document addresses the need to
   distribute data over multiple repositories and delegate authority for
   data subsets to other repositories without compromising the
   authorization model established in Routing Policy System Security
   RFC.







Villamizar, et al.          Standards Track                     [Page 1]

RFC 2769           Routing Policy System Replication       February 2000


Table of Contents

   1  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2  Data Representation  . . . . . . . . . . . . . . . . . . . . .   4
   3  Authentication and Authorization . . . . . . . . . . . . . . .   5
   4  Repository Hierarchy . . . . . . . . . . . . . . . . . . . . .   6
   5  Additions to RPSL  . . . . . . . . . . . . . . . . . . . . . .   6
      5.1  repository object . . . . . . . . . . . . . . . . . . . .   7
      5.2  delegated attribute . . . . . . . . . . . . . . . . . . .   9
      5.3  integrity attribute . . . . . . . . . . . . . . . . . . .  10
   6  Interactions with a Repository or Mirror . . . . . . . . . . .  11
      6.1  Initial Transaction Submission  . . . . . . . . . . . . .  12
      6.2  Redistribution of Transactions  . . . . . . . . . . . . .  12
      6.3  Transaction Commit and Confirmation . . . . . . . . . . .  12
   7  Data Format Summaries, Transaction Encapsulation and Processing 13
      7.1  Transaction Submit and Confirm  . . . . . . . . . . . . .  13
      7.2  Redistribution of Transactions  . . . . . . . . . . . . .  16
      7.3  Redistribution Protocol Description . . . . . . . . . . .  16
           7.3.1 Explicitly Requesting Transactions  . . . . . . . .  21
           7.3.2 Heartbeat Processing  . . . . . . . . . . . . . . .  22
      7.4  Transaction Commit  . . . . . . . . . . . . . . . . . . .  23
      7.5  Database Snapshot . . . . . . . . . . . . . . . . . . . .  24
      7.6  Authenticating Operations . . . . . . . . . . . . . . . .  25
   A  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
      A.1  Initial Object Submission and Redistribution  . . . . . .  27
      A.2  Transaction Redistribution Encoding . . . . . . . . . . .  29
      A.3  Transaction Protocol Encoding . . . . . . . . . . . . . .  31
      A.4  Transaction Redistribution  . . . . . . . . . . . . . . .  32
   B  Technical Discussion . . . . . . . . . . . . . . . . . . . . .  35
      B.1  Server Processing . . . . . . . . . . . . . . . . . . . .  35
           B.1.1 getting connected . . . . . . . . . . . . . . . . .  35
           B.1.2 rolling transaction logs forward and back . . . . .  35
           B.1.3 committing or disposing of transactions . . . . . .  36
           B.1.4 dealing with concurrency  . . . . . . . . . . . . .  36
      B.2  Repository Mirroring for Redundancy . . . . . . . . . . .  36
      B.3  Trust Relationships . . . . . . . . . . . . . . . . . . .  37
      B.4  A Router as a Minimal Mirror  . . . . . . . . . . . . . .  38
      B.5  Dealing with Errors . . . . . . . . . . . . . . . . . . .  38
   C  Deployment Considerations  . . . . . . . . . . . . . . . . . .  39
   D  Privacy of Contact Information . . . . . . . . . . . . . . . .  39
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  40
   Security Considerations . . . . . . . . . . . . . . . . . . . . .  41
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . . .  42







Villamizar, et al.          Standards Track                     [Page 2]

RFC 2769           Routing Policy System Replication       February 2000


1  Overview

   A routing registry must maintain some degree of integrity to be of
   any use.  The IRR is increasingly used for purposes that have a
   stronger requirement for data integrity and security.  There is also
   a desire to further decentralize the IRR. This document proposes a
   means of decentralizing the routing registry in a way that is
   consistent with the usage of the IRR and which avoids compromising
   data integrity and security even if the IRR is distributed among less
   trusted repositories.

   Two methods of authenticating the routing registry information have
   been proposed.

   authorization and authentication checks on transactions:  The
      integrity of the routing registry data is insured by repeating
      authorization checks as transactions are processed.  As
      transactions are flooded each remote registry has the option to
      repeat the authorization and authentication checks.  This scales
      with the total number of changes to the registry regardless of how
      many registries exist.  When querying, the integrity of the
      repository must be such that it can be trusted.  If an
      organization is unwilling to trust any of the available
      repositories or mirrors they have the option to run their own
      mirror and repeat authorization checks at that mirror site.
      Queries can then be directed to a mirror under their own
      administration which presumably can be trusted.

   signing routing registry objects:  An alternate which appears on the
      surface to be attractive is signing the objects themselves.
      Closer examination reveals that the approach of signing objects by
      itself is flawed and when used in addition to signing transactions
      and rechecking authorizations as changes are made adds nothing.
      In order for an insertion of critical objects such as inetnums and
      routes to be valid, authorization checks must be made which allow
      the insertion.  The objects on which those authorization checks
      are made may later change.  In order to later repeat the
      authorization checks the state of other objects, possibly in other
      repositories would have to be known.  If the repository were not
      trusted then the change history on the object would have to be
      traced back to the object's insertion.  If the repository were not
      trusted, the change history of any object that was depended upon
      for authorization would also have to be rechecked.  This trace
      back would have to go back to the epoch or at least to a point
      where only trusted objects were being relied upon for the
      authorizations.  If the depth of the search is at all limited,
      authorization could be falsified simply by exceeding the search
      depth with a chain of authorization references back to falsified



Villamizar, et al.          Standards Track                     [Page 3]

RFC 2769           Routing Policy System Replication       February 2000


      objects.  This would be grossly inefficient.  Simply verifying
      that an object is signed provides no assurance that addition of
      the object addition was properly authorized.

   A minor distinction is made between a repository and a mirror.  A
   repository has responsibility for the initial authorization and
   authentication checks for transactions related to its local objects
   which are then flooded to adjacent repositories.  A mirror receives
   flooded transactions from remote repositories but is not the
   authoritative source for any objects.  From a protocol standpoint,
   repositories and mirrors appear identical in the flooding topology.

   Either a repository or a mirror may recheck all or a subset of
   transactions that are flooded to it.  A repository or mirror may
   elect not to recheck authorization and authentication on transactions
   received from a trusted adjacency on the grounds that the adjacent
   repository is trusted and would not have flooded the information
   unless authorization and authentication checks had been made.

   If it can be arranged that all adjacencies are trusted for a given
   mirror, then there is no need to implement the code to check
   authorization and authentication.  There is only a need to be able to
   check the signatures on the flooded transactions of the adjacent
   repository.  This is an important special case because it could allow
   a router to act as a mirror.  Only changes to the registry database
   would be received through flooding, which is a very low volume.  Only
   the signature of the adjacent mirror or repository would have to be
   checked.

2  Data Representation

   RPSL provides a complete description of the contents of a routing
   repository [1].  Many RPSL data objects remain unchanged from the
   RIPE, and RPSL references the RIPE-181 specification as recorded in
   RFC-1786 [2].  RPSL provides external data representation.  Data may
   be stored differently internal to a routing registry.  The integrity
   of the distributed registry data requires the use of the
   authorization and authentication additions to RPSL described in [3].

   Some additions to RPSL are needed to locate all of the repositories
   after having located one of them and to make certain parameters
   selectable on a per repository basis readily available.  These
   additions are described in Section 5.

   Some form of encapsulation must be used to exchange data.  The de-
   facto encapsulation has been that which the RIPE tools accept, a
   plain text file or plain text in the body of an RFC-822 formatted
   mail message with information needed for authentication derived from



Villamizar, et al.          Standards Track                     [Page 4]

RFC 2769           Routing Policy System Replication       February 2000


   the mail headers.  Merit has slightly modified this using the PGP
   signed portion of a plain text file or PGP signed portion of the body
   of a mail message.

   The exchange that occurs during flooding differs from the initial
   submission.  In order to repeat the authorization checks the state of
   all repositories containing objects referenced by the authorization
   checks needs to be known.  To accomplish this a sequence number is
   associated with each transaction in a repository and the flooded
   transactions must contain the sequence number of each repository on
   which authorization of the transaction depends.

   In order to repeat authorization checks it must be possible to
   retrieve back revisions of objects.  How this is accomplished is a
   matter local to the implementation.  One method which is quite simple
   is to keep the traversal data structures to all current objects even
   if the state is deleted, keep the sequence number that the version of
   the object became effective and keep back links to prior versions of
   the objects.  Finding a prior version of an object involves looking
   back through the references until the sequence number of the version
   of the object is less than or equal to the sequence number being
   searched for.

   The existing very simple forms of encapsulation are adequate for the
   initial submission of a database transaction and should be retained
   as long as needed for backward compatibility.  A more robust
   encapsulation and submission protocol, with optional confirmation is
   defined in Section 6.1.  An encapsulation suitable for exchange of
   transaction between repositories is addressed in Section 6.  Query
   encapsulation and protocol is outside the scope of this document.

3  Authentication and Authorization

   Control must be exercised over who can make changes and what changes
   they can make.  The distinction of who vs what separates
   authentication from authorization.

   o  Authentication is the means to determine who is attempting to make
      a change.

   o  Authorization is the determination of whether a transaction
      passing a specific authentication check is allowed to perform a
      given operation.

   A submitted transaction contains a claimed identity.  Depending on
   the type of transaction, the authorization will depend on related
   objects.




Villamizar, et al.          Standards Track                     [Page 5]

RFC 2769           Routing Policy System Replication       February 2000


   The "mnt-by", "mnt-routes", or "mnt-lower" attributes in those
   related objects reference "maintainer" objects.  Those maintainer
   objects contain "auth" attributes.  The auth attributes contain an
   authorization method and data which generally contains the claimed
   identity and some form of public encryption key used to authenticate
   the claim.

   Authentication is done on transactions.  Authentication should also