|
Network Working Group Request for Comments: 2329 Category: Informational |
J. Moy Ascend Communications, Inc. April 1998 |
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright © The Internet Society (1998). All Rights Reserved.
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.
1 Introduction
2 Modifications since Draft Standard status
2.1 Point-to-MultiPoint interface
2.2 Cryptographic Authentication
3 Updated implementation and deployment experience
4 Protocol Security
References
Security Considerations
Author's Address
Full Copyright Statement
OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing protocol documented in [Ref8]. 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:
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.
OSPF became a Draft Standard with the release of RFC 1583 [Ref3]. Implementations of the new specification in [Ref8] are backward- compatible with RFC 1583. The differences between the two documents are described in the Appendix Gs of [Ref1] and [Ref8]. These differences are listed briefly below. Two major features were also added, the Point-to-MultiPoint interface and Cryptographic Authentication, which are described in separate sections.
The Point-to-MultiPoint interface was added as an alternative to
OSPF's NBMA interface when running OSPF over non-broadcast
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.
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.
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.
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 2 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.
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
In an attempt to ascertain the extent to which OSPF is currently deployed, vendors were also asked 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.
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].
[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 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., Hares S., and Y. Rekhter, "BGP4/IDRP for IP--
-OSPF Interaction", RFC 1745, December 1994.
[Ref8] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Security considerations are addressed in Section 4 of this memo.
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
Copyright © The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.