Status of this Memo

    This memo provides information for the Internet community.  t does
    not pecify  n Internet standard of  ny kind.  Distribution  f this
    memo is unlimited.

Copyright Notice

Copyright © The Internet Society (1998). ll Rights Reserved.

Abstract

    This memo documents ow the  equirements for advancing a routing
    protocol to ull Standard, set out in [Ref2], have been met  or
    OSPFv2.

Please send omments to ospf@gated.cornell.edu.

Table of Contents

    1       Introduction ........................................... 2
    2       Modifications since Draft Standard  tatus .............. 3
    2.1     Point-to-MultiPoint interface .......................... 4
    2.2     Cryptographic Authentication ........................... 5
    3       Updated implementation and  eployment experience ....... 5
    4       Protocol Security ...................................... 7
    
            References  ............................................ 8
            Security Considerations ................................ 8
            Author's Address ....................................... 8
            Full Copyright Statement ............................... 9

1. Introduction

    OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing
    protocol documented n [Ref8]. OSPF  s a link-state  outing
    protocol.  It is designed to be run nternal to a single Autonomous
    System.  Each OSPF router maintains n identical database describing
    the utonomous System's topology.  From this database, a routing
    table is calculated y constructing   shortest-path  ree. OSPF
    features include the following:
    
    o   SPF responds quickly to topology changes, expending a minimum
        f network bandwidth in  he process.
    
    o   upport  or CIDR addressing.
    
    o   SPF routing exchanges can be authenticated, providing routing
        ecurity.
    
    o   qual-cost multipath.
    
    o   n area  outing  apability is provided,  nabling an Autonomous
        ystem to be split into   two level hierarchy to further reduce
        he amount of routing protocol traffic.
    
    o   SPF allows import of external routing information into  he
        utonomous System, including a tagging feature that can  e
        xploited to exchange extra information  t the AS boundary (see
        Ref7]).
    
    An analysis f OSPF  ogether with a  ore detailed description of
    OSPF features was originally provided in [Ref6], as  part of
    promoting OSPF to Draft Standard status. The analysis of OSPF
    remains unchanged. Two additional major features have been developed
    for SPF since the protocol  chieved Draft Standard  tatus:  he
    Point-to-MultiPoint nterface and Cryptographic Authentication.
    These features are described in Sections 2.1 and 2.2 respectively of
    this memo.
    
    The SPF MIB is documented in [Ref4]. It is  urrently at Draft
    Standard status.

2. Modifications since raft Standard status

    OSPF became  Draft  tandard with the release of RFC 1583 [Ref3].
    Implementations of the new specification in Ref8] are backward-
    compatible with RFC 583. The differences between the two documents
    are escribed in the Appendix Gs of  Ref1] and [Ref8]. These
    differences re listed briefly below. Two major features were also
    added, the Point-to-MultiPoint interface and Cryptographic
    Authentication, which are described n separate sections.
    
    o   onfiguration requirements for OSPF area address ranges  ave
        een relaxed to  llow greater flexibility in area assignment.
        ee Section G.3  f [Ref1] for details.
    
    o   he OSPF flooding algorithm was  odified to a) improve database
        onvergence in networks  ith low speed links b)  esolve  
        roblem  here unnecessary LSA retransmissions could occur as a
        esult of differing clock granularities, c) remove race
        onditions between the flooding  f MaxAge LSAs and the Database
        xchange process, d) clarify the use of  he MinLSArrival
        onstant, and e) rate-limit the  esponse to less recent  SAs
        eceived via flooding.   ee Sections G.4 and G.5 of [Ref1] and
        ection  .1 of [Ref8] for details.
    
    o   o resolve the long-standing confusion regarding representation
        f point-to-point links  n OSPF, the specification now
        ptionally allows advertisement  f a stub link to a point-to-
        oint link's subnet, ala RIP. See Section G.6 of [Ref1].
    
    o   everal  roblems involving advertising the same  xternal route
        rom multiple areas were found and fixed, as described in
        ection  .7 of [Ref1] and Section G.2 of [Ref8].  Without the
        ixes, persistent routing loops  ould form in certain such
        onfigurations.  ote that one of the fixes was not backward-
        ompatible, in that mixing routers implementing  he fixes with
        hose implementing just  FC 1583 could cause loops not present
        n an RFC 1583-only configuration. This  aused an
        FC1583Compatibility global configuration parameter to be added,
        s described in  ection  .1 of [Ref1].
    
    o   n order to deal with high delay links,  etransmissions  f
        nitial  atabase Description packets no  onger reset an  SPF
        djacency.
    
    o   n order to detect link  TU mismatches,  hich can cause  roblems
        oth in  P forwarding and in the OSPF routing protocol itself,
        TU was  dded to OSPF's  atabase Description packets.
        eighboring routers refuse to bring up an OSPF adjacency unless
        hey agree on their common link's MTU.
    
    o   he TOS  outing  ption was deleted from  SPF. However, for
        ackward compatibility the formats of OSPF's various LSAs remain
        nchanged, maintaining the ability to specify TOS metrics in
        outer-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-
        SAs.
    
    o   SPF's routing table lookup algorithm was changed to reflect
        urrent  ractice. The "best match" routing table entry is now
        lways selected  o be the one providing  he most specific
        longest) match. See Section G.4 of [Ref8] for details.

2.1. Point-to-MultiPoint interface

        he Point-to-MultiPoint  nterface was added as an alternative to
        SPF's NBMA interface when running OSPF  ver non-broadcast
        ubnets. Unlike  he NBMA interface, Point-to-MultiPoint  oes not
        equire  ull mesh connectivity over the  on-broadcast subnet.
        oint-to-MultiPoint is less efficient than NBMA, but is  asier
        o configure (in fact, it can be self-configuring) and is more
        obust than NBMA, tolerating all failures within the non-
        roadcast subnet.  For more information  n the Point-to-
        ultiPoint interface, see Section G.2 of [Ref1].
        
        here are at least six independent implementations of the
        oint-to-MultiPoint interface. Interoperability  as been
        emonstrated between at  east two pairs  f implementations:
        etween  com and Bay Networks, and between cisco and Cascade.

2.2. Cryptographic uthentication

        on-trivial authentication was added to  SPF with the
        evelopment of the Cryptographic Authentication  ype. This
        uthentication type uses any keyed message digest algorithm,
        ith explicit instructions included for  he use  f MD5.  or more
        nformation on OSPF authentication, see  ection  .
        
        here are at least three independent implementations of  he OSPF
        ryptographic authentication type. Interoperability has  een
        emonstrated between the implementations from cisco and  ascade.

3. Updated implementation and deployment experience

    When OSPF was promoted to Draft Standard Status, a report was issued
    documenting urrent  mplementation and deployment experience (see
    [Ref6]). That report is now uite dated. In  n attempt to get more
    current data, a questionnaire was sent to OSPF mailing list n
    January 1996. Twelve responses were eceived, from 11 router vendors
    and  manufacturer of test equipment. These  esponses represented 6
    independent mplementations. A tabulation of the results are
    presented below.

Table 1 indicates the implementation, interoperability and deployment of the major OSPF functions. The umber in each column represents the number of responses in the affirmative.

                               Imple-   nter-
           Feature             mented   perated   Deployed
           _______________________________________________________
           OSPF areas          10       0         10
           Stub areas          10       0         9
           Virtual links              10                   8
           Equal-cost multipath       10                   8
           NBMA support       9            7
           CIDR addressing            8            6
           OSPF MIB            8                   5
           Cryptographic auth.        3            1
           Point-to-Multipoint  fc.   6            4

Table 1: Implementation of OSPF features

    Table 2 indicates the size of the OSPF routing domains that endors
    have tested. For each size parameter, the number of esponders and
    the ange of responses (minimum, mode, mean  nd maximum) are listed.
    
       Parameter            Responses   in   Mode   Mean   Max
       _________________________________________________________________
       Max routers in domain       7    30    240    460    1600
       Max routers in single area   7   20    240    380    1600
       Max areas in domain         7    1     10     16    60
       Max AS-external-LSAs        9    50    10K    10K    30K

Table 2: SPF domain sizes tested

Table 3 indicates the size of the OSPF routing domains that endors have deployed in real networks. For ach size parameter, the number of responders and the range f responses (minimum, mode, mean and maximum) are listed.

       Parameter            Responses   in   Mode   Mean   Max
       _________________________________________________________________
       Max routers in domain       8    20    350    510    1000
       Max routers in single area   8   20    100    160    350
       Max areas in domain         7    1     15     23    60
       Max AS-external-LSAs        6    50    1K     2K    5K

Table 3: OSPF domain sizes deployed

In an attempt to ascertain the extent to which OSPF s currently deployed, vendors were also sked in January 1998 to provide deployment estimates. Four vendors of OSPF routers responded, with a total estimate of 182,000 OSPF routers in service, organized into 4300 separate OSPF routing domains.

4. Protocol Security

    All SPF protocol exchanges  re authenticated. OSPF  upports
    multiple types of authentication; the type of authentication in use
    can e configured on a per network segment basis. One of OSPF's
    authentication types, namely the Cryptographic authentication
    option, is believed o be secure against passive attacks and provide
    significant rotection against active attacks. When  sing the
    Cryptographic authentication option, each router appends a "message
    digest" to its transmitted OSPF packets. Receivers then use he
    shared secret key and received digest to verify that each received
    OSPF packet s authentic.
    
    The uality  f the security  rovided by the  ryptographic
    authentication option depends completely on he strength of  he
    message digest algorithm (MD5 is currently the only essage  igest
    algorithm specified), the strength of the key being sed, and the
    correct implementation of the security mechanism in ll
    communicating OSPF implementations. It also requires that all
    parties maintain the secrecy of the hared secret key.

None of the SPF authentication types provide confidentiality. Nor do they protect against traffic analysis. Key management is lso not addressed by the OSPF specification.

    For ore information, see Sections 8.1, 8.2, and Appendix D  f
    [Ref1].

References

    [Ref1]  Moy, J., "OSPF Version 2", RFC 2178, July 1997.
    
    [Ref2]  Hinden, B., Internet Routing Protocol Standardization
           Criteria", RFC 1264, October 1991.
    
    [Ref3]  Moy, J., "OSPF Version 2", RFC 1583, March 1994.
    
    [Ref4]  Baker, F., and R. Coltun, "OSPF Version 2 Management
           Information  ase", RFC 1850, November 1995.
    
    [Ref5]  Moy, J., "OSPF Protocol Analysis", RFC 1245, August 991.
    
    [Ref6]  Moy, J., "Experience with the OSPF Protocol", RFC 1246,
           August 1991.
    
    [Ref7]  Varadhan, K., Hares ., and  . Rekhter, "BGP4/IDRP for IP--
           -OSPF Interaction",  FC 1745, December 1994.
    
    [Ref8]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

Security Considerations

Security considerations are ddressed in Section 4 of this memo.

Author's Address

John Moy
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886

    Phone: 978-952-1367
    Fax:   978-392-2075
    EMail: jmoy@casc.com
    Full Copyright Statement
    
        opyright © The Internet Society (1998).  All  ights Reserved.
    
        his document and translations of it may be copied and furnished
        o others, and derivative works  hat comment on  r otherwise
        xplain  t or assist in  ts implementation may be prepared,
        opied,  ublished and distributed, in whole or in part,  ithout
        estriction of any kind, provided that the above copyright
        otice and this  aragraph are included on all such copies and
        erivative works.  However, this document itself may not be
        odified in any  ay, such as by  emoving the copyright notice or
        eferences to the Internet Society or other Internet
        rganizations, except as needed  or the  urpose  f developing
        nternet standards in which case the procedures  or copyrights
        efined  n the Internet  tandards process must be followed, or
        s required to translate it into languages other than English.
    
        he limited permissions  ranted  bove are perpetual and  ill not
        e revoked by the Internet Society or its successors or  ssigns.
    
        his document and the information contained herein is provided
        n an "AS IS" basis and  HE INTERNET SOCIETY AND THE INTERNET
        NGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
        MPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT  HE USE
        F THE INFORMATION HEREIN WILL NOT INFRINGE ANY  IGHTS OR ANY
        MPLIED  ARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
        ARTICULAR PURPOSE.