RFC2329 - OSPF Standardization Report

NetworkWorkingGroup J. Moy

Requestfor Comments: 2329 Ascend Communications, Inc.

Category: Informational April 1998

OSPF Standardization Report

Status of this Memo

This memo provides information for the Internet community.It does

notspecifyan Internet standard ofany kind. Distributionof this

memo is unlimited.

Abstract

This memo documentshow therequirements for advancing a routing

protocol toFull Standard, set out in [Ref2], have been metfor

OSPFv2.

Please sendcomments to ospf@gated.cornell.edu.

Table of Contents

1 IntrodUCtion ........................................... 2

2 Modifications since Draft Standardstatus .............. 3

2.1 Point-to-MultiPoint interface .......................... 4

2.2 Cryptographic Authentication ........................... 5

3 Updated implementation anddeployment 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 documentedin [Ref8]. OSPFis a link-staterouting

protocol. It is designed to be runinternal to a single Autonomous

System. Each OSPF router maintainsan identical database describing

theAutonomous System's topology. From this database, a routing

table is calculatedby constructinga shortest-pathtree. OSPF

features include the following:

oOSPF responds quickly to topology changes, expending a minimum

of network bandwidth inthe process.

oSupportfor CIDR addressing.

oOSPF routing exchanges can be authenticated, providing routing

security.

oEqual-cost multipath.

oAn arearoutingcapability is provided,enabling an Autonomous

system to be split intoa two level hierarchy to further reduce

the amount of routing protocol traffic.

oOSPF allows import of external routing information intothe

Autonomous System, including a tagging feature that canbe

exploited to exchange extra informationat the AS boundary (see

[Ref7]).

An analysisof OSPFtogether with amore detailed description of

OSPF features was originally provided in [Ref6], asa part of

promoting OSPF to Draft Standard status. The analysis of OSPF

remains unchanged. Two additional major features have been developed

forOSPF since the protocolachieved Draft Standardstatus:the

Point-to-MultiPointinterface and Cryptographic Authentication.

These features are described in Sections 2.1 and 2.2 respectively of

this memo.

TheOSPF MIB is documented in [Ref4]. It iscurrently at Draft

Standard status.

2. Modifications sinceDraft Standard status

OSPF becamea DraftStandard with the release of RFC1583 [Ref3].

Implementations of the new specification in[Ref8] are backward-

compatible with RFC1583. The differences between the two documents

aredescribed in the Appendix Gs of[Ref1] and [Ref8]. These

differencesare listed briefly below. Two major features were also

added, the Point-to-MultiPoint interface and Cryptographic

Authentication, which are describedin separate sections.

oConfiguration requirements for OSPF area address rangeshave

been relaxed toallow greater flexibility in area assignment.

See Section G.3of [Ref1] for details.

oThe OSPF flooding algorithm wasmodified to a) improve database

convergence in networkswith low speed links b)resolvea

problemwhere unnecessary LSA retransmissions could occur as a

result of differing clock granularities, c) remove race

conditions between the floodingof MaxAge LSAs and the Database

Exchange process, d) clarify the use ofthe MinLSArrival

constant, and e) rate-limit theresponse to less recentLSAs

received via flooding.See Sections G.4 and G.5 of [Ref1] and

SectionG.1 of [Ref8] for details.

oTo resolve the long-standing confusion regarding representation

of point-to-point linksin OSPF, the specification now

optionally allows advertisementof a stub link to a point-to-

point link's subnet, ala RIP. See Section G.6 of [Ref1].

oSeveralproblems involving advertising the sameexternal route

from multiple areas were found and fixed, as described in

SectionG.7 of [Ref1] and Section G.2 of [Ref8]. Without the

fixes, persistent routing loopscould form in certain such

configurations.Note that one of the fixes was not backward-

compatible, in that mixing routers implementingthe fixes with

those implementing justRFC1583 could cause loops not present

in an RFC1583-only configuration. Thiscaused an

RFC1583Compatibility global configuration parameter to be added,

as described inSectionC.1 of [Ref1].

oIn order to deal with high delay links,retransmissionsof

initialDatabase Description packets nolonger reset anOSPF

adjacency.

oIn order to detect linkMTU mismatches,which can causeproblems

both inIP forwarding and in the OSPF routing protocol itself,

MTU wasadded to OSPF'sDatabase Description packets.

Neighboring routers refuse to bring up an OSPF adjacency unless

they agree on their common link's MTU.

oThe TOSroutingoption was deleted fromOSPF. 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.

oOSPF's routing table lookup algorithm was changed to reflect

currentpractice. The "best match" routing table entry is now

always selectedto be the one providingthe most specific

(longest) match. See Section G.4 of [Ref8] for details.

2.1. Point-to-MultiPoint interface

The Point-to-MultiPointinterface was added as an alternative to

OSPF's NBMA interface when running OSPFover non-broadcast

subnets. Unlikethe NBMA interface, Point-to-MultiPointdoes not

requirefull mesh connectivity over thenon-broadcast subnet.

Point-to-MultiPoint is less efficient than NBMA, but iseasier

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 informationon the Point-to-

MultiPoint interface, see Section G.2 of [Ref1].

There are at least six independent implementations of the

Point-to-MultiPoint interface. Interoperabilityhas been

demonstrated between atleast two pairsof implementations:

between3com and Bay Networks, and between cisco and Cascade.

2.2. CryptographicAuthentication

Non-trivial authentication was added toOSPF with the

development of the Cryptographic Authenticationtype. This

authentication type uses any keyed message digest algorithm,

with explicit instructions included forthe useof MD5.For more

information on OSPF authentication, seeSection4.

There are at least three independent implementations ofthe OSPF

Cryptographic authentication type. Interoperability hasbeen

demonstrated between the implementations from cisco andCascade.

3. Updated implementation and deployment experience

When OSPF was promoted to Draft Standard Status, a report was issued

documentingcurrentimplementation and deployment experience (see

[Ref6]). That report is nowquite dated. Inan attempt to get more

current data, a questionnaire was sent to OSPF mailing listin

January 1996. Twelve responses werereceived, from 11 router vendors

and1 manufacturer of test equipment. Theseresponses represented 6

independentimplementations. A tabulation of the results are

presented below.

Table 1 indicates the implementation, interoperability and

deployment of the major OSPF functions. Thenumber in each column

represents the number of responses in the affirmative.

Imple-Inter-

Feature mentedoperated Deployed

_______________________________________________________

OSPF areas 1010 10

Stub areas 1010 9

Virtual links 109 8

Equal-cost multipath 107 8

NBMA support 98 7

CIDR addressing 85 6

OSPF MIB 85 5

Cryptographic auth. 32 1

Point-to-Multipointifc. 63 4

Table 1: Implementation of OSPF features

Table 2 indicates the size of the OSPF routing domains thatvendors

have tested. For each size parameter, the number ofresponders and

therange of responses (minimum, mode, meanand maximum) are listed.

Parameter ResponsesMin Mode Mean Max

_________________________________________________________________

Max routers in domain 730 240 460 1600

Max routers in single area 720 240 380 1600

Max areas in domain 71 10 16 60

Max AS-external-LSAs 950 10K 10K 30K

Table 2:OSPF domain sizes tested

Table 3 indicates the size of the OSPF routing domains thatvendors

have deployed in real networks. Foreach size parameter, the number

of responders and the rangeof responses (minimum, mode, mean and

maximum) are listed.

Parameter ResponsesMin Mode Mean Max

_________________________________________________________________

Max routers in domain 820 350 510 1000

Max routers in single area 820 100 160 350

Max areas in domain 71 15 23 60

Max AS-external-LSAs 650 1K 2K 5K

Table 3: OSPF domain sizes deployed

In an attempt to ascertain the extent to which OSPFis currently

deployed, vendors were alsoasked 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

AllOSPF protocol exchangesare authenticated. OSPFsupports

multiple types of authentication; the type of authentication in use

canbe configured on a per network segment basis. One of OSPF's

authentication types, namely the Cryptographic authentication

option, is believedto be secure against passive attacks and provide

significantprotection against active attacks. Whenusing the

Cryptographic authentication option, each router appends a "message

digest" to its transmitted OSPF packets. Receivers then usethe

shared secret key and received digest to verify that each received

OSPF packetis authentic.

Thequalityof the securityprovided by theCryptographic

authentication option depends completely onthe strength ofthe

message digest algorithm (MD5 is currently the onlymessagedigest

algorithm specified), the strength of the key beingused, and the

correct implementation of the security mechanism inall

communicating OSPF implementations. It also requires that all

parties maintain the secrecy of theshared secret key.

None of theOSPF authentication types provide confidentiality. Nor

do they protect against traffic analysis. Key management isalso not

addressed by the OSPF specification.

Formore information, see Sections 8.1, 8.2, and Appendix Dof

[Ref1].

References

[Ref1] Moy, J., "OSPF Version 2", RFC2178, July 1997.

[Ref2] Hinden, B.,"Internet Routing Protocol Standardization

Criteria", RFC1264, October 1991.

[Ref3] Moy, J., "OSPF Version 2", RFC1583, March 1994.

[Ref4] Baker, F., and R. Coltun, "OSPF Version 2 Management

InformationBase", RFC1850, November 1995.

[Ref5] Moy, J., "OSPF Protocol Analysis", RFC1245, August1991.

[Ref6] Moy, J., "Experience with the OSPF Protocol", RFC1246,

August 1991.

[Ref7] Varadhan, K., HaresS., andY. Rekhter, "BGP4/IDRP for IP--

-OSPF Interaction",RFC1745, December 1994.

[Ref8] Moy, J., "OSPF Version 2", STD 54, RFC2328, April 1998.

Security Considerations

Security considerations areaddressed 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

This document and translations of it may be copied and furnished

to others, and derivative worksthat comment onor otherwise

explainit or assist inits 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 thisparagraph are included on all such copies and

derivative works. However, this document itself may not be

modified in anyway, such as byremoving the copyright notice or

references to the Internet Society or other Internet

organizations, except as neededfor thepurposeof developing

Internet standards in which case the proceduresfor copyrights

definedin the InternetStandards process must be followed, or

as required to translate it into languages other than English.

The limited permissionsgrantedabove are perpetual andwill not

be revoked by the Internet Society or its successors orassigns.

This document and the information contained herein is provided

on an "AS IS" basis andTHE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THATTHE USE

OF THE INFORMATION HEREIN WILL NOT INFRINGE ANYRIGHTS OR ANY

IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A

PARTICULAR PURPOSE.