idnits 2.17.1 draft-ietf-ospf-lls-05.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. 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 IETF Trust Copyright Line does not match the current year -- 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 (April 20, 2008) is 5843 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 A. Roy 5 Expires: October 22, 2008 L. Nguyen 6 Cisco Systems 7 B. Friedman 8 Redback Networks 9 D. Young 10 Cisco Systems 11 April 20, 2008 13 OSPF Link-local Signaling 14 draft-ietf-ospf-lls-05.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 22, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 OSPF is a link-state intra-domain routing protocol. OSPF routers 48 exchange information on a link using packets that follow a well- 49 defined fixed format. The format is not flexible enough to enable 50 new features which need to exchange arbitrary data. This document 51 describes a backward-compatible technique to perform link-local 52 signaling, i.e., exchange arbitrary data on a link. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Options Field . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. Extended Options TLV . . . . . . . . . . . . . . . . . . . 6 63 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 7 64 2.6. Private and Experimental TLVs . . . . . . . . . . . . . . 8 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Introduction 77 This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3 78 [OSPFV3] allowing additional information to be exchanged between 79 routers on the same link. OSPFv2 and OSPFv3 packet formats are fixed 80 and do not allow for extension. This document proposes appending an 81 optional data block composed of Type/Length/Value (TLV) triplets to 82 existing OSPFv2 and OSPFv3 packets to carry this additional 83 information. Throughout this document, OSPF will be used when the 84 specification is applicable to both OSPFv2 and OSPFv3. Similarly, 85 OSPFv2 or OSPFv3 will be used when the text is protocol specific. 87 One potential way of solving this task could be introducing a new 88 packet type. However, that would mean introducing extra packets on 89 the network which may not be desirable and may cause backward 90 compatibility issues. This document describes how to exchange data 91 using standard OSPF packet types. 93 1.1. Requirements notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [KEY]. 99 2. Proposed solution 101 To perform link-local signaling (LLS), OSPF routers add a special 102 data block to the end of OSPF packets or right after the 103 authentication data block when cryptographic authentication is used. 104 The length of the LLS block is not included into the length of OSPF 105 packet, but is included in the IPv4/IPv6 packet length. Figure 1 106 illustrates how the LLS data block is attached. 108 +---------------------+ -- -- +---------------------+ 109 | IP Header | ^ ^ | IPv6 Header | 110 | Length = HL+X+Y+Z | | Header Length | | Length = HL+X+Y | 111 | | v v | | 112 +---------------------+ -- -- +---------------------+ 113 | OSPF Header | ^ ^ | OSPFv3 Header | 114 | Length = X | | | | Length = X | 115 |.....................| | X | X |.....................| 116 | | | | | | 117 | OSPFv2 Data | | | | OSPFv3 Data | 118 | | v v | | 119 +---------------------+ -- -- +---------------------+ 120 | | ^ ^ | | 121 | Authentication Data | | Y | Y | LLS Data | 122 | | v v | | 123 +---------------------+ -- -- +---------------------+ 124 | | ^ 125 | LLS Data | | Z 126 | | v 127 +---------------------+ -- 129 Figure 1: LLS Data Block in OSPFv2 and OSPFv3 131 The LLS data block MAY be attached to OSPF Hello and DD packets. The 132 data included in LLS block attached to a Hello packet MAY be used for 133 dynamic signaling since Hello packets may be sent at any time in 134 time. However, delivery of LLS data in Hello packets is not 135 guaranteed. The data sent with DD packets is guaranteed to be 136 delivered as part of the adjacency forming process. 138 This document does not specify how the data transmitted by the LLS 139 mechanism should be interpreted by OSPF routers. As routers that do 140 not understand LLS may receive these packets, changes made due to LLS 141 block TLV's do not affect the basic routing when interacting with 142 non-LLS routers. 144 2.1. Options Field 146 A new L bit (L stands for LLS) is introduced to OSPF Options field 147 (see Figure 2a/2b). Routers set the L bit in Hello and DD packets to 148 indicate that the packet contains LLS data block. In other words, 149 LLS data block is only examined if the L bit is set. 151 +---+---+---+---+---+---+---+---+ 152 | * | O | DC| L |N/P| MC| E | * | 153 +---+---+---+---+---+---+---+-+-+ 155 Figure 2a: OSPFv2 Options field 157 0 1 2 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+ 160 | | | | | | | | | | | | | | |L|AF|*|*|DC| R| N|MC| E|V6| 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+ 163 Figure 2b: OSPFv3 Options field 165 The L bit is only set in Hello and DD packets. 167 2.2. LLS Data Block 169 The data block used for link-local signaling is formatted as 170 described below (see Figure 3 for illustration). 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Checksum | LLS Data Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 | LLS TLVs | 179 . . 180 . . 181 . . 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 3: Format of LLS Data Block 186 The Checksum field contains the standard IP checksum for the entire 187 contents of the LLS block. 189 The 16-bit LLS Data Length field contains the length (in 32-bit 190 words) of the LLS block including the header and payload. 191 Implementations MUST NOT use the Length field in the IP packet header 192 to determine the length of the LLS data block. 194 Note that if the OSPF packet is cryptographically authenticated, the 195 LLS data block MUST also be cryptographically authenticated. In this 196 case, the regular LLS checksum is not calculated and the LLS block 197 will contain a cryptographic authentication TLV (see Section 2.5). 199 The rest of the block contains a set of Type/Length/Value (TLV) 200 triplets as described in Section 2.3. All TLVs MUST be 32-bit 201 aligned (with padding if necessary). 203 2.3. LLS TLVs 205 The contents of LLS data block is constructed using TLVs. See Figure 206 4 for the TLV format. 208 The type field contains the TLV ID which is unique for each type of 209 TLVs. The Length field contains the length of the Value field (in 210 bytes). The value field is variable and contains arbitrary data. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 . . 219 . Value . 220 . . 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 4: Format of LLS TLVs 225 Note that TLVs are always padded to 32-bit boundary, but padding 226 bytes are not included in TLV Length field (though they are included 227 in the LLS Data Length field in the LLS block header). Unrecognized 228 TLV types are ignored. 230 2.4. Extended Options TLV 232 This subsection describes a TLV called the Extended Options (EO) TLV. 233 The format of EO-TLV is shown in Figure 5. 235 Bits in the Value field do not have any semantics from the point of 236 view of the LLS mechanism. This field MAY be used to announce some 237 OSPF capabilities that are link-specific. Also, other OSPF 238 extensions MAY allocate bits in the bit vector to perform boolean 239 link-local signaling. 241 The length of the Value field in the EO-TLV is 4 bytes. 243 The value of the type field in the EO-TLV is 1. 245 The EO-TLV MUST only appear once in the LLS data block. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | 1 | 4 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Extended Options | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 5: Format of EO TLV 257 Currently, [OOB] and [RESTART] use bits in the Extended Options field 258 of the EO-TLV. 260 The Extended Options bits are defined in Section 3. 262 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) 264 This document defines a special TLV that is used for cryptographic 265 authentication (CA-TLV) of the LLS data block. This TLV MUST be 266 included in the LLS block when the cryptographic authentication is 267 enabled on the corresponding interface. The message digest of the 268 LLS block MUST be calculated using the same key and authentication 269 algorithm as used for the OSPFv2 packet. The cryptographic sequence 270 number is included in the TLV and MUST be the same as the one in the 271 OSPFv2 authentication data for the LLS block to be considered 272 authentic. 274 The TLV is constructed as shown in Figure 6. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | 2 | AuthLen | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Sequence number | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 . . 285 . AuthData . 286 . . 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 6: Format of Cryptographic Authentication TLV 291 The value of the Type field for the CA-TLV is 2. 293 The Length field in the header contains the length of the data 294 portion of the TLV including 4 bytes for Sequence Number and the 295 length of the message digest block for the whole LLS block in bytes. 297 The Sequence Number field contains the cryptographic sequence number 298 that is used to prevent simple replay attacks. For the LLS block to 299 be considered authentic, the Sequence Number in the CA-TLV MUST match 300 the Sequence Number in the OSPFv2 packet header Authentication field. 301 In the event of Sequence Number mismatch or Authentication failure, 302 the whole LLS block MUST be ignored. 304 The AuthData contains the message digest calculated for the LLS data 305 block. 307 The CA-TLV MUST only appear once in the the LLS block. Also, when 308 present, this TLV SHOULD be the last TLV in the LLS block. 310 2.6. Private and Experimental TLVs 312 LLS type values in the range of 32768-65536 are reserved for private 313 and experimental use. The first four octets of the Value field MUST 314 be the private enterprise code [ENTNUM]. This allows multiple vendor 315 private extensions to coexist in a network. 317 3. IANA Considerations 319 LLS TLV types are maintained by the IANA. Extensions to OSPF which 320 require a new LLS TLV type MUST be reviewed by an designated expert 321 from the routing area. 323 Following the policies outlined in [IANA], LLS type values in the 324 range of 0-32767 are allocated through an IETF Consensus action and 325 LLS type values in the range of 32768-65536 are reserved for private 326 and experimental use. 328 This document assigns the following LLS TLV types in OSPFv2/OSPFv3. 330 TLV Type Name Reference 331 0 Reserved 332 1 Extended Options [RFCNNNN]* 333 2 Cryptographic Authentication+ [RFCNNNN]* 334 3-32767 Reserved for assignment by the IANA 335 32768-65535 Private Use 337 *[RFCNNNN] refers to the RFC number-to-be for this document. 338 + Cryptographic Authentication TLV is only defined for OSPFv2 340 This document also assigns the following bits for the Extended 341 Options bits field in the EO-TLV outlined in Section 2.5: 343 Extended Options Bit Name Reference 344 0x00000001 LSDB Resynchronization (LR) [OOB] 345 0x00000002 Restart Signal (RS-bit) [RESTART] 347 Other Extended Options bits will be allocated through an IETF 348 consensus action. 350 4. Compatibility Issues 352 The modifications to OSPF packet formats are compatible with standard 353 OSPF since OSPF router not supporting LLS will ignore the LLS data 354 block after the OSPF packet or cryptographic message digest. 356 5. Security Considerations 358 The described technique provides the same level of security as OSPFv2 359 protocol by allowing LLS data to be authenticated using the same 360 cryptographic authentication that OSPFv2 uses (see Section 2.5 for 361 more details). 363 OSPFv3 utilizes IPSec for authentication and encryption [OSPFV3AUTH]. 364 With IPsec, the AH (Authentication Header), ESP (Encapsulating 365 Security Payload), or both are applied to the entire OSPFv3 payload 366 including the LLS block. 368 6. References 370 6.1. Normative References 372 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 373 IANA Considerations Section in RFCs", RFC 2334, 374 October 1998. 376 [KEY] Bradner, S., "Key words for use in RFC's to Indicate 377 Requirement Levels", RFC 2119, March 1997. 379 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 381 [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 382 RFC 2740, December 1999. 384 [OSPFV3AUTH] 385 Gupta, M. and N. Melam, "Authentication/Confidentiality 386 for OSPFv3", RFC 4552, June 2006. 388 6.2. Informative References 390 [ENTNUM] IANA, 391 "http://www.iana.org/assignments/enterprise-numbers". 393 [OOB] Zinin, A., Roy, A., and L. Nguyen, "OSPF Out-of-band LSDB 394 resynchronization", RFC 4811, March 2007. 396 [RESTART] Zinin, A., Roy, A., and L. Nguyen, "OSPF Restart 397 Signaling", RFC 4812, March 2007. 399 Appendix A. Acknowledgements 401 The authors would like to acknowledge Russ White, Acee Lindem and 402 Manral Vishwas for their review of this document. 404 Authors' Addresses 406 Alex Zinin 407 Alcatel 408 Sunnyvale 409 USA 411 Email: zinin@psg.com 413 Abhay Roy 414 Cisco Systems 415 170 West Tasman Drive 416 San Jose, CA 95134 417 USA 419 Email: akr@cisco.com 421 Liem Nguyen 422 Cisco Systems 423 170 West Tasman Drive 424 San Jose, CA 95134 425 USA 427 Email: lhnguyen@cisco.com 429 Barry Friedman 430 Redback Networks 431 100 Headquarters Drive 432 San Jose, CA 95134 433 USA 435 Email: friedman@redback.com 437 Derek Young 438 Cisco Systems 439 170 West Tasman Drive 440 San Jose, CA 95134 441 USA 443 Email: myeung@cisco.com 445 Full Copyright Statement 447 Copyright (C) The IETF Trust (2008). 449 This document is subject to the rights, licenses and restrictions 450 contained in BCP 78, and except as set forth therein, the authors 451 retain all their rights. 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 456 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 457 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 458 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Intellectual Property 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Acknowledgment 487 Funding for the RFC Editor function is provided by the IETF 488 Administrative Support Activity (IASA).