rfc2154.txt

RFC 的详细文档！

5.  Compatibility with Standard OSPF V2

   OSPF with Digital Signatures is compatible with standard OSPF V2 in
   an autonomous system.  Within an AS, there may be "signed" areas and
   "unsigned" areas.  There will never be both signed and unsigned LSAs
   used in any one area.  Each area will have an environment flag
   indicating whether it is "signed" or "unsigned".  The environment
   flag is a per area configuration value for the router.  The signed
   areas must contain all routers running OSPF with Digital Signatures,
   and the unsigned areas contain routers running standard OSPF V2 code
   (or OSPF with Digital Signatures with all areas set to be unsigned).
   An area border router connecting a signed to an unsigned area must be
   running OSPF with Digital Signatures with one area set to be
   unsigned.

   In order to arrange this limited compatibility, a router running OSPF
   with Digital Signatures must be able to process both signed and
   unsigned LSAs.  The only router that will actually be processing both
   kinds of LSAs is an Area Border Router connecting a signed area to an
   unsigned area.  An ABR connecting a signed to an unsigned area will
   generate signed summaries for one area and unsigned summaries for the
   other.  An ABR must not flood signed LSAs into unsigned areas.  An
   ABR must not flood unsigned LSAs into signed areas.  This will result
   in AS External LSAs being dropped if they reach an area that has a
   different environment from the one in which they were created.  There
   are special limitations in the case of a router that is an ABR and
   also an ASBR: see section 6.

   Complete connectivity is provided within the AS, because of the
   summarization provided by ABRs connecting signed and unsigned areas.
   There are limitations on connectivity to AS external routes in an AS
   with a mixture of signed and unsigned areas, depending on the
   location of AS border routers.  An ASBR in a signed area will
   generate signed ASE LSAs.  These LSAs will be flooded to every
   contiguously connected signed area.  The connected signed areas are
   the "scope" of these ASEs.  A host located in an area that is not in
   this scope, will not have connectivity to these external routes.  An
   ASBR in an unsigned area will generate unsigned ASE LSAs.  These LSAs



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


   will have a scope of all the contiguously connected unsigned areas,
   and will be available to hosts in this scope.  To arrange complete
   connectivity to an ASE route in an AS with signed and unsigned areas:

   (1) Place the ASBR on the backbone.

   (2) Signed Backbone: have some ABR in each unsigned area advertise a
       default route to the backbone.

   (3) Unsigned Backbone: have some ABR in each signed area advertise a
       default route to the backbone.

   Given this design for a mixed AS, routing is available throughout the
   AS, but the authentication and integrity provided by this design will
   be effective only for routes that are inside a signed area, or
   traverse only signed areas.  There is no mechanism for a data packet
   to state a preference for signed routes.  The basic rules of the OSPF
   protocol ensure that intra-area routes are preferred to inter-area
   routes, that routes within the AS are preferred to AS external
   routes, and that inter-area routes go from area1->backbone->area2.
   OSPF does not allow looping, or routes of the form area1->area2-
   >area3.  Because of these properties of OSFP routing, an AS can
   contain signed and unsigned areas, and achieve a predictable level of
   authentication.

6.  Special Considerations/Restrictions for the ABR-ASBR

   There are special restrictions and configuration considerations for a
   router running OSPF with Digital Signatures that is both an Area
   Border Router and an Autonomous System Border Router.  An ASBR
   produces AS external LSAs that are flooded throughout the non-stub
   areas of the AS.  An ABR that is generating digital signatures may be
   using a different key, certifying Trusted Entity, or signature
   algorithm for each of its attached areas, or it might be signing in
   some areas and not in others.

   An ABR/ASBR with no restrictions on its configuration could produce
   multiple versions of an ASE that would all be flooded throughout the
   non-stub areas of the AS.  The results of this production of multiple
   versions of LSAs would be detrimental to performance, and could
   produce unpredictable routing behavior.










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


   The PKLSA of an ASBR is also flooded throughout the non-stub areas of
   the AS, and in the case of an ABR/ASBR there could be multiple,
   distinct PKLSAs for a given router, one per attached area, all being
   flooded throughout the AS.  If two distinct PKLSAs from one ABR/ASBR
   router were present in one area, the key with the most recent create
   time would be stored, and all LSAs signed with a less recent key
   would be unverifiable.

   The simplest way to deal with this problem, and the method
   recommended by this document, is the following:

   If an ASBR must also be an ABR, then the security configuration (key,
   signature algorithm, certifying Trusted Entity, environment =
   signed/unsigned) for all attached areas must be the same.  This way
   the PKLSA and the ASEs produced for each area match, and there is no
   proliferation of versions of LSAs.

7.  LSA formats

7.1.  Router Public Key LSA (PKLSA)

   This LSA is the vehicle for distribution of a router public key.  The
   PKLSA is sent by one router, and stored by all the other routers in
   the flooding scope.  The PKLSA contains the public key that other
   routers will use to verify the signatures created by this router.  A
   Router PKLSA will be communicated in the usual database exchange and
   via flooding mechanisms. The regular period for sending this LSA is
   LSRefreshTime.  The Router PKLSA will also be sent when there is a
   new key, or a key to be flushed from the system.

   The flooding scope of a PKLSA is the area, except in the case of
   ASBRs.  The flooding scope of an ASBR's PKLSA is the same as that of
   the ASEs.  The "role" of the router (RTR, ABR, ASBR, ABR-ASBR) is
   stored in the PKLSA inside the certificate, and can be checked during
   flooding.
















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


   ROUTER PUBLIC KEY LSA

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |            LS Age             |   Options     |    LS Type    |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                        Link State ID                          |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                     Advertising Router                        |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                     LS Sequence Number                        |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |         LS Checksum           |            Length             |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                  Certificate (format in 7.2)                  /
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                           Signature                           /
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |         Cert Length           |         Sign Length           |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+

   LS AGE          Defined in OSPF RFC [3].

   OPTIONS         Defined in OSPF RFC [3].

   LS TYPE         16 for Router Public Key LSA.
                   First bit set to indicate a signed LSA.

   LINK STATE ID   Contains the Advertising Router Id (see next field).

   ADVERTISING ROUTER  Defined in OSPF RFC [3].

   LS SEQUENCE NUMBER  Defined in OSPF RFC [3].

   LS CHECKSUM     Defined in OSPF RFC [3].
                   Checksum does not cover the signature.

   LENGTH          Defined in OSPF RFC [3].  Length does include the
                   Signature field, Cert Length and Sign Length.

   CERTIFICATE     Format in section 7.2.









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


   SIGNATURE       The advertising router's signature of this LSA.  This
                   can be verified using the enclosed Router Public Key.
                   The signature covers the LSA header and message
                   starting with the LSA header options field and ending
                   with the Trusted Entity certification field.  For
                   sign and verify, the last two fields (Cert Length and
                   Sign Length) are appended immediately after the
                   Certificate.  When complete, the signature is
                   inserted between the Certification and the Cert
                   Length.  There are two exceptions to this coverage:

                   1) If the LSA was generated with an age=MaxAge, then
                   the signature begins with the age field (see section
                   3.3).

                   2) The checksum in the LSA Header is set to zero for
                   the computation of the signature.

                   A pad is added to the end of the signature field to
                   allow the next field to begin on a (4 byte) word
                   boundary.

                   The format used for an RSA-MD5 signature is defined
                   in section 4.1.2 of RFC2065 [10].

   CERT LENGTH     The length in bytes of the Certification inside the
                   Certificate.
                   Does not include pad that may follow Certification.

   SIGN LENGTH     The length in bytes of the Signature.
                   Does not include pad that may follow Signature.

7.2.  Router Public Key Certificate

   A router public key certificate is a package of data signed by a
   Trusted Entity.  This certificate is included in the router PKLSA and
   in the router configuration information.  To change any of the values
   in the certificate, a new certificate must be obtained from a TE.













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


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          Router Id                            |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |     TE Id     |   TE Key Id   |   Rtr Key Id  |    Sig Alg    |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          Create Time                          |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |        Key Field Length       |  Router Role  |  #Net Ranges  |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                         Address Mask                          |