idnits 2.17.1 draft-ietf-ospf-stdreport-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 184 instances of lines with control characters in the document. ** The abstract seems to contain references ([Ref2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Ref5' is defined on line 279, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2178 (ref. 'Ref1') (Obsoleted by RFC 2328) ** Obsolete normative reference: RFC 1264 (ref. 'Ref2') (Obsoleted by RFC 4794) ** Obsolete normative reference: RFC 1583 (ref. 'Ref3') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 1850 (ref. 'Ref4') (Obsoleted by RFC 4750) ** Downref: Normative reference to an Informational RFC: RFC 1245 (ref. 'Ref5') ** Downref: Normative reference to an Informational RFC: RFC 1246 (ref. 'Ref6') ** Downref: Normative reference to an Historic RFC: RFC 1745 (ref. 'Ref7') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref8' Summary: 17 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Moy 2 Internet Draft Ascend Communications, Inc. 3 Expiration Date: August 1998 February 1998 4 File name: draft-ietf-ospf-stdreport-03.txt 6 OSPF Standardization Report 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet- Drafts as 18 reference material or to cite them other than as "work in progress". 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This memo documents how the requirements for advancing a routing 29 protocol to Full Standard, set out in [Ref2], have been met for 30 OSPFv2. 32 Please send comments to ospf@gated.cornell.edu. 34 Table of Contents 36 1 Introduction ........................................... 2 37 2 Modifications since Draft Standard status .............. 2 38 2.1 Point-to-MultiPoint interface .......................... 4 39 2.2 Cryptographic Authentication ........................... 4 40 3 Updated implementation and deployment experience ....... 4 41 4 Protocol Security ...................................... 6 42 References ............................................. 7 43 Security Considerations ................................ 8 44 Author's Address ....................................... 8 45 1. Introduction 47 OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing 48 protocol documented in [Ref8]. OSPF is a link-state routing 49 protocol. It is designed to be run internal to a single Autonomous 50 System. Each OSPF router maintains an identical database describing 51 the Autonomous System's topology. From this database, a routing 52 table is calculated by constructing a shortest-path tree. OSPF 53 features include the following: 55 o OSPF responds quickly to topology changes, expending a minimum 56 of network bandwidth in the process. 58 o Support for CIDR addressing. 60 o OSPF routing exchanges can be authenticated, providing routing 61 security. 63 o Equal-cost multipath. 65 o An area routing capability is provided, enabling an Autonomous 66 system to be split into a two level hierarchy to further reduce 67 the amount of routing protocol traffic. 69 o OSPF allows import of external routing information into the 70 Autonomous System, including a tagging feature that can be 71 exploited to exchange extra information at the AS boundary (see 72 [Ref7]). 74 An analysis of OSPF together with a more detailed description of 75 OSPF features was originally provided in [Ref6], as a part of 76 promoting OSPF to Draft Standard status. The analysis of OSPF 77 remains unchanged. Two additional major features have been developed 78 for OSPF since the protocol achieved Draft Standard status: the 79 Point-to-MultiPoint interface and Cryptographic Authentication. 80 These features are described in Sections 2.1 and 2.2 respectively of 81 this memo. 83 The OSPF MIB is documented in [Ref4]. It is currently at Draft 84 Standard status. 86 2. Modifications since Draft Standard status 88 OSPF became a Draft Standard with the release of RFC 1583 [Ref3]. 89 Implementations of the new specification in [Ref8] are backward- 90 compatible with RFC 1583. The differences between the two documents 91 are described in the Appendix Gs of [Ref1] and [Ref8]. These 92 differences are listed briefly below. Two major features were also 93 added, the Point-to-MultiPoint interface and Cryptographic 94 Authentication, which are described in separate sections. 96 o Configuration requirements for OSPF area address ranges have 97 been relaxed to allow greater flexibility in area assignment. 98 See Section G.3 of [Ref1] for details. 100 o The OSPF flooding algorithm was modified to a) improve database 101 convergence in networks with low speed links b) resolve a 102 problem where unnecessary LSA retransmissions could occur as a 103 result of differing clock granularities, c) remove race 104 conditions between the flooding of MaxAge LSAs and the Database 105 Exchange process, d) clarify the use of the MinLSArrival 106 constant, and e) rate-limit the response to less recent LSAs 107 received via flooding. See Sections G.4 and G.5 of [Ref1] and 108 Section G.1 of [Ref8] for details. 110 o To resolve the long-standing confusion regarding representation 111 of point-to-point links in OSPF, the specification now 112 optionally allows advertisement of a stub link to a point-to- 113 point link's subnet, ala RIP. See Section G.6 of [Ref1]. 115 o Several problems involving advertising the same external route 116 from multiple areas were found and fixed, as described in 117 Section G.7 of [Ref1] and Section G.2 of [Ref8]. Without the 118 fixes, persistent routing loops could form in certain such 119 configurations. Note that one of the fixes was not backward- 120 compatible, in that mixing routers implementing the fixes with 121 those implementing just RFC 1583 could cause loops not present 122 in an RFC 1583-only configuration. This caused an 123 RFC1583Compatibility global configuration parameter to be added, 124 as described in Section C.1 of [Ref1]. 126 o In order to deal with high delay links, retransmissions of 127 initial Database Description packets no longer reset an OSPF 128 adjacency. 130 o In order to detect link MTU mismatches, which can cause problems 131 both in IP forwarding and in the OSPF routing protocol itself, 132 MTU was added to OSPF's Database Description packets. 133 Neighboring routers refuse to bring up an OSPF adjacency unless 134 they agree on their common link's MTU. 136 o The TOS routing option was deleted from OSPF. However, for 137 backward compatibility the formats of OSPF's various LSAs remain 138 unchanged, maintaining the ability to specify TOS metrics in 139 router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external- 140 LSAs. 142 o OSPF's routing table lookup algorithm was changed to reflect 143 current practice. The "best match" routing table entry is now 144 always selected to be the one providing the most specific 145 (longest) match. See Section G.4 of [Ref8] for details. 147 2.1. Point-to-MultiPoint interface 149 The Point-to-MultiPoint interface was added as an alternative to 150 OSPF's NBMA interface when running OSPF over non-broadcast 151 subnets. Unlike the NBMA interface, Point-to-MultiPoint does not 152 require full mesh connectivity over the non-broadcast subnet. 153 Point-to-MultiPoint is less efficient than NBMA, but is easier 154 to configure (in fact, it can be self-configuring) and is more 155 robust than NBMA, tolerating all failures within the non- 156 broadcast subnet. For more information on the Point-to- 157 MultiPoint interface, see Section G.2 of [Ref1]. 159 There are at least six independent implementations of the 160 Point-to-MultiPoint interface. Interoperability has been 161 demonstrated between at least two pairs of implementations: 162 between 3com and Bay Networks, and between cisco and Cascade. 164 2.2. Cryptographic Authentication 166 Non-trivial authentication was added to OSPF with the 167 development of the Cryptographic Authentication type. This 168 authentication type uses any keyed message digest algorithm, 169 with explicit instructions included for the use of MD5. For more 170 information on OSPF authentication, see Section 4. 172 There are at least three independent implementations of the OSPF 173 Cryptographic authentication type. Interoperability has been 174 demonstrated between the implementations from cisco and Cascade. 176 3. Updated implementation and deployment experience 178 When OSPF was promoted to Draft Standard Status, a report was issued 179 documenting current implementation and deployment experience (see 180 [Ref6]). That report is now quite dated. In an attempt to get more 181 current data, a questionnaire was sent to OSPF mailing list in 182 January 1996. Twelve responses were received, from 11 router vendors 183 and 1 manufacturer of test equipment. These responses represented 6 184 independent implementations. A tabulation of the results are 185 presented below. 187 Table 1 indicates the implementation, interoperability and 188 deployment of the major OSPF functions. The number in each column 189 represents the number of responses in the affirmative. 191 Imple- Inter- 192 Feature mented operated Deployed 193 _______________________________________________________ 194 OSPF areas 10 10 10 195 Stub areas 10 10 9 196 Virtual links 10 9 8 197 Equal-cost multipath 10 7 8 198 NBMA support 9 8 7 199 CIDR addressing 8 5 6 200 OSPF MIB 8 5 5 201 Cryptographic auth. 3 1 1 202 Point-to-Multipoint ifc. 6 3 4 204 Table 1: Implementation of OSPF features 206 Table 2 indicates the size of the OSPF routing domains that vendors 207 have tested. For each size parameter, the number of responders and 208 the range of responses (minimum, mode, mean and maximum) are listed. 210 Parameter Responses Min Mode Mean Max 211 _________________________________________________________________ 212 Max routers in domain 7 30 240 460 1600 213 Max routers in single area 7 20 240 380 1600 214 Max areas in domain 7 1 10 16 60 215 Max AS-external-LSAs 9 50 10K 10K 30K 217 Table 2: OSPF domain sizes tested 219 Table 3 indicates the size of the OSPF routing domains that vendors 220 have deployed in real networks. For each size parameter, the number 221 of responders and the range of responses (minimum, mode, mean and 222 maximum) are listed. 224 Parameter Responses Min Mode Mean Max 225 _________________________________________________________________ 226 Max routers in domain 8 20 350 510 1000 227 Max routers in single area 8 20 100 160 350 228 Max areas in domain 7 1 15 23 60 229 Max AS-external-LSAs 6 50 1K 2K 5K 231 Table 3: OSPF domain sizes deployed 233 In an attempt to ascertain the extent to which OSPF is currently 234 deployed, vendors were also asked in January 1998 to provide 235 deployment estimates. Four vendors of OSPF routers responded, with a 236 total estimate of 182,000 OSPF routers in service, organized into 237 4300 separate OSPF routing domains. 239 4. Protocol Security 241 All OSPF protocol exchanges are authenticated. OSPF supports 242 multiple types of authentication; the type of authentication in use 243 can be configured on a per network segment basis. One of OSPF's 244 authentication types, namely the Cryptographic authentication 245 option, is believed to be secure against passive attacks and provide 246 significant protection against active attacks. When using the 247 Cryptographic authentication option, each router appends a "message 248 digest" to its transmitted OSPF packets. Receivers then use the 249 shared secret key and received digest to verify that each received 250 OSPF packet is authentic. 252 The quality of the security provided by the Cryptographic 253 authentication option depends completely on the strength of the 254 message digest algorithm (MD5 is currently the only message digest 255 algorithm specified), the strength of the key being used, and the 256 correct implementation of the security mechanism in all 257 communicating OSPF implementations. It also requires that all 258 parties maintain the secrecy of the shared secret key. 260 None of the OSPF authentication types provide confidentiality. Nor 261 do they protect against traffic analysis. Key management is also not 262 addressed by the OSPF specification. 264 For more information, see Sections 8.1, 8.2, and Appendix D of 265 [Ref1]. 267 References 269 [Ref1] Moy, J., "OSPF Version 2", RFC 2178, July 1997. 271 [Ref2] Hinden, B., "Internet Routing Protocol Standardization 272 Criteria", RFC 1264, October 1991. 274 [Ref3] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 276 [Ref4] Baker, F,, and R. Coltun, "OSPF Version 2 Management 277 Information Base", RFC 1850, November 1995. 279 [Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991. 281 [Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246, 282 August 1991. 284 [Ref7] Varadhan, K., S. Hares and Y. Rekhter, "BGP4/IDRP for IP--- 285 OSPF Interaction", RFC 1745, December 1994. 287 [Ref8] Moy, J., "OSPF Version 2", Internet Draft, , January 1998. 290 Security Considerations 292 Security considerations are addressed in Section 4 of this memo. 294 Author's Address 296 John Moy 297 Ascend Communications, Inc. 298 1 Robbins Road 299 Westford, MA 01886 301 Phone: 978-952-1367 302 Fax: 978-392-2075 303 Email: jmoy@casc.com 305 This document expires in August 1998.