rfc2725.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

5  Organization of this Document

   Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this
   document.  Goals are described in Section 6.  Section 7 through
   Section 9 provide descriptions of the changes and discussion.
   Section 10 provides a concise summary of data formats and semantics.
   Appendix C through Appendix E provide additional technical
   discussion, examples, and deployment considerations.

      Goals and Requirements Section 6 provides a more detailed
      description of the issues and identifies specific problems that
      need to be solved, some of which require a degree of cooperation
      in the Internet community.

      Data Representation Section 7 provides some characteristics of
      RPSL and formats for external representations of information.

      Authentication Model Section 8 describes current practice,
      proposes additional authentication methods, and describes the
      extension mechanism if additional methods are needed in the
      future.

      Authorization Model Section 9 describes the means of determining
      whether a transaction contains the authorization needed to add,
      modify, or delete specific data objects, based on stated
      authentication requirements in related data objects.

      Data Format Summaries Section 10 provides a concise reference to
      the data formats and steps in transaction processing.

      Technical Discussion Section C contains some discussion of
      technical tradeoffs.

      Common Operational Cases Section D provides some examples drawn
      from past operational experience with the IRR.

      Deployment Considerations Section E describes some deployment
      issues and discusses possible means of resolution.

6  Goals and Requirements

   The Internet is an open network.  This openness and the large scale
   of the Internet can present operational problems.  Technical
   weaknesses that allow misconfiguration or errant operation in part of



Villamizar, et al.          Standards Track                     [Page 6]

RFC 2725             Routing Policy System Security        December 1999


   the network to propagate globally or which provide potentials for
   simple denial of service attacks should be eliminated to the extent
   that it is practical.  The integrity of routing information is
   critical in assuring that traffic goes where it is supposed to.

   An accidental misconfiguration can direct traffic toward routers that
   cannot reach a destination for which they are advertising
   reachability.  This is commonly caused by misconfigured static routes
   though there are numerous other potential causes.  Static routes are
   often used to provide constant apparent reachability to single homed
   destinations.  Some of the largest ISPs literally have thousands of
   static routes in their networks.  These are often entered manually by
   operators.  Mistyping can divert traffic from a completely unrelated
   destination to a router with no actual reachability to the advertised
   destination.  This can happen and does happen somewhat regularly.  In
   addition, implementation bugs or severe misconfigurations that result
   in the loss of BGP AS path information or alteration of prefix length
   can result in the advertisement of large sets of routes.  Though
   considerably more rare, on a few occasions where this has occurred
   the results were catastrophic.

   Where there is the potential for an accidental misconfiguration in a
   remote part of the Internet affecting the global Internet there is
   also the potential for malice.  For example, it has been demonstrated
   by accident that multiple hour outages at a major institution can be
   caused by a laptop and a dial account if proper precautions are not
   taken.  The dial account need not be with the same provider used by
   the major institution.

   The potential for error is increased by the CIDR preference for more
   specific routes [8].  If an institution advertises a single route of
   a given length and a distant router advertises a more specific route
   covering critical hosts, the more specific route, if accepted at all,
   is preferred regardless of administrative weighting or any routing
   protocol attributes.

   There is a need to provide some form of checks on whether a route
   advertisement is valid.  Today checks are typically made against the
   border AS advertising the route.  This prevents accepting routes from
   the set of border AS that could not legitimately advertise the route.
   Theses checks rely on the use of information registered in the IRR to
   generate lists of prefixes that could be advertised by a specific
   border AS. Checks can also be made against the origin AS. If policy
   information were sufficiently populated, checks could be made against
   the entire AS path, but this is not yet feasible.






Villamizar, et al.          Standards Track                     [Page 7]

RFC 2725             Routing Policy System Security        December 1999


   The use of a routing registry can also make it more difficult for
   prefixes to be used without authorization such as unallocated
   prefixes or prefixes allocated to another party.

   In summary, some of the problems being addressed are:

   o  Localizing the impact of accidental misconfiguration made by
      Internet Providers to that provider's networks only.

   o  Eliminating the potential for an Internet provider's customer to
      use malicious misconfiguration of routing as a denial of service
      attack if the provider route filters their customers.  Localizing
      the denial of service to that Internet provider only if the
      immediate Internet service provider does not route filter their
      customers but other providers route filter the route exchange at
      the interprovider peering.

   o  Eliminating the unauthorized use of address space.

   If the data within a routing registry is critical, then the ability
   to change the data must be controlled.  Centralized authorities can
   provide control but centralization can lead to scaling problems (and
   is politically distasteful).

   Address allocation and name allocation is already delegated.  Since
   delegation can be to outside registries it is at least somewhat
   distributed [11].  Autonomous System (AS) numbers are allocated by
   the same authorities.  It makes sense to delegate the routing number
   space in a manner similar to the address allocation and AS number
   allocation.  The need for this delegation of authority to numerous
   registries increases the difficulty of maintaining the integrity of
   the body of information as a whole.

   As a first step, the database can be somewhat centrally administered
   with authority granted to many parties to change the information.
   This is the case with the current IRR. There are a very small number
   of well trusted repositories and a very large number of parties
   authorized to make changes.  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.




Villamizar, et al.          Standards Track                     [Page 8]

RFC 2725             Routing Policy System Security        December 1999


   Different portions of the database will require different methods of
   authentication.  Some applications will require authentication based
   on strong encryption.  In other cases software supporting strong
   encryption may not be necessary or may not be legally available.  For
   this reason multiple authentication methods must be supported,
   selected on a per object basis through the specification of
   authentication methods in the maintainer object "auth" attribute.
   The authentication methods may range from very weak data integrity
   checks to cryptographicly strong signatures.  The authorization model
   must sure that the use of weak integrity checks in parts of the
   database does not compromise the overall integrity of the database.

   Additional requirements are placed on the authorization model if the
   database is widely distributed with delegations made to parties that
   may not be trustworthy or whose security practices may be lacking.
   This problem must be addressed in the authorization model in order to
   enable later evolution to a more distributed routing registry.

   Autonomous system numbers can be delegated in blocks and subdelegated
   as needed and then individual AS numbers assigned.  Address
   allocation is a simple numeric hierarchy.  Route allocation is
   somewhat more complicated.  The key attributes in a route object (key
   with regard to making it unique) contain both an address prefix and
   an AS number, known as the origin AS. The addition of a route object
   must be validated against the authorization criteria for both the AS
   and the address prefix.  Route objects may exist for the same prefix
   with multiple origin AS values due to a common multihoming practice
   that does not require a unique origin AS. There is often no
   correlation between the origin AS of a prefix and the origin AS of
   overlapping more specific prefixes.

   There are numerous operational cases that must be accommodated.  Some
   of the more common are listed below.  These are explored in greater
   detail in Appendix D with discussion of technical tradeoffs in
   Appendix C.

   o  simple hierarchical address allocation and route allocation

   o  aggregation and multihomed more specific routes

   o  provider independent addresses and multiple origin AS

   o  changing Internet service providers

   o  renumbering grace periods






Villamizar, et al.          Standards Track                     [Page 9]

RFC 2725             Routing Policy System Security        December 1999


   The authorization model must accommodate a variety of policies
   regarding the allocation of address space and cannot mandate the use
   of any one model.  There is no standardization of address allocation
   policies though guidelines do exist [11, 16].  Whether authorization
   allows the recovery of address space must be selectable on a per
   object basis and may differ in parts of the database.  This issue is
   discussed further in Appendix C.

7  Data Representation

   RPSL provides a complete description of the contents of a routing
   repository [1].  Many RPSL data objects remain unchanged from the
   RIPE specifications 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.

   Some database object types or database attributes must be added to
   RPSL to record the delegation of authority and to improve the
   authentication and authorization mechanisms.  These additions are
   very few and are described in Section 8 and Section 9.

   Some form of encapsulation must be used to exchange data.  The
   defacto encapsulation has been the one 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
   the mail headers or the body of the message.  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.  These very simple
   forms of encapsulation are suitable for the initial submission of a
   database transaction.

   The encapsulation of registry transaction submissions, registry
   queries and registry responses and exchanges between registries is
   outside the scope of this document.  The encapsulation of registry
   transaction submissions and exchanges between registries is outside
   the scope of this document.

8  Authentication Model

   The maintainer objects serve as a container to hold authentication
   filters.  A reference to a maintainer within another object defines
   authorization to perform operations on the object or on a set of
   related objects.  The maintainer is typically referenced by name in
   mnt-by attributes of objects.  Further details on the use of
   maintainers are provided in Section 9.1.





Villamizar, et al.          Standards Track                    [Page 10]

RFC 2725             Routing Policy System Security        December 1999


   The maintainer contains one or more "auth" attributes.  Each "auth"
   attribute begins with a keyword identifying the authentication method
   followed by the authentication information needed to enforce that
   method.  The PGPKEY method is slightly syntactically different in
   that the method PGPKEY is a substring.

   Authentication methods currently supported include the following.
   Note that pgp-from is being replaced by the pgpkey (see Section 10
   and [18]).

   mail-from  This is a very weak authentication check and is
      discouraged.  The authentication information is a regular
      expression over ASCII characters.  The maintainer is authenticated
      if the from or reply-to fields in RFC-822 mail headers are matched