rfc2154.txt

RFC 的详细文档！

   use in retrieving the PKLSA. Identification information in the
   certified data (TE Id, Rtr Key Id) can be used to uniquely identify
   the current router key (section 7.2).

   To assist in parsing the message, the router signature length and the
   certification length fields are at the end of the LSA, following the
   signature.  The message must be signed and verified with these fields
   immediately appended to the LSA data.  The router signature of the
   PKLSA is verified in the same manner as other signed LSAs.  In
   addition, the certification must be verified using the referenced TE
   public key.  If either verification fails, for any reason, the PKLSA
   is discarded.

   A successfully verified PKLSA is stored for use in verifying signed
   LSAs from the advertising router. For every router that this router
   is in contact with, there may be one PKLSA stored at any given time.
   Each PKLSA is uniquely identified by the values (TE Id, Rtr Key Id)
   in the certified data (format in 7.2).  When a PKLSA arrives for a
   given router, and there is already a PKLSA stored for that router,
   the PKLSA with the most recent "Create Time" is the one kept.

   Whenever groups of LSAs are sent by a router (as when synchronizing
   databases or sending updates), the PKLSAs must be sent/requested
   before other LSAs to minimize the time spent processing LSAs that
   arrive prior to their associated keys.  The PKLSA is sent at
   intervals like all other LSAs, and it is sent immediately if a router
   obtains a new key to distribute. A PKLSA is sent via OSPF flooding
   within an OSPF area.  PKLSAs are not flooded outside an area with the
   exception of an Autonomous System Border Router's PKLSAs which must
   be flooded wherever AS external LSAs are flooded.  The decision to
   flood or not flood can be implemented by checking the router role
   (Rtr, ABR, ASBR, ABR-ASBR) stored in the certified part of the PKLSA.

   A router may flush its keys from routing tables by flooding a PKLSA
   for that key with age=MaxAge.  This is called premature aging of the
   PKLSA.  A key can also be removed from routing tables (superseded) by
   a PKLSA from the same router, containing a valid certificate for a
   new key with a more recent Create Time.  If a key is superseded by a
   more recent key it is not necessary to flush the old key with a
   "MaxAge" PKLSA.

   When a new key is received, the LSAs stored in the LSDB that are
   signed with the old key must be replaced within MAX_TRANSIT_DELAY.
   if the sending router is working properly.  This is because a router
   distributing a new key sends all of its self-originated LSAs signed
   with the new key immediately after sending the new PKLSA.  (See
   section 4.4 on Router Key Replacement).  To ensure that data signed
   with an old (possibly subverted) key does not persist in the LSDB in



Murphy, et. al.               Experimental                      [Page 6]

RFC 2154              OSPF with Digital Signatures             June 1997


   error, all LSAs signed with a flushed or superseded key are aged to
   within MAX_TRANSIT_DELAY of MaxAge.  This should allow time for the
   new LSAs signed with the new key to arrive.  If new LSAs do not
   arrive, or if the key has been flushed and not replaced, then the old
   LSA data will disappear from the LSDB in a timely fashion.

   Link State Acknowledgements must be sent for PKLSAs that are
   discarded due to verification failures or because the PKLSA was less
   recent than the one already stored.

3.3.  MaxAge Processing

   The age field in the OSPF LSA header is used to keep track of how
   long a given LSA has been in the system.  When the age field reaches
   MaxAge, a router stops using the LSA for routing, and it floods the
   MaxAge LSA to make sure that all routers stop using this LSA.  In the
   normal course of the OSPF protocol, an LSA is always replaced by an
   updated version before the age reaches MaxAge, unless the advertising
   router fails, or changes in the AS have made the routing information
   in the LSA inaccurate.  An LSA with age=MaxAge is either:


   (1) being intentionally flushed from the AS by the advertising router
       because the information in it is no longer accurate, or

   (2) an orphan LSA that has aged to MaxAge because its originating
       router has not refreshed it at the normal refresh intervals.

   The age field cannot generally be included in the signature, because
   it must be updated by routers other than the originating router.  For
   the same reason, the age field is not included in the checksum
   computation.  The age field must be protected, because if a faulty
   router started to age out other router's LSAs, it would effectively
   deny service to those other routers.

   To protect the age field, the signature must include the age field if
   and only if the originating router creates an LSA with age=MaxAge.
   Verification of the signature on a signed LSA must include the age
   field if and only if the age field value is MaxAge.  In this manner,
   the originating router can flush an LSA, but other routers cannot.
   An LSA that ages to MaxAge in the LSDB of any router is still
   discarded by that router, but it is not synchronously flushed from
   the AS.








Murphy, et. al.               Experimental                      [Page 7]

RFC 2154              OSPF with Digital Signatures             June 1997


   An LSA will be removed from a router's Link State Database in one of
   two ways: 1) the router receives a version of the LSA with the age
   field set to MaxAge and a valid signature that covers the age field,
   or 2) the LSA incrementally reaches MaxAge while it is stored by the
   router.

   If a standard OSPF V2 router goes down, an LSA from that router will
   age in the LSDBs of each remaining router until it reaches MaxAge
   somewhere.  As soon as it reaches MaxAge in some router's LSDB it is
   flooded, and this causes it to be flushed from the AS in a
   synchronized fashion.  If router running OSPF with digital signatures
   goes down, its signed LSAs will be aged out by each remaining router
   individually.  This will slow database convergence but the databases
   will still converge, and a fairly obvious security hole will be
   closed.

4.  Key Management

4.1.  Identifying Keys

4.1.1.  Identifying Router Keys and PKLSAs

   A router key is identified by the Router Id, and the identifiers
   associated with the particular key in its certificate: TE Id and
   Router Key Id.  All three of these values are stored in a PKLSA
   (format in 7.1).  The Router Id is the standard LSA header
   Advertising Router.  The (TE Id, Rtr Key Id) are stored in the PKLSA
   certified data.  The TE Id is a number assigned to a Trusted Entity
   that must uniquely identify one TE in the AS.  The TE Id in a
   certificate identifies the TE that produced the certificate.  The Rtr
   Key Id is associated with a key by the Trusted Entity that produced
   the certificate.  The Trusted Entity must produce a stream of Rtr Key
   Ids for one router such that the router will not re-use a key id
   until all references to the last key having that id are gone from the
   AS.  If a key is re-played, or re-used too soon, the Create Time in
   the key certification will determine which key is current.  Rtr Key
   Ids do not have to be sequential.

4.1.2.  Identifying TE Public Keys

   Each TE public key has an associated TE Id, TE Key Id.  The
   combination of (TE Id, TE Key Id) uniquely identifies one TE public
   key in the AS.  The TE Id is a number assigned to a Trusted Entity








Murphy, et. al.               Experimental                      [Page 8]

RFC 2154              OSPF with Digital Signatures             June 1997


   that uniquely identifies one TE in the AS.  The TE Key Id must
   identify one particular key for a TE at any given time.  The TE Key
   Id distinguishes between a new key and an old key for the same TE.
   The TE Key Id also differentiates between keys for different
   signature algorithms if one TE serves multiple algorithms.  Each TE
   can have at most one current key per signature algorithm.

   There can be multiple TE keys stored on each router.  A TE public key
   is used to verify the certificates issued by other routers, and in an
   AS with several TEs, any given router may need several TE public
   keys.  TE Key Ids do not have to be used sequentially, and they can
   be re-used.  There is no timestamp for TE keys because these are not
   certified.

   It is the responsibility of Configuration Management to ensure that
   TE Key Ids are not re-used before all references to a previously used
   key with the same (TE Id, TE Key Id) are gone from the AS, that a
   given (TE Id, TE Key Id) on one router identifies the same key as it
   does on any other router, and that the rules for TE Key Replacement
   (section 4.5) are followed.

4.1.3.  Key to use for Signing

   A router is configured with a pair of keys.  The private key is
   protected from disclosure and is used for signing.  The public key is
   flooded in a PKLSA and is used for verifying signatures.  A router
   may have one key per area to use for signing at any given time.  A
   router may use the same key for several or all areas.

4.1.4.  Key to use for Verification

   There are three uses of signature verification in this design:

   (1) The signature in a signed LSA (format in 7.3) can be verified
       with the public key distributed by the advertising router in a
       Public Key LSA.  A signed LSA contains the (TE Id, Rtr Key Id) of
       the key used to sign it.  The signed LSA's Advertising Router Id
       is used to retrieve the router's PKLSA , and the (TE Id, Rtr Key
       Id) indicates if the router key in the PKLSA is the same as the
       one used to generate the signature.

   (2) The router's signature in a PKLSA (format in 7.1) is verified
       with the public key contained in that PKLSA.








Murphy, et. al.               Experimental                      [Page 9]

RFC 2154              OSPF with Digital Signatures             June 1997


   (3) The PKLSA contains data certified with a signature generated
       by a TE.  The PKLSA certified data contains the (TE Id, TE Key
       Id) for the TE key that can be used to verify the certificate
       (format in 7.2).  TE public keys must be configured on each
       router.

4.2.  Trusted Entity (TE) Requirements

   This design does not specify how the Trusted Entity (TE) must be
   implemented, where it must reside, or how it must communicate with
   routers.  There are several very different possible approaches to the
   implementation of a Trusted Entity (e.g., an offline system with
   distribution of keys by floppy or secure e-mail, an online automated
   key distribution center, etc.) This design does mandate certain
   requirements for what a Trusted Entity must do.  A Trusted Entity
   must generate a certificate for each signing router that contains
   individualized information about that router (format in 7.2) and is
   signed with the Trusted Entity private key.  The Trusted Entity must
   have a unique TE Id for itself, it must create a Rtr Key Id for each
   router key that is unique for the given Router for this TE at this
   time, and it must timestamp certificates with a Create Time that is
   consistent for itself and for any other Trusted Entities operating in
   the AS.  Note: routers do not have to be time-synched, but TEs do.
   Create Time is used by routers as a relative measure to determine
   which key is more recent.

   The TE Public key, TE Id, TE Key Id and Signature Algorithm must be
   made available to each router processing certificates from this TE.

   A TE can theoretically create certificates for more than one
   signature algorithm.  The TE key and the router public key certified
   do not have to be of the same signature algorithm.

   There can be more than one TE in an AS but the TE Id must identify a
   unique TE.

4.3.  Scope for Keys and Signature Algorithms

   The concept of "scope" relates to Router Keys, TE Keys, and Signature
   Algorithms.

   (1) The scope of a PKLSA and therefore a router key, is defined to
       be the set of routers that will receive and store that PKLSA in
       the course of OSPF flooding.  A router produces a PKLSA for each
       attached area.  In a router with more than one area, the PKLSAs
       for each area may match, or each may contain a different key.
       The scope of PKLSA for an internal router is all the routers in
       that area.  An ABR has multiple PKLSAs, each having a scope of



Murphy, et. al.               Experimental                     [Page 10]

RFC 2154              OSPF with Digital Signatures             June 1997


       one attached area.  The scope of an ASBR's PKLSA is the same as
       the scope of the ASBRs ASEs - all the routers in all the non-stub
       areas in the AS.  An ASBR that is an ABR produces multiple PKLSAs
       that each have a scope of all the routers in all the non-stub