rfc2370.txt

RFC 的详细文档！


RFC 2370               The OSPF Opaque LSA Option              July 1998


                Any advertisement whose age is equal to MaxAge is
                omitted from the Database summary list. It is instead
                added to the neighbor's link-state retransmission list.
                A summary of the Database summary list will be sent to
                the neighbor in Database Description packets.  Each
                Database Description Packet has a DD sequence number,
                and is explicitly acknowledged.  Only one Database
                Description Packet is allowed to be outstanding at any
                one time. For more detail on the sending and receiving
                of Database Description packets, see Sections 10.6 and
                10.8 of [OSPF].

4.0  Protocol Data Structures

   The Opaque option is described herein in terms of its operation on
   various protocol data structures. These data structures are included
   for explanatory uses only, and are not intended to constrain an
   implementation. In addition to the data structures listed below, this
   specification references the various data structures (e.g., OSPF
   neighbors) defined in [OSPF].

   In an OSPF router, the following item is added to the list of global
   OSPF data structures described in Section 5 of [OSPF]:

     o Opaque capability. Indicates whether the router is running the
       Opaque option (i.e., capable of storing Opaque LSAs).  Such a
       router will continue to inter-operate with non-opaque-capable
       OSPF routers.

4.1 Additions To The OSPF Neighbor Structure

   The OSPF neighbor structure is defined in Section 10 of [OSPF].  In
   an opaque-capable router, the following items are added to the OSPF
   neighbor structure:

     o Neighbor Options. This field was already defined in the OSPF
       specification. However, in opaque-capable routers there is a new
       option which indicates the neighbor's Opaque capability. This new
       option is learned in the Database Exchange process through
       reception of the neighbor's Database Description packets, and
       determines whether Opaque LSAs are flooded to the neighbor. For a
       more detailed explanation of the flooding of the Opaque LSA see
       section 3 of this document.








Coltun                      Standards Track                     [Page 6]

RFC 2370               The OSPF Opaque LSA Option              July 1998


5.0 Management Considerations

   This section identifies the current OSPF MIB [OSPFMIB] capabilities
   that are applicable to the Opaque option and lists the additional
   management information which is required for its support.

   Opaque LSAs are types 9, 10 and 11 link-state advertisements.  The
   link-state ID of the Opaque LSA is divided into an Opaque type field
   (the first 8 bits) and a type-specific ID (the remaining 24 bits).
   The packet format of the Opaque LSA is given in Appendix A.  The
   range of topological distribution (i.e., the flooding scope) of an
   Opaque LSA is identified by its link-state type.

     o Link-State type 9 Opaque LSAs have a link-local scope. Type-9
       Opaque LSAs are flooded on a single local (sub)network but are
       not flooded beyond the local (sub)network.

     o Link-state type 10 Opaque LSAs have an area-local scope. Type-10
       Opaque LSAs are flooded throughout a single area but are not
       flooded beyond the borders of the associated area.

     o Link-state type 11 Opaque LSAs have an Autonomous-System-wide
       scope.  The flooding scope of type-11 LSAs are equivalent to the
       flooding scope of AS-external (type-5) LSAs.

   The OSPF MIB provides a number of objects that can be used to manage
   and monitor an OSPF router's Link-State Database.  The ones that are
   relevant to the Opaque option are as follows.

     The ospfGeneralGroup defines two objects for keeping track of newly
     originated and newly received LSAs (ospfOriginateNewLsas and
     ospfRxNewLsas respectively).

     The OSPF MIB defines a set of optional traps.  The ospfOriginateLsa
     trap signifies that a new LSA has been originated by a router and
     the ospfMaxAgeLsa trap signifies that one of the LSAs in the
     router's link-state database has aged to MaxAge.

     The ospfAreaTable describes the configured parameters and
     cumulative statistics of the router's attached areas. This table
     includes a count of the number of LSAs contained in the area's
     link-state database (ospfAreaLsaCount), and a sum of the LSA's LS
     checksums contained in this area (ospfAreaLsaCksumSum).  This sum
     can be used to determine if there has been a change in a router's
     link-state database, and to compare the link-state database of two
     routers.





Coltun                      Standards Track                     [Page 7]

RFC 2370               The OSPF Opaque LSA Option              July 1998


     The ospfLsdbTable describes the OSPF Process's link-state database
     (excluding AS-external LSAs).  Entries in this table are indexed
     with an Area ID, a link-state type, a link-state ID and the
     originating router's Router ID.

   The management objects that are needed to support the Opaque option
   are as follows.

     An Opaque-option-enabled object is needed to indicate if the Opaque
     option is enabled on the router.

     The origination and reception of new Opaque LSAs should be
     reflected in the counters ospfOriginateNewLsas and ospfRxNewLsas
     (inclusive for types 9, 10 and 11 Opaque LSAs).

     If the OSPF trap option is supported, the origination of new Opaque
     LSAs and purging of MaxAge Opaque LSAs should be reflected in the
     ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for types 9, 10
     and 11 Opaque LSAs).

     The number of type-10 Opaque LSAs should be reflected in
     ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should be
     included in ospfAreaLsaChksumSum.

     Type-10 Opaque LSAs should be included in the ospfLsdbTable.  Note
     that this table does not include a method of examining the Opaque
     type field (in the Opaque option this is a sub-field of the link-
     state ID).

     Up until now, LSAs have not had a link-local scope so there is no
     method of requesting the number of, or examining the LSAs that are
     associated with a specific OSPF interface. A new group of
     management objects are required to support type-9 Opaque LSAs.
     These objects should include a count of type-9 Opaque LSAs, a
     checksum sum and a table for displaying the link-state database for
     type-9 Opaque LSAs on a per-interface basis.  Entries in this table
     should be indexed with an Area ID, interface's IP address, Opaque
     type, link-state ID and the originating router's Router ID.

     Prior to the introduction of type-11 Opaque LSAs, AS-External
     (type-5) LSAs have been the only link-state types which have an
     Autonomous-System-wide scope.  A new group of objects are required
     to support type-11 Opaque LSAs.  These objects should include a
     count of type-11 Opaque LSAs, a type-11 checksum sum and a table
     for displaying the type-11 link-state database.  Entries in this
     table should be indexed with the Opaque type, link-state ID and the





Coltun                      Standards Track                     [Page 8]

RFC 2370               The OSPF Opaque LSA Option              July 1998


     originating router's Router ID.  The type-11 link-state database
     table will allow type-11 LSAs to be displayed once for the router
     rather than once in each non-stub area.

6.0 Security Considerations

   There are two types of issues that need be addressed when looking at
   protecting routing protocols from misconfigurations and malicious
   attacks.  The first is authentication and certification of routing
   protocol information.  The second is denial of service attacks
   resulting from repetitive origination of the same router
   advertisement or origination a large number of distinct
   advertisements resulting in database overflow.  Note that both of
   these concerns exist independently of a router's support for the
   Opaque option.

   To address the authentication concerns, OSPF protocol exchanges are
   authenticated.  OSPF supports multiple types of authentication; the
   type of authentication in use can be configured on a per network
   segment basis. One of OSPF's authentication types, namely the
   Cryptographic authentication option, is believed to be secure against
   passive attacks and provide significant protection against active
   attacks. When using the Cryptographic authentication option, each
   router appends a "message digest" to its transmitted OSPF packets.
   Receivers then use the shared secret key and received digest to
   verify that each received OSPF packet is authentic.

   The quality of the security provided by the Cryptographic
   authentication option depends completely on the strength of the
   message digest algorithm (MD5 is currently the only message digest
   algorithm specified), the strength of the key being used, and the
   correct implementation of the security mechanism in all communicating
   OSPF implementations. It also requires that all parties maintain the
   secrecy of the shared secret key.  None of the standard OSPF
   authentication types provide confidentiality. Nor do they protect
   against traffic analysis.  For more information on the standard OSPF
   security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].

   [DIGI] describes the extensions to OSPF required to add digital
   signature authentication to Link State data and to provide a
   certification mechanism for router data.  [DIGI] also describes the
   added LSA processing and key management as well as a method for
   migration from, or co-existence with, standard OSPF V2.

   Repetitive origination of advertisements are addressed by OSPF by
   mandating a limit on the frequency that new instances of any
   particular LSA can be originated and accepted during the flooding
   procedure.  The frequency at which new LSA instances may be



Coltun                      Standards Track                     [Page 9]

RFC 2370               The OSPF Opaque LSA Option              July 1998


   originated is set equal to once every MinLSInterval seconds, whose
   value is 5 seconds (see Section 12.4 of [OSPF]).  The frequency at
   which new LSA instances are accepted during flooding is once every
   MinLSArrival seconds, whose value is set to 1 (see Section 13,
   Appendix B and G.5 of [OSPF]).

   Proper operation of the OSPF protocol requires that all OSPF routers
   maintain an identical copy of the OSPF link-state database.  However,
   when the size of the link-state database becomes very large, some
   routers may be unable to keep the entire database due to resource
   shortages; we term this "database overflow".  When database overflow
   is anticipated, the routers with limited resources can be
   accommodated by configuring OSPF stub areas and NSSAs.  [OVERFLOW]
   details a way of gracefully handling unanticipated database
   overflows.

7.0 IANA Considerations

   Opaque types are maintained by the IANA.  Extensions to OSPF which
   require a new Opaque type must be reviewed by the OSPF working group.
   In the event that the OSPF working group has disbanded the review
   shall be performed by a recommended Designated Expert.

   Following the policies outlined in [IANA], Opaque type values in the
   range of 0-127 are allocated through an IETF Consensus action and
   Opaque type values in the range of 128-255 are reserved for private
   and experimental use.

8.0 References

   [ARA] Coltun, R., and J. Heinanen, "The OSPF Address Resolution
         Advertisement Option", Work in Progress.

   [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
          1793, April 1995.

   [DIGI] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
          Signatures", RFC 2154, June 1997.

   [IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs", Work in Progress.

   [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
           1994.







Coltun                      Standards Track                    [Page 10]

RFC 2370               The OSPF Opaque LSA Option              July 1998