Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ospf-stdreport-02.txt < prev next >

Wrap

Text File | 1997-05-02 | 13KB | 450 lines

Network Working Group J. Moy Internet Draft Cascade Communications Corp. Expiration Date: November 1997 May 1997 File name: draft-ietf-ospf-stdreport-02.txt OSPF Standardization Report Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met for OSPFv2. Please send comments to ospf@gated.cornell.edu. Table of Contents 1 Introduction ........................................... 2 2 Modifications since Draft Standard status .............. 2 2.1 Point-to-MultiPoint interface .......................... 3 2.2 Cryptographic Authentication ........................... 4 3 Updated implementation and deployment experience ....... 4 4 Protocol Security ...................................... 6 References ............................................. 7 Security Considerations ................................ 8 Author's Address ....................................... 8 Moy [Page 1] Internet Draft OSPFv2 Standardization Report May 1997 1. Introduction OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing protocol documented in [Ref1]. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest-path tree. OSPF features include the following: o OSPF responds quickly to topology changes, expending a minimum of network bandwidth in the process. o Support for CIDR addressing. o OSPF routing exchanges can be authenticated, providing routing security. o Equal-cost multipath. o An area routing capability is provided, enabling an Autonomous system to be split into a two level hierarchy to further reduce the amount of routing protocol traffic. o OSPF allows import of external routing information into the Autonomous System, including a tagging feature that can be exploited to exchange extra information at the AS boundaries (see [Ref7]). An analysis of OSPF together with a more detailed description of OSPF features was originally provided in [Ref6], as a part of promoting OSPF to Draft Standard status. The analysis of OSPF remains unchanged. Two additional major features have been developed for OSPF since the protocol achieved Draft Standard status: the Point-to-MultiPoint interface and Cryptographic Authentication. These features are described in Sections 2.1 and 2.2 respectively of this memo. The OSPF MIB is documented in [Ref4]. It is currently at Draft Standard status. 2. Modifications since Draft Standard status OSPF was last released as RFC 1583 [Ref3], which is labeled with Draft Standard status. Implementations of the new specification in [Ref1] are backward-compatible with RFC 1583. The differences between the two documents are described in Appendix G of [Ref1]. These differences are listed briefly below. Two major features were Moy [Page 2] Internet Draft OSPFv2 Standardization Report May 1997 also added, the Point-to-MultiPoint interface and Cryptographic Authentication, which are described in separate sections. o Configuration requirements for OSPF area address ranges have been relaxed to allow greater flexibility in area assignment. See Section G.3 of [Ref1] for details. o The OSPF flooding algorithm was modified to a) improve database convergence in networks with low speed links and b) resolve a problem where unnecessary LSA retransmissions could occur as a result of differing clock granularities. See Sections G.4 and G.5 of [Ref1] for details. o To resolve the long-standing confusion regarding representation of point-to-point links in OSPF, the specification now optionally allows advertisement of a stub link to a point-to- point link's subnet, ala RIP. See Section G.6 of [Ref1]. o Several problems involving advertising the same external route from multiple areas were found and fixed, as described in Section G.7 of [Ref1]. Without the fixes, persistent routing loops could form in certain such configurations. Note that one of the fixes was not backward-compatible, in that mixing routers implementing the fixes with those implementing just RFC 1583 could cause loops not present in an RFC 1583-only configuration. This caused an RFC1583Compatibility global configuration parameter to be added, as described in Section C.1 of [Ref1]. o In order to deal with high delay links, retransmissions of initial Database Description packets no longer reset an OSPF adjacency. o In order to detect link MTU mismatches, which can cause problems both in IP forwarding and in the OSPF routing protocol itself, MTU was added to OSPF's Database Description packets. Neighboring routers refuse to bring up an OSPF adjacency unless they agree on their common link's MTU. o The TOS routing option was deleted from OSPF. However, for backward compatibility the formats of OSPF's various LSAs remain unchanged, maintaining the ability to specify TOS metrics in router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external- LSAs. 2.1. Point-to-MultiPoint interface The Point-to-MultiPoint interface was added as an alternative to OSPF's NBMA interface when running OSPF over non-broadcast Moy [Page 3] Internet Draft OSPFv2 Standardization Report May 1997 subnets. Unlike the NBMA interface, Point-to-MultiPoint does not require full mesh connectivity over the non-broadcast subnet. Point-to-MultiPoint is less efficient than NBMA, but is easier to configure (in fact, it can be self-configuring) and is more robust than NBMA, tolerating all failures within the non- broadcast subnet. For more information on the Point-to- MultiPoint interface, see Section G.2 of [Ref1]. There are at least six independent implementations of the Point-to-MultiPoint interface. Interoperability has been demonstrated between at least two pairs of implementations: between 3com and Bay Networks, and between cisco and Cascade. 2.2. Cryptographic Authentication Non-trivial authentication was added to OSPF with the development of the Cryptographic Authentication type. This authentication type uses any keyed message digest algorithm, with explicit instructions included for the use of MD5. For more information on OSPF authentication, see Section 4. There are at least three independent implementations of the OSPF Cryptographic authentication type. Interoperability has been demonstrated between the implementations from cisco and Cascade. 3. Updated implementation and deployment experience When OSPF was promoted to Draft Standard Status, a report was issued documenting current implementation and deployment experience (see [Ref6]). That report is now quite dated. In an attempt to get more current data, a questionnaire was sent to OSPF mailing list in January 1996. Twelve responses were received, from 11 router vendors and 1 manufacturer of test equipment. These responses represented 6 independent implementations. A tabulation of the results are presented below. Table 1 indicates the implementation, interoperability and deployment of the major OSPF functions. The number in each column represents the number of responses in the affirmative. Moy [Page 4] Internet Draft OSPFv2 Standardization Report May 1997 Imple- Inter- Feature mented operated Deployed _______________________________________________________ OSPF areas 10 10 10 Stub areas 10 10 9 Virtual links 10 9 8 Equal-cost multipath 10 7 8 NBMA support 9 8 7 CIDR addressing 8 5 6 OSPF MIB 8 5 5 Cryptographic auth. 3 1 1 Point-to-Multipoint ifc. 6 3 4 Table 1: Implementation of OSPF features Table 2 indicates the size of the OSPF routing domains that vendors have tested. For each size parameter, the number of responders and the range of responses (minimum, mode, mean and maximum) are listed. Parameter Responses Min 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: OSPF domain sizes tested Table 3 indicates the size of the OSPF routing domains that vendors have deployed in real networks. For each size parameter, the number of responders and the range of responses (minimum, mode, mean and maximum) are listed. Moy [Page 5] Internet Draft OSPFv2 Standardization Report May 1997 Parameter Responses Min 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 4. Protocol Security All 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 OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. Key management is also not addressed by the OSPF specification. For more information, see Sections 8.1, 8.2, and Appendix D of [Ref1]. Moy [Page 6] Internet Draft OSPFv2 Standardization Report May 1997 References [Ref1] Moy, J., "OSPF Version 2", Internet Draft, <draft-ietf- ospf-version2-11.txt>, Cascade, April 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 Base", RFC 1850, November 1995. [Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991. [Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246, August 1991. [Ref7] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP--- OSPF Interaction", RFC 1745, December 1994. Moy [Page 7] Internet Draft OSPFv2 Standardization Report May 1997 Security Considerations Security considerations are addressed in Section 4 of this memo. Author's Address John Moy Cascade Communications Corp. 5 Carlisle Road Westford, MA 01886 Phone: 508-952-1367 Fax: 508-692-9214 Email: jmoy@casc.com This document expires in November 1997. Moy [Page 8]