rfc2725.txt

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

   Many RPSL objects do not have a natural hierarchy of their own but
   allow hierarchical names.  Some examples are the object types "as-
   set" and "route-set".  An as-set may have a name corresponding to no
   naming hierarchy such as "AS-Foo" or it may have a hierarchical name
   of the form "AS1:AS-Bar".

   When a hierarchical name is not used, authorization for objects such
   as "as-set" and "route-set" correspond to the rules for objects with
   no hierarchy described in Section 9.6.

   If hierarchical names are used, then the addition of an object must
   be authorized by the aut-num whose key is named by everything to the
   left of the rightmost colon in the name of the object being added.
   Authorization is determined by first using the mnt-lower maintainer
   reference, or if absent, using the mnt-by reference.

9.8  Query Processing

   A query may have to span multiple repositories.  All queries should
   be directed toward a local repository which may mirror the root
   repository and others.  Currently each IRR repository mirrors all
   other repositories.  In this way, the query may be answered by the
   local repository but draw data from others.



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


   The mechanism below when applied to multiple repositories assumes the
   existence of an attribute for traversal of the repositories.  The
   definition of this attribute is considered a distributed registry
   issue and is out of scope of this document.

   For object types that have a natural hierarchy, such as aut-num,
   inet-num, and route, the search begins at the root database and
   follows the hierarchy.  For objects types that have no natural
   hierarchy, such as maintainer, person, and role objects, the search
   is confined to a default database unless a database is specified.
   The default database is the same database as an object from which a
   reference is made if the query is launched through the need to follow
   a reference. Otherwise the default is generally the local database or
   a default set by the repository.  The default can be specified in the
   query itself as described in Section 9.7.

   In the absense of attributes to traverse multiple registries a search
   of all repositories is needed.  With such attributes the search would
   proceed as follows.  In searching for an AS, the delegation attribute
   in AS blocks can be consulted, moving the search to data from other
   repositories.  Eventually the AS is either found or the search fails.
   The search for an inetnum is similar.  Less specific inetnums may
   refer the search to other databases.  Eventually the most specific
   inetnum is found and its status (assigned or not assigned) can be
   determined.  The definition of attributes for traversal of
   repositories is considered a distrbiuted registry issue and is not
   within the scope of this document.

   The search for a route in the presence of attributes for the
   traversal of multiple registries is similar except the search may
   branch to more than one repository.  The most specific route in one
   repository may be more specific than the most specific in another.
   In looking for a route object it makes sense to return the most
   specific route that is not more specific than the query requests
   regardless of which repository that route is in rather than return
   one route from each repository that contains a less specific overlap.

9.9  Adding to the Database

   The mechanism below when applied to multiple repositories assumes the
   existence of an attribute for traversal of the repositories.  The
   definition of this attribute is considered a distributed registry
   issue and is out of scope of this document.

   The root repository must be initially populated at some epoch with a
   few entries.  An initial maintainer is needed to add more
   maintainers.  The referral-by attribute can be set to refer to itself
   in this special case (Section 10 describes the referral-by).  When



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


   adding an inetnum or a route object an existing exact match or a less
   specific overlap must exist.  A route object may be added based on an
   exact match or a less specific inetnum.  The root repository must be
   initially populated with the allocation of an inetnum covering the
   prefix 0/0, indicating that some address allocation authority exists.
   Similarly an initial as-block is needed covering the full AS number
   range.

   When adding an object with no natural hierarchy, the search for an
   existing object follows the procedure outlined in Section 9.8.

   When adding an aut-num (an AS), the same procedure used in a query is
   used to determine the appropriate repository for the addition and to
   determine which maintainer applies.  The sequence of AS-block objects
   and repository delegations is followed.  If the aut-num does not
   exist, then the submission must match the authentication specified in
   the maintainer for the most specific AS-block in order to be added.

   The procedure for adding an inetnum is similar.  The sequence of
   inet-num blocks is followed until the most specific is found.  The
   submission must match the authentication specified in the maintainer
   for the most specific inetnum overlapping the addition.

   Adding a route object is somewhat more complicated.  The route object
   submission must satisfy two authentication criteria.  It must match
   the authentication specified in the aut-num and the authentication
   specified in either a route object or if no applicable route object
   is found, then an inetnum.

   An addition is submitted with an AS number and prefix as its key.  If
   the object already exists, then the submission is treated as a modify
   (see Section 9.10).  If the aut-num does not exist on a route add,
   then the addition is rejected (see Section C for further discussion
   of tradeoffs).  If the aut-num exists then the submission is checked
   against the applicable maintainer.  A search is then done for the
   prefix first looking for an exact match.  If the search for an exact
   match fails, a search is made for the longest prefix match that is
   less specific than the prefix specified.  If this search succeeds it
   will return one or more route objects.  The submission must match an
   applicable maintainer in at least one of these route objects for the
   addition to succeed.  If the search for a route object fails, then a
   search is performed for an inetnum that exactly matches the prefix or
   for the most specific inetnum that is less specific than the route
   object submission.  The search for an inetnum should never fail but
   it may return an unallocated or reserved range.  The inetnum status
   must be "allocated" and the submission must match the maintainer.





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


   Having found the AS and either a route object or inetnum, the
   authorization is taken from these two objects.  The applicable
   maintainer object is any referenced by the mnt-routes attributes.  If
   one or more mnt-routes attributes are present in an object, the mnt-
   by attributes are not considered.  In the absence of a mnt-routes
   attribute in a given object, the mnt-by attributes are used for that
   object.  The authentication must match one of the authorizations in
   each of the two objects.

   If the addition of a route object or inetnum contains a reclaim
   attribute, then any more specific objects of the same type must be
   examined.  The reclaim attribute can only be added if there are no
   more specific overlaps or if the authentication on the addition is
   present in the authorization of a less specific object that already
   has a reclaim attribute covering the prefix range, or if the
   authentication on the addition is authorized for the modification of
   all existing more specific prefixes covered by the addition.

9.10  Modifying or Deleting Database Objects

   When modifying or deleting any existing object a search for the
   object is performed as described in Section 9.8.  If the submission
   matches an applicable maintainer for the object, then the operation
   can proceed.  An applicable maintainer for a modification is any
   maintainer referenced by the mnt-by attribute in the object.  For
   route and inet-num objects an applicable maintainer may be listed in
   a less specific object with a reclaim attribute.

   If the submission is for a route object, a search is done for all
   less specific route objects and inetnums.  If the submission is for
   an inetnum, a search is done for all less specific inetnums.  If the
   submission fails the authorization in the object itself but matches
   the reclaim attribute in any of the less specific objects, then the
   operation can proceed.  Section C contains discussion of the
   rationale behind the use of the reclaim attribute.

   A modification to an inetnum object that adds a reclaim attribute or
   removes a no-reclaim attribute must be checked against all existing
   inetnums that are more specific.  The same check of the reclaim
   attribute that is made during addition must be made when a reclaim
   attribute is added by a modification (see Section 9.9).

   A deletion is considered a special case of the modify operation.  The
   deleted object may remain in the database with a "deleted" attribute
   in which case the mnt-by can still be consulted to remove the
   "deleted" attribute.





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


10  Data Format Summaries

   RIPE-181 [2] and RPSL [1] data is represented externally as ASCII
   text.  Objects consist of a set of attributes.  Attributes are name
   value pairs.  A single attribute is represented as a single line with
   the name followed by a colon followed by whitespace characters
   (space, tab, or line continuation) and followed by the value.  Within
   a value all whitespace is equivalent to a single space.  Line
   continuation is supported by a backslash at the end of a line or the
   following line beginning with whitespace.  When transferred,
   externally attributes are generally broken into shorter lines using
   line continuation though this is not a requirement.  An object is
   externally represented as a series of attributes.  Objects are
   separated by blank lines.

   There are about 80 attribute types in the current RIPE schema and
   about 15 object types.  Some of the attributes are mandatory in
   certain objects.  Some attributes may appear multiple times.  One or
   more attributes may form a key.  Some attributes or sets of
   attributes may be required to be unique across all repositories.
   Some of the attributes may reference a key field in an object type
   and may be required to be a valid reference.  Some attributes may be
   used in inverse lookups.

   A review of the entire RIPE or RPSL schema would be too lengthy to
   include here.  Only the differences in the schema are described.

10.1  Changes to the RIPE/RPSL Schema

   One new object type and several attributes are added to the RIPE/RPSL
   schema.  There are significant changes to the rules which determine
   if the addition of an object is authorized.

   The new object type is listed below.  The first attribute listed is
   the key attribute and also serves as the name of the object type.

   as-block        key  mandatory  single    unique
   descr                optional   multiple
   remarks              optional   multiple
   admin-c              mandatory  multiple
   tech-c               mandatory  multiple
   notify               optional   multiple
   mnt-by               mandatory  multiple
   changed              mandatory  multiple
   source               mandatory  single






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


   In the above object type only the key attribute "as-block" is new:

   as-block  This attribute provides the AS number range for an "as-
      block" object.  The format is two AS numbers including the sub-
      string "AS" separated by a "-" delimiter and optional whitespace
      before and after the delimiter.

   In order to support stronger authentication, the following keywords
   are added to the "auth" attribute:

   pgp-from  The remainder of the attribute gives the string identifying
      a PGP identity whose public key is held in an external keyring.
      The use of this method is deprecated in favor of the "pgpkey"
      method.

   pgpkey  See [18].

   In order to disable authentication and give permission to anyone, the
   authentication method "none" is added.  It has no arguments.

   An additional change is the "auth" attribute is allowed to exist in a
   "person" or "role" object.  The "auth" method "role" or "person" can
   be used to refer to a role or person object and take the "auth"
   fields from those objects.  Care must be taken in implementations to
   detect circular references and terminate expansion or the references
   already visited.

   A few attributes are added to the schema.  These are:

   mnt-routes  The mnt-routes attribute may appear in an aut-num, inet-
      num, or route object.  This attribute references a maintainer
      object which is used in determining authorization for the addition
      of route objects.  After the reference to the maintainer, an
      optional list of prefix ranges (as defined in RPSL) inside of