idnits 2.17.1 draft-ietf-ospf-lls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 9, 2007) is 6317 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) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Zinin 3 Internet-Draft Alcatel 4 Intended status: Standards Track B. Friedman 5 Expires: July 13, 2007 A. Roy 6 L. Nguyen 7 D. Young 8 Cisco Systems 9 January 9, 2007 11 OSPF Link-local Signaling 12 draft-ietf-ospf-lls-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 13, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2007). 43 Abstract 45 OSPF is a link-state intra-domain routing protocol. OSPF routers 46 exchange information on a link using packets that follow a well- 47 defined fixed format. The format is not flexible enough to enable 48 new features which need to exchange arbitrary data. This memo 49 describes a backward-compatible technique to perform link-local 50 signaling, i.e., exchange arbitrary data on a link. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 56 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Options Field . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Extended Options TLV . . . . . . . . . . . . . . . . . . . 6 61 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 7 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 10 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3 75 [OSPFV3] allowing additional information to be exchanged between 76 routers on the same link. OSPFv2 and OSPFv3 packet formats are fixed 77 and do not allow for extension. This document proposes appending an 78 optional data block composed of Type/Length/Value (TLV) triplets to 79 existing OSPFv2 and OSPFv3 packets to carry this additional 80 information. Throughout this document, OSPF will be used when the 81 specification is applicable to both OSPFv2 and OSPFv3. Similarly, 82 OSPFv2 or OSPFv3 will be used when the text is protocol specific. 84 One potential way of solving this task could be introducing a new 85 packet type. However, that would mean introducing extra packets on 86 the network which may not be desirable and may cause backward 87 compatibility issues. This document describes how to exchange data 88 using standard OSPF packet types. 90 1.1. Conventions Used In This Document 92 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 93 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 94 and "OPTIONAL" are to be interpreted as described in RFC2119 [KEY]. 96 2. Proposed solution 98 To perform link-local signaling (LLS), OSPF routers add a special 99 data block at the end of OSPF packets or right after the 100 authentication data block when cryptographic authentication is used. 101 The length of the LLS block is not included into the length of OSPF 102 packet, but is included in the IPv4/IPv6 packet length. Figure 1 103 illustrates how the LLS data block is attached. 105 +---------------------+ -- -- +---------------------+ 106 | IP Header | ^ ^ | IPv6 Header | 107 | Length = HL+X+Y+Z | | Header Length | | Length = HL+X+Y | 108 | | v v | | 109 +---------------------+ -- -- +---------------------+ 110 | OSPF Header | ^ ^ | OSPFv3 Header | 111 | Length = X | | | | Length = X | 112 |.....................| | X | X |.....................| 113 | | | | | | 114 | OSPFv2 Data | | | | OSPFv3 Data | 115 | | v v | | 116 +---------------------+ -- -- +---------------------+ 117 | | ^ ^ | | 118 | Authentication Data | | Y | Y | LLS Data | 119 | | v v | | 120 +---------------------+ -- -- +---------------------+ 121 | | ^ 122 | LLS Data | | Z 123 | | v 124 +---------------------+ -- 126 Figure 1: LLS Data Block in OSPFv2 and OSPFv3 128 The LLS data block MAY be attached to OSPF hello and DD packets. The 129 data included in LLS block attached to a Hello packet MAY be used for 130 dynamic signaling, since Hello packets may be sent at any moment in 131 time. However, delivery of LLS data in Hello packets is not 132 guaranteed. The data sent with DBD packets is guaranteed to be 133 delivered as part of the adjacency forming process. 135 This memo does not specify how the data transmitted by the LLS 136 mechanism should be interpreted by OSPF routers. The interface 137 between OSPF LLS component and its clients is implementation 138 specific. 140 2.1. Options Field 142 A new bit, called L (L stands for LLS) is introduced to OSPF Options 143 field (see Figure 2a/2b). Routers set L bit in Hello and DBD packets 144 to indicate that the packet contains LLS data block. In other words, 145 LLS data block is only examined if L bit is set. 147 +---+---+---+---+---+---+---+---+ 148 | * | O | DC| L |N/P| MC| E | * | 149 +---+---+---+---+---+---+---+-+-+ 151 Figure 2a: OSPFv2 Options field 153 0 1 2 154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+ 156 | | | | | | | | | | | | | | |L|AF|*|*|DC| R| N|MC| E|V6| 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+ 159 Figure 2b: OSPFv3 Options field 161 The L-bit is only set in Hello and DBD packets. 163 2.2. LLS Data Block 165 The data block used for link-local signaling is formatted as 166 described below (see Figure 3 for illustration). 168 0 1 2 3 169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Checksum | LLS Data Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 | LLS TLVs | 175 . . 176 . . 177 . . 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 3: Format of LLS Data Block 182 The Checksum field contains the standard IP checksum of the entire 183 contents of the LLS block. 185 The 16-bit LLS Data Length field contains the length (in 32-bit 186 words) of the LLS block including the header and payload. 187 Implementations MUST NOT use the Length field in the IP packet header 188 to determine the length of the LLS data block. 190 Note that if the OSPF packet is cryptographically authenticated, the 191 LLS data block MUST also be cryptographically authenticated. In this 192 case the regular LLS checksum is not calculated and the LLS block 193 will contain a cryptographic authentication TLV (see Section 2.5). 195 The rest of the block contains a set of Type/Length/Value (TLV) 196 triplets as described in Section 2.3. All TLVs MUST be 32-bit 197 aligned (with padding if necessary). 199 2.3. LLS TLVs 201 The contents of LLS data block is constructed using TLVs. See Figure 202 4 for the TLV format. 204 The type field contains the TLV ID which is unique for each type of 205 TLVs. The Length field contains the length of the Value field (in 206 bytes) that is variable and contains arbitrary data. 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | | 214 . . 215 . Value . 216 . . 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 4: Format of LLS TLVs 221 Note that TLVs are always padded to 32-bit boundary, but padding 222 bytes are not included in TLV Length field (though it is included in 223 the LLS Data Length field of the LLS block header). 225 2.4. Extended Options TLV 227 This subsection describes a TLV called Extended Options (EO) TLV. 228 The format of EO-TLV is shown in Figure 5. 230 Bits in the Value field do not have any semantics from the point of 231 view of LLS mechanism. This field MAY be used to announce some OSPF 232 capabilities that are link-specific. Also, other OSPF extensions MAY 233 allocate bits in the bit vector to perform boolean link-local 234 signaling. 236 The length of the Value field in EO-TLV is 4 bytes. 238 The value of the type field in EO-TLV is 1. 240 EO-TLV MUST only appear once in the LLS data block. 242 0 1 2 3 243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | 1 | 4 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Extended Options | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 5: Format of EO TLV 252 Currently, [OOB] and [RESTART] use bits in the Extended Options field 253 of the EO-TLV. 255 The Extended Options bits are defined in Section 3. 257 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) 259 This document defines a special TLV that is used for cryptographic 260 authentication (CA-TLV) of the LLS data block. This TLV MUST be 261 included in the LLS block when the cryptographic (MD5) authentication 262 is enabled on the corresponding interface. The message digest of the 263 LLS block MUST be calculated using the same key and authentication 264 algorithm, as that used for the main OSPFv2 packet. The 265 cryptographic sequence number is included in the TLV and MUST be the 266 same as the one in the main OSPFv2 packet for the LLS block to be 267 considered authentic. 269 The TLV is constructed as shown Figure 6. 271 0 1 2 3 272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | 2 | AuthLen | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Sequence number | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 . . 280 . AuthData . 281 . . 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 6: Format of Cryptographic Authentication TLV 286 The value of the Type field for CA-TLV is 2. 288 The Length field in the header contains the length of the data 289 portion of the TLV that includes 4 bytes for the Sequence Number and 290 the length of the message digest (MD5) block for the whole LLS block 291 in bytes (this will always be 16 bytes for MD5). So AuthLen field 292 will have value of 20. 294 The Sequence Number field contains the cryptographic sequence number 295 that is used to prevent simple replay attacks. For the LLS block to 296 be considered authentic, the Sequence Number in the CA-TLV MUST match 297 the Sequence Number in the OSPFv2 packet. 299 The AuthData contains the message digest calculated for the LLS data 300 block. 302 The CA-TLV MUST only appear once in the the LLS block. Also, when 303 present, this TLV SHOULD be the last TLV in the LLS block. 305 3. IANA Considerations 307 LLS TLV types are maintained by the IANA. Extensions to OSPF which 308 require a new LLS TLV type MUST be reviewed by an designated expert 309 from the routing area. 311 Following the policies outlined in [IANA], LLS type values in the 312 range of 0-32767 are allocated through an IETF Consensus action and 313 LLS type values in the range of 32768-65536 are reserved for private 314 and experimental use. 316 This document assigns the following LLS TLV types in OSPFv2/OSPFv3. 318 TLV Type Name Reference 319 0 Reserved 320 1 Extended Options [RFCNNNN]* 321 2 Cryptographic Authentication+ [RFCNNNN]* 322 3-32767 Reserved for assignment by the IANA 323 32768-65535 Private Use 325 *[RFCNNNN] refers to the RFC number-to-be for this document. 326 + Cryptographic Authentication TLV is only defined for OSPFv2 328 This document also assigns the following bits for the Extended 329 Options bits field in the EO-TLV outlined in Section 2.5: 331 Extended Options Bit Name Reference 332 0x00000001 LSDB Resynchronization (LR) [OOB] 333 0x00000002 Restart Signal (RS-bit) [RESTART] 335 Other Extended Options bits will be allocated through an IETF 336 consensus action. 338 4. Compatibility Issues 340 The modifications to OSPF packet formats are compatible with standard 341 OSPF because LLS-incapable routers will not consider the extra data 342 after the packet; i.e., the LLS data block will be ignored by routers 343 which do not support the LLS extension. 345 5. Security Considerations 347 The described technique provides the same level of security as OSPF 348 protocol by allowing LLS data to be authenticated (see Section 2.5 349 for more details). 351 OSPFv3 has IPSec authentication built in. There are AH/ESP 352 techniques which operate on the whole OSPFv3 payload. So we do not 353 need a separate cryptographic TLV for OSPFv3. 355 6. References 357 6.1. Normative References 359 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 360 IANA Considerations Section in RFCs", RFC 2334, 361 October 1998. 363 [KEY] Bradner, S., "Key words for use in RFC's to Indicate 364 Requirement Levels", RFC 2119, March 1997. 366 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 368 [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 369 RFC 2740, December 1999. 371 6.2. Informative References 373 [OOB] Zinin, A., Roy, A., and L. Nguyen, "OSPF Out-of-band LSDB 374 resynchronization", draft-nguyen-ospf-oob-resync-06.txt 375 (work in progress), October 2006. 377 [RESTART] Zinin, A., Roy, A., and L. Nguyen, "OSPF Restart 378 Signaling", draft-nguyen-ospf-restart-06.txt (work in 379 progress), October 2006. 381 Appendix A. Acknowledgements 383 The authors would like to acknowledge Russ White and Acee Lindem for 384 their thoughtful review of this document. 386 Authors' Addresses 388 Alex Zinin 389 Alcatel 390 Sunnyvale 391 USA 393 Email: zinin@psg.com 395 Barry Friedman 396 Cisco Systems 397 170 West Tasman Drive 398 San Jose, CA 95134 399 USA 401 Email: friedman@cisco.com 403 Abhay Roy 404 Cisco Systems 405 170 West Tasman Drive 406 San Jose, CA 95134 407 USA 409 Email: akr@cisco.com 411 Liem Nguyen 412 Cisco Systems 413 170 West Tasman Drive 414 San Jose, CA 95134 415 USA 417 Email: lhnguyen@cisco.com 419 Derek Young 420 Cisco Systems 421 170 West Tasman Drive 422 San Jose, CA 95134 423 USA 425 Email: myeung@cisco.com 427 Full Copyright Statement 429 Copyright (C) The Internet Society (2007). 431 This document is subject to the rights, licenses and restrictions 432 contained in BCP 78, and except as set forth therein, the authors 433 retain all their rights. 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 438 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 439 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 440 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 Intellectual Property 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org. 467 Acknowledgment 469 Funding for the RFC Editor function is provided by the IETF 470 Administrative Support Activity (IASA).