idnits 2.17.1 draft-nguyen-ospf-lls-06.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 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 452. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 26, 2006) is 6354 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) 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 B. Friedman 3 Internet-Draft L. Nguyen 4 Intended status: Experimental A. Roy 5 Expires: April 29, 2007 D. Yeung 6 Cisco Systems 7 A. Zinin 8 Alcatel 9 October 26, 2006 11 OSPF Link-local Signaling 12 draft-nguyen-ospf-lls-06.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 April 29, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 OSPF is a link-state intra-domain routing protocol used in IP 46 networks. OSPF routers exchange information on a link using packets 47 that follow a well-defined format. The format of OSPF packets is not 48 flexible enough to enable applications exchange arbitrary data, which 49 may be necessary in certain situations. This memo describes a vendor 50 specific, backward-compatible technique to perform link-local 51 signaling, i.e., exchange arbitrary data on a link. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Options Field . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.4. Predefined TLV . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4.1. Extended Options TLV . . . . . . . . . . . . . . . . . 6 63 2.4.2. Cryptographic Authentication TLV . . . . . . . . . . . 7 64 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 74 1. Introduction 76 Formats of OSPF [RFC2328] packets are not very flexible to provide an 77 acceptable mechanism for opaque data transfer. However, this appears 78 to be very useful to allow OSPF routers to do so. An example where 79 such a technique could be used is exchanging some capabilities on a 80 link (standard OSPF utilizes Options field in Hello and Exchange 81 packets, but there are not so many bits left in it). 83 One potential way of solving this task could be introducing a new 84 packet type. However, that would mean introducing extra packets on 85 the network which may not be desirable, so this document describes 86 how to exchange data using existing, standard OSPF packet types. 88 1.1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC2119 [RFC2119]. 94 2. Proposed Solution 96 To perform link-local signaling (LLS), OSPF routers add a special 97 data block at the end of OSPF packets or right after the 98 authentication data block when cryptographic authentication is used. 99 Like with OSPF cryptographic authentication, the length of the LLS- 100 block is not included into the length of OSPF packet, but is included 101 in the IP packet length. Figure 1 illustrates how the LLS data block 102 is attached. 104 +---------------------+ -- 105 | IP Header | ^ 106 | Length = HL+X+Y+Z | | Header Length 107 | | v 108 +---------------------+ -- 109 | OSPF Header | ^ 110 | Length = X | | 111 |.....................| | X 112 | | | 113 | OSPF Data | | 114 | | v 115 +---------------------+ -- 116 | | ^ 117 | Authentication Data | | Y 118 | | v 119 +---------------------+ -- 120 | | ^ 121 | LLS Data | | Z 122 | | v 123 +---------------------+ -- 125 Figure 1: Attaching LLS Data Block 127 The LLS data block may be attached to OSPF packets of two types--- 128 type 1 (OSPF Hello), and type-2 (OSPF DBD). The data included in LLS 129 block attached to a Hello packet may be used for dynamic signaling, 130 since Hello packets may be sent at any moment in time. However, 131 delivery of LLS data in Hello packets is not guaranteed. The data 132 sent with DBD packets is guaranteed to be delivered as part of the 133 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 2). The value of the bit is 0x10. Routers set L 144 bit in Hello and DBD packets to indicate that the packet contains LLS 145 data block. 147 +---+---+---+---+---+---+---+---+ 148 | * | O | DC| L |N/P| MC| E | * | 149 +---+---+---+---+---+---+---+-+-+ 151 Figure 2: The Options field 153 L-bit 154 This bit is set only in Hello and DBD packets. It is not set in 155 OSPF LSAs and may be used in them for different purposes. 157 2.2. LLS Data Block 159 The data block used for link-local signaling is formatted as 160 described below (see Figure 3 for illustration). 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Checksum | LLS Data Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 | LLS TLVs | 169 . . 170 . . 171 . . 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 3: Format of LLS Data Block 176 Checksum 177 The Checksum field contains the standard IP checksum of the entire 178 contents of the LLS block. 180 LLS Length 181 The 16-bit LLS Data Length field contains the length (in 32-bit 182 words) of the LLS block including the header and payload. 183 Implementations should not use the Length field in the IP packet 184 header to determine the length of the LLS data block. 186 Note that if the OSPF packet is cryptographically authenticated, the 187 LLS data block must also be cryptographically authenticated. In this 188 case the regular LLS checksum is not calculated and the LLS block 189 will contain a cryptographic authentication TLV (see Section 2.4.2). 191 The rest of the block contains a set of Type/Length/Value (TLV) 192 triplets as described in Section 2.3. All TLVs must be 32-bit 193 aligned (with padding if necessary). 195 2.3. LLS TLVs 197 The contents of LLS data block is constructed using TLVs. See Figure 198 4 for the TLV format. 200 The type field contains the TLV ID which is unique for each type of 201 TLVs. The Length field contains the length of the Value field (in 202 bytes) that is variable and contains arbitrary data. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 . . 211 . Value . 212 . . 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 4: Format of LLS TLVs 217 Note that TLVs are always padded to 32-bit boundary, but padding 218 bytes are not included in TLV Length field (though it is included in 219 the LLS Data Length field of the LLS block header). 221 2.4. Predefined TLV 223 2.4.1. Extended Options TLV 225 This subsection describes a TLV called Extended Options (EO) TLV. 226 The format of EO-TLV is shown in Figure 5. 228 Bits in the Value field do not have any semantics from the point of 229 view of LLS mechanism. This field may be used to announce some OSPF 230 capabilities that are link-specific. Also, other OSPF extensions may 231 allocate bits in the bit vector to perform boolean link-local 232 signaling. 234 The length of the Value field in EO-TLV is 4 bytes. 236 The value of the type field in EO-TLV is 1. 238 EO-TLV should only appear once in the LLS data block. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | 1 | Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Extended Options | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 5: Format of EO TLV 250 Currently, [OOB] and [RESTART] use bits in the Extended Options field 251 of the EO-TLV. The Extended Options bits are also defined in Section 252 5. 254 2.4.2. Cryptographic Authentication TLV 256 This document defines a special TLV that is used for cryptographic 257 authentication (CA-TLV) of the LLS data block. This TLV should be 258 included in the LLS block when the cryptographic (MD5) authentication 259 is enabled on the corresponding interface. The message digest of the 260 LLS block should be calculated using the same key as that used for 261 the main OSPF packet. The cryptographic sequence number is included 262 in the TLV and must be the same as the one in the main OSPF packet 263 for the LLS block to be considered authentic. 265 The TLV is constructed as shown Figure 6. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | 2 | AuthLen | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Sequence number | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 . . 276 . AuthData . 277 . . 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 6: Format of Cryptographic Authentication TLV 282 The value of the Type field for CA-TLV is 2. 284 The Length field in the header contains the length of the data 285 portion of the TLV that includes 4 bytes for the Sequence Number and 286 the length of the message digest (MD5) block for the whole LLS block 287 in bytes (this will always be 16 bytes for MD5). So AuthLen field 288 will have value of 20. 290 The Sequence Number field contains the cryptographic sequence number 291 that is used to prevent simple replay attacks. For the LLS block to 292 be considered authentic, the Sequence Number in the CA-TLV must match 293 the Sequence Number in the OSPF packet. 295 The AuthData contains the message digest calculated for the LLS data 296 block. 298 The CA-TLV may appear in the LLS block only once. Also, when 299 present, this TLV should be the last in the LLS block. 301 3. Backward Compatibility 303 The modifications to OSPF packet formats are compatible with standard 304 OSPF because LLS-incapable routers will not consider the extra data 305 after the packet; i.e., the LLS data block will be ignored by routers 306 which do not support the LLS extension. 308 4. Security Considerations 310 The function described in this document does not create any new 311 security issues for the OSPF protocol. The described technique 312 provides the same level of security as OSPF protocol by allowing LLS 313 data to be authenticated (see Section 2.4.2 for more details). 315 5. IANA Considerations 317 LLS TLV types are maintained by the IANA. Extensions to OSPF which 318 require a new LLS TLV type must be reviewed by an designated expert 319 from the routing area. 321 Following the policies outlined in [RFC2434], LLS type values in the 322 range of 0-32767 are allocated through an IETF Consensus action and 323 LLS type values in the range of 32768-65536 are reserved for private 324 and experimental use. 326 This document assigns LLS types 1 and 2, as follows: 328 LLS Type Name Reference 329 0 Reserved 330 1 Extended Options [RFCNNNN]* 331 2 Cryptographic Authentication [RFCNNNN]* 332 3-32767 Reserved for assignment by the IANA 333 32768-65535 Private Use 335 *[RFCNNNN] refers to the RFC number-to-be for this document. 337 This document also assigns the following bits for the Extended 338 Options bits field in the EO-TLV outlined in Section 2.4.1: 340 Extended Options Bit Name Reference 341 0x00000001 LSDB Resynchronization (LR) [OOB] 342 0x00000002 Restart Signal (RS-bit) [RESTART] 344 Other Extended Options bits will be allocated through an IETF 345 consensus action. 347 6. References 349 6.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 352 Requirement Levels", RFC 2119, March 1997. 354 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 356 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 357 IANA Considerations Section in RFCs", RFC 2434, 358 October 1998. 360 6.2. Informative References 362 [OOB] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-band LSDB 363 resynchronization", Work in progress , October 2006. 365 [RESTART] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart 366 Signaling", Work in progress , October 2006. 368 Appendix A. Acknowledgments 370 The authors would like to acknowledge Russ White for his review of 371 this document. 373 Authors' Addresses 375 Barry Friedman 376 Cisco Systems 377 225 West Tasman Drive 378 San Jose, CA 95134 379 USA 381 Email: friedman@cisco.com 383 Liem Nguyen 384 Cisco Systems 385 225 West Tasman Drive 386 San Jose, CA 95134 387 USA 389 Email: lhnguyen@cisco.com 391 Abhay Roy 392 Cisco Systems 393 225 West Tasman Drive 394 San Jose, CA 95134 395 USA 397 Email: akr@cisco.com 399 Derek Yeung 400 Cisco Systems 401 225 West Tasman Drive 402 San Jose, CA 95134 403 USA 405 Email: myeung@cisco.com 407 Alex Zinin 408 Alcatel 409 Sunnyvale, CA 410 USA 412 Email: zinin@psg.com 414 Full Copyright Statement 416 Copyright (C) The Internet Society (2006). 418 This document is subject to the rights, licenses and restrictions 419 contained in BCP 78, and except as set forth therein, the authors 420 retain all their rights. 422 This document and the information contained herein are provided on an 423 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 424 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 425 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 426 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 427 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 428 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 430 Intellectual Property 432 The IETF takes no position regarding the validity or scope of any 433 Intellectual Property Rights or other rights that might be claimed to 434 pertain to the implementation or use of the technology described in 435 this document or the extent to which any license under such rights 436 might or might not be available; nor does it represent that it has 437 made any independent effort to identify any such rights. Information 438 on the procedures with respect to rights in RFC documents can be 439 found in BCP 78 and BCP 79. 441 Copies of IPR disclosures made to the IETF Secretariat and any 442 assurances of licenses to be made available, or the result of an 443 attempt made to obtain a general license or permission for the use of 444 such proprietary rights by implementers or users of this 445 specification can be obtained from the IETF on-line IPR repository at 446 http://www.ietf.org/ipr. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights that may cover technology that may be required to implement 451 this standard. Please address the information to the IETF at 452 ietf-ipr@ietf.org. 454 Acknowledgment 456 Funding for the RFC Editor function is provided by the IETF 457 Administrative Support Activity (IASA).