rfc2154.txt

RFC 的详细文档！

Network Working Group                                          S. Murphy
Request for Comments: 2154                                     M. Badger
Category: Experimental                                     B. Wellington
                                             Trusted Information Systems
                                                               June 1997

                      OSPF with Digital Signatures

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This memo describes the extensions to OSPF required to add digital
   signature authentication to Link State data, and to provide a
   certification mechanism for router data.  Added LSA processing and
   key management is detailed.  A method for migration from, or co-
   existence with, standard OSPF V2 is described.

Table of Contents

   1 Acknowledgements .............................................   2
   2 Introduction .................................................   2
   3 LSA Processing ...............................................   4
   3.1 Signed LSA .................................................   4
   3.2 Router Public Key LSA (PKLSA) ..............................   5
   3.3 MaxAge Processing ..........................................   7
   4 Key Management ...............................................   8
   4.1 Identifying Keys ...........................................   8
   4.1.1 Identifying Router Keys and PKLSAs .......................   8
   4.1.2 Identifying TE Public Keys ...............................   8
   4.1.3 Key to use for Signing ...................................   9
   4.1.4 Key to use for Verification ..............................   9
   4.2 Trusted Entity (TE) Requirements ...........................  10
   4.3 Scope for Keys and Signature Algorithms.....................  10
   4.4 Router Key Replacement .....................................  11
   4.5 Trusted Entity Key Replacement .............................  12
   4.6 Flexible Cryptographic Environments ........................  14
   4.6.1 Multiple Signature Algorithms ............................  14
   4.6.2 Multiple Trusted Entities ................................  15
   4.6.3 Multiple Keys for One Router .............................  16
   5 Compatibility with Standard OSPF V2 ..........................  16
   6 Special Considerations/Restrictions for the ABR-ASBR .........  17
   7 LSA formats ..................................................  18



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


   7.1 Router Public Key LSA (PKLSA) ..............................  18
   7.2 Router Public Key Certificate ..............................  20
   7.3 Signed LSA .................................................  23
   8 Configuration Information ....................................  26
   9 Remaining Vulnerabilities ....................................  26
   9.1 Area Border Routers ........................................  27
   9.2 Internal Routers ...........................................  27
   9.3 Autonomous System Border Routers ...........................  28
   10 Security Considerations .....................................  28
   11 References ..................................................  29
   12 Authors' Addresses ..........................................  29

1.  Acknowledgements

   The idea of signing routing information is not new.  Foremost, of
   course, there is the design that Radia Perlman reported in her thesis
   [4] and in her book [5] for signing link state information and for
   distribution of the public keys used in the signing.  IDPR [7] also
   recommends the use of public key based signatures of link state
   information.  Kumar and Crowcroft [2] discuss the use of secret and
   public key authentication of inter-domain routing protocols.  Finn [1]
   discusses the use of secret and public key authentication of several
   different routing protocols.  The design reported here is closest to
   that reported in [4] and [7].  It should be noted that [4] also
   presents techniques for protecting the forwarding of data packets, a
   topic that is not considered here, as we consider it not within the
   scope of the OSPF working group.

   The authors would also like to acknowledge many fruitful discussions
   with many members of the OSPF working group, particularly Fred Baker
   of Cisco Systems, Dennis Ferguson of MCI Telecommunications Corp.,
   John Moy of Cascade Communications Corp., Curtis Villamizar of ANS,
   Inc., and Rob Coltun of FORE Systems.

2.  Introduction

   It is well recognized that there is a need for greater security in
   routing protocols. OSPF currently provides "simple password"
   authentication where the password travels "in the clear", and there
   is work in progress[11] to provide keyed MD5 authentication for OSPF
   protocol packets between neighbors.  The simple password
   authentication is vulnerable because any listener can discover and
   use the password.  Keyed MD5 authentication is very useful for
   protection of protocol packets passed between neighbors, but does not
   address authentication of routing data that is flooded from source to
   eventual destination, through routers which may themselves be faulty
   or subverted.




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


   The basic idea of this proposal is to add digital signatures to OSPF
   LSA data, distribute certified router information and keys, and use a
   neighbor-to-neighbor authentication algorithm (like keyed MD5) to
   protect local protocol exchanges.  The content of a Hello packet,
   Link State Request, Link State Update, or Database Description will
   be protected by the neighbor-to-neighbor algorithm.  The LSAs that
   are being flooded inside the Link State Update packets are
   individually protected by a digital signature.  Each LSA will be
   signed by the originator of that information and the signature will
   stay with the data in its travels via OSPF flooding.  This will
   provide end-to-end integrity and authentication for LSA data. The
   digital signature attached to an LSA by the source router provides
   assurance that the data comes from the advertising router.  It will
   also ensure that the data has not been modified by some other router
   in the course of flooding.  In the case where incorrect routing data
   is originated by a faulty router, the signature will identify the
   source of the problem.

   Digital signatures are implemented using public key cryptography.
   There are some good books on the subject of cryptography [6], but the
   high level view of how this design uses public key cryptography is as
   follows: Each router has a pair of keys, a public key and a private
   key.  The private key is used to generate a unique signature of a
   block of data (in this case, the LSA). Each router signs its LSAs by
   first running a one-way hash algorithm (like MD5 or SHA) on the data,
   and then using its private key to sign the digest.  The signature of
   an LSA is appended to the LSA. The public key can be used by any
   other router to verify the signature.  The private key must be kept
   secret by one router and the public key must be distributed to all
   the routers that will receive link state information from the signer.
   The distribution is accomplished by creating a new LSA, the Public
   Key LSA (PKLSA), and distributing it via the standard OSPF flooding
   procedure.  Flooding will ensure that a router public key is sent
   everywhere that the router's signed LSAs are sent.

   Any router can send out a public key and claim to be a given router,
   so the public key itself provides no assurance of the actual identity
   of the sender. This assurance must be provided by a Trusted Entity.
   The Trusted Entity (TE) is a system that generates certificates for
   routers.  A certificate is a packet of information about a router
   that identifies the router and supplies a public key. Certified
   router information will include the router id, its role, the address
   ranges that the router may advertise, a timestamp and the router's
   public key. The certificate is signed by the TE.  Each router must be
   configured with a certificate and a TE public key to use in verifying
   other routers' certificates.  A router PKLSA contains the certificate
   for that router.  A router receiving a PKLSA verifies the certificate
   using the TE public key, and then verifies the whole LSA using the



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


   router public key contained in the certificate. Successful
   verification provides assurance that the PKLSA is from the correct
   router, and that it has not been altered by any other router in the
   flood path.

   OSPF with Digital Signatures is backward compatible with standard
   OSPF V2 in a limited way.  Within an AS there may be "signed" areas
   and "unsigned" areas.  The behavior of a mixed AS is discussed in
   section 5.

   Digital signatures for OSPF LSAs can be implemented with the
   following major functions:

   (1) Support for a digital signature algorithm

   (2) Support for a signed version of all routing information LSAs

   (3) Support for a new LSA: Router Public Key LSA (PKLSA)

   (4) A mechanism for key certification and certificate distribution

   (5) Extra configuration data (detail in section 7):

         Trusted Entity (TE) information and key(s)
         Router certification data and key
         Area environment flag (signed/unsigned)
         Timing intervals

   An implementation of this design exists, based on the OSPF in Gated
   version 3.5Beta3.  This implementation is available for
   use/experimentation.  Please contact the authors for information.

3.  LSA Processing

3.1.  Signed LSA

   A signed LSA contains the standard OSPF V2 header and data plus key
   identification information, a signature length and a signature.  The
   top bit of the LS type field is set to indicate the presence of a
   signature.  The signature covers the LSA header (starting with the
   options field), the LSA data, and the key identification information
   and the signature length that must be appended to the LSA data.
   There are two exceptions to this coverage: first, an LSA created with
   age=MaxAge has a signature that begins with the age field (see
   section on maxage); second, the LSA header checksum is set to zero
   for the generation of the signature.  To assist in parsing the
   message, the key id information and the signature length fields are
   placed at the end of the LSA, following the signature.  However, the



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


   message must be signed and verified with these fields immediately
   appended to the LSA data.  This can be accomplished either by doing
   the sign and verify "in parts" (allowed by RSAREF), or by storing the
   LSA data with appended fields and the LSA signature separately in the
   link state database (LSDB).

   When a signed LSA is received, the signature can be verified using
   the public key of the advertising router contained in the advertising
   router's PKLSA.  If the signature verifies, then the signed LSA is
   stored for use in routing calculations. If the signature verification
   fails, the LSA must be discarded. If the identified key is not
   available (in a PKLSA from the advertising router), then the signed
   LSA must be stored for a period of time defined by the configurable
   MAX_TRANSIT_DELAY interval.  If the key arrives within this interval,
   the LSA will be processed then.  If the key does not arrive within
   this interval, the LSA will be discarded.  This delay period prevents
   loss of routing information due to LSAs arriving prior to their
   associated PKLSAs (which should not normally be the case, but could
   happen).

   If the LSA is a Router Links LSA, the router's advertised links must
   be checked against the allowed address ranges stored in the PKLSA for
   the advertising router.  All network links (link types 2 and 3) must
   have an IP address that fits in one of the ranges defined by the list
   of address ranges in the PKLSA (format 7.2).  If there is a link that
   does not fit into one of these ranges, then an error must be logged
   and the LSA must be discarded.  Careful subnetting and corresponding
   ranges can provide very tight control on what is advertised.  A much
   less restrictive, but still useful, level of control can be obtained
   by defining allowed address ranges for an area, so that all routers
   in an area could be configured with the same set.  To trivially
   satisfy this checking, one range with a zero address and mask can be
   defined that contains all IP addresses.

   Link State Acknowledgements must be sent for all LSAs that are
   discarded due to verification failures, that are stored waiting for
   keys, and that are discarded because they are advertising a link that
   they are not allowed to advertise.

3.2.  Router Public Key LSA (PKLSA)

   A Router Public Key LSA (PKLSA) is sent in the same manner as all
   other LSAs.  This LSA contains the router's public key and
   identifying information that has been certified by a Trusted Entity.
   The router public key is used to verify signatures produced by this
   router.  There is only one PKLSA stored per router in the LSDB for an
   area, so the Router Id and LS type can be used to retrieve a given
   PKLSA.  The Router Id is stored in the PKLSA Link State Id field to



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