rfc2725.txt

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

      by this regular expression.  Since mail forgery is quite easy,
      this is a very weak form of authentication.

   crypt-pw  This is another weak form of authentication.  The
      authentication information is a fixed encrypted password in UNIX
      crypt format.  The maintainer is authenticated if the transaction
      contains the clear text password of the maintainer.  Since the
      password is in clear text in transactions, it can be captured by
      snooping.  Since the encrypted form of the password is exposed, it
      is subject to password guessing attacks.

   pgp-from  This format is being replaced by the "pgpkey" so that the
      public key certificate will be available to remote repositories.
      This is Merit's PGP extension.  The authentication information is
      a signature identity pointing to an external public key ring.  The
      maintainer is authenticated if the transaction (currently PGP
      signed portion of a mail message) is signed by the corresponding
      private key.

   pgpkey  This keyword takes the form "PGPKEY-hhhhhhhh", where
      "hhhhhhhh" is the hex representation of the four byte id of the
      PGP public key used for authentication.  The public key
      certificate is stored in a separate object as described in [18].

   Repositories may elect to disallow the addition of "auth" attributes
   specifying weaker forms of authentication and/or disallow their use
   in local transaction submissions.  Repositories are encouraged to
   disallow the addition of "auth" attributes with the deprecated "pgp-
   from" method.

   Any digital signature technique can in principle be used for
   authentication.  Transactions should be signed using multiple digital
   signature techniques to allow repositories or mirrors that only use a




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


   subset of the techniques to verify at least one of the signatures.
   The selection of digital signature techniques is not within the scope
   of this document.

9  Authorization Model

   The authorization model must accommodate the requirements outlined in
   Section 6.  A key feature of the authorization model is the
   recognition that authorization for the addition of certain types of
   data objects must be derived from related data objects.

   With multiple repositories, objects not found in RPSL are needed to
   control AS delegations and new attributes are needed in existing
   objects to control subdelegation.  The definition of RPSL objects
   used to implement a distrubuted routing registry system is not within
   the scope of this document.

9.1  Maintainer Objects

   The maintainer objects serve as a container to hold authentication
   filters.  The authentication methods are described in Section 8.  The
   maintainer can be referenced by name in other objects, most notably
   in the mnt-by attributes of those objects.

   Maintainers themselves contain mnt-by attributes.  In some cases the
   mnt-by in a maintainer will reference the maintainer itself.  In this
   case, authorization to modify the maintainer is provided to a
   (usually very limited) set of identities.  A good practice is to
   create a maintainer containing a long list of identities authorized
   to make specific types of changes but have the maintainer's mnt-by
   attribute reference a far more restrictive maintainer more tightly
   controlling changes to the maintainer object itself.

   The mnt-by attribute is mandatory in all objects.  Some data already
   exists without mnt-by attributes.  A missing mnt-by attribute is
   interpreted as the absence of any control over changes.  This is
   highly inadvisable and most repositories will no longer allow this.

   An additional maintainer reference can occur through a new attribute,
   "mnt-routes", and is used in aut-num, inetnum and route objects.  The
   "mnt-routes" attribute is an extension to RPSL and is described in
   detail in Section 10.

   A mnt-routes attribute in an aut-num object allows addition of route
   objects with that AS number as the origin to the maintainers listed.
   A mnt-routes attribute in an inetnum object allows addition of route
   objects with exact matching or more specific prefixes.  A mnt-routes
   attribute in a route object allows addition of route objects with



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


   exact matching or more specific prefixes.  A mnt-routes attribute
   does not allow changes to the aut-num, inetnum, or route object where
   it appears.  A mnt-routes may optionally be constrained to only apply
   to a subset of more specific routes.

   Where "mnt-routes" or "mnt-lower" are applicable, any maintainer
   referenced in the "mnt-by" still apply.  The set of applicable
   maintainers for whatever check is being made is the union of the
   "mnt-routes" or "mnt-lower" and the "mnt-by".  For example, when
   authorizing a route object software would look at "mnt-routes", if it
   does not exist, look at "mnt-lower", if that does not exist look at
   "mnt-by".

9.2  as-block and aut-num objects

   An "as-block" object is needed to delegate a range of AS numbers to a
   given repository.  This is needed for authorization and it is needed
   to avoid having to make an exhaustive search of all repositories to
   find a specific AS. This search would not be an issue now but would
   be if a more distributed routing repository is used.  Distributed
   registry issues are not within the scope of this document.

   The "as-block" object also makes it possible to separate AS number
   allocation from registration of AS routing policy.

      as-block:        AS1321 - AS1335

   The "aut-num" describes the routing policy for an AS and is critical
   for router configuration of that AS and for analysis performed by
   another AS. For the purpose of this document it is sufficient to
   consider the aut-num solely as a place holder identifying the
   existence of an AS and providing a means to associate authorization
   with that AS when adding "route" objects.

   The "as-block" object is proposed here solely as a means of recording
   the delegation of blocks of AS numbers to alternate registries and in
   doing so providing a means to direct queries and a means to support
   hierarchical authorization across multiple repositories.

9.3  inetnum objects

   The "inetnum" exists to support address allocation.  For external
   number registries, such as those using "[r]whoisd[++]" the "inet-num"
   can serve as a secondary record that is added when an address
   allocation is made in the authoritative database.  Such records could
   be added by a address registry such as ARIN as a courtesy to the
   corresponding routing registry.




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


      inetnum:        193.0.0.0 - 193.0.0.255
      source:         IANA

9.4  route objects

   Currently there are a quite few route objects in more than one
   registry.  Quite a few are registered with an origin AS for which
   they have never been announced.  There is a legitimate reason to be
   in more than one origin AS.

   The "route" object is used to record routes which may appear in the
   global routing table.  Explicit support for aggregation is provided.
   Route objects exist both for the configuration of routing information
   filters used to isolate incidents of erroneous route announcements
   (Section 6) and to support network problem diagnosis.

9.5  reclaim and no-reclaim attributes

   A reclaim attribute is needed in as-block, inetnum and route objects.
   The reclaim attribute allows a control to be retained over more
   specific AS, IP address or route space by allowing modify and delete
   privileges regardless of the mnt-by in the object itself.

   The reclaim attribute provides the means to enforce address lending.
   It allows cleanup in cases where entities cease to exist or as a last
   presort means to correct errors such as parties locking themselves
   out of access to their own objects.  To specify all more specific
   objects the reclaim attribute value should be "ALL". To allow finer
   control a set of prefixes can be specified.

   A no-reclaim attribute can be used to provide explicit exceptions.  A
   reclaim attribute can only be added to an existing object if the
   addition of the reclaim attribute does not remove autonomy of
   existing more specific objects that are covered by the new reclaim
   attribute.

   1. A reclaim attribute can be added to an existing object if there
      are no existing exact matches or more specific objects overlapped
      by the new reclaim attribute, or

   2. if the submitter is listed in the maintainer pointed to by the
      mnt-by of the objects which are overlapped, or

   3. if any overlapped object is listed in a no-reclaim attribute in
      the object where the reclaim is being added.






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


   Similarly, a submitter may delete a no-reclaim attribute from an
   object only when that submitter is the only maintainer listed in the
   mnt-by attributes of any overlapped objects.  If the submitter is not
   listed in any of the maintainers pointed to by the mnt-by attributes
   for one or more overlapped object, then the submitter is not
   permitted to delete the no-reclaim attribute.

   If neither a reclaim or no-reclaim attribute is present, then more
   specific objects of a given object cannot be modified by the
   maintainer of the less specified object unless the maintainer is also
   listed as a maintainer in the more specific object.  However, the
   addition of a new route or inetnum object must pass authentication of
   the largest less specific prefix as part of the authentication check
   described in Section 9.9.

   See Section 10 for a full description of the reclaim and no-reclaim
   attributes.

9.6  Other Objects

   Many of the RPSL ancillary objects have no natural hierarchy the way
   AS numbers, Internet addresses and routes do have a numeric
   hierarchy.  Some examples are "maintainers", "people" and "role"
   objects.  For these objects, lack of any hierarchy leads to two
   problems.

   1. There is no hierarchy that can be exploited to direct queries to
      alternate registries.  At some point the query strategy of
      searching all known registries becomes impractical.

   2. There is no hierarchy on which authorizations of additions can be
      based.

   The first problem can be addressed by considering the name space for
   each of the ancillary objects to be unique only within the local
   database and to use explicit references to an external repository
   where needed.  To specify an external repository reference, the
   object key is preceded by the name of the repository and the
   delimiter "::".  For example a NIC handle may take the form
   "RIPE::CO19".  Currently there is a desire to keep NIC handles unique
   so the naming convention of appending a dash and the repository name
   is used.  Prepending the repository name provides the unique name
   space since an object in the RIPE database referencing "CO19" would
   be interpreted as "RIPE::CO19" by default, but it would still be
   possible to query or reference "IANA::CO19".  There is no possibility
   of accidentally forgetting to adhere to the conventions when making
   an addition and the existing objects are accommodated, including
   cases where name conflicts have already occurred.



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


   The second problem can be partially addressed by using a referral
   system for the addition of maintainers and requiring that any other
   object be submitted by a registered maintainer or by IANA.  The
   referral system would allow any existing maintainer to add another
   maintainer.  This can be used in parallel with the addition of other
   object types to support the maintenance of those objects.  For
   example, when adding a subdomain to the "domain" hierarchy (in the
   RIPE repository where domains are also handled), even when adding a
   new domain to a relatively flat domain such as "com", there is
   already a maintainer for the existing domain.  The existing
   maintainer can add the maintainer that will be needed for the new
   domain in addition to adding the new domain and giving the new
   maintainer the right to modify it.

   An organization gaining a presence on the Internet for the first time
   would be given a maintainer.  This maintainer may list a small number
   of very trusted employees that are authorized to modify the
   maintainer itself.  The organization itself can then add another
   maintainer listing a larger set of employees but listing the more
   restrictive maintainer in the mnt-by attributes of the maintainers
   themselves.  The organization can then add people and role objects as
   needed and any other objects as needed and as authorization permits.

9.7  Objects with AS Hierarchical Names