idnits 2.17.1 draft-ietf-ospf-lls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (November 2000) is 8562 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) == Missing Reference: 'IANA' is mentioned on line 264, but not defined Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alex Zinin (Cisco Systems) 3 Internet Draft Barry Friedman (Cisco Systems) 4 Expiration Date: July 2001 Abhay Roy (Cisco Systems) 5 File name: draft-ietf-ospf-lls-00.txt Liem Nguyen (Cisco Systems) 6 Derek Yeung (Procket) 7 November 2000 9 OSPF Link-local Signaling 10 draft-ietf-ospf-lls-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that other 19 groups may also distribute working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 34 OSPF is a link-state intra-domain routing protocol used in IP 35 networks. OSPF routers exchange information on a link using packets 36 that follow a well-defined format. The format of OSPF packets is not 37 flexible enough to enable applications exchange arbitrary data, which 38 may be necessary in certain situations. This memo describes a 39 backward-compatible technique to perform link-local signaling, i.e., 40 exchange arbitrary data on a link. 42 1 Motivation 44 Formats of OSPF [RFC2328] packets are not very flexible to provide an 45 acceptable mechanism for opaque data transfer. However, this appears 46 to be very useful to allow OSPF routers to do so. An example where 47 such a technique could be used is exchanging some capabilities on a 48 link (standard OSPF utilizes Options field in Hello and Exchange 49 packets, but there are not so many bits left in it). 51 One potential way of solving this task could be introducing a new 52 packet type. However, in some situations it may not be desirable, so 53 this document describes how to exchange data using standard OSPF 54 packet types. 56 2 Proposed solution 58 To perform link-local signaling (LLS), OSPF routers add a special 59 data block at the end of OSPF packets or right after the 60 authentication data block when cryptographic authentication is used. 61 Like with OSPF cryptographic authentication, the length of the LLS- 62 block is not included into the length of OSPF packet, but is included 63 in the IP packet length. Figure 1 illustrates how the LLS data block 64 is attached. 66 +---------------------+ -- 67 | IP Header | ^ 68 | Length = HL+X+Y+Z | | Header Length 69 | | v 70 +---------------------+ -- 71 | OSPF Header | ^ 72 | Length = X | | 73 |.....................| | X 74 | | | 75 | OSPF Data | | 76 | | v 77 +---------------------+ -- 78 | | ^ 79 | Authentication Data | | Y 80 | | v 81 +---------------------+ -- 82 | | ^ 83 | LLS Data | | Z 84 | | v 85 +---------------------+ -- 87 Figure 1: Attaching LLS Data Block 89 The LLS data block may be attached to OSPF packets of two types--- 90 type 1 (OSPF Hello), and type-2 (OSPF DBD). Note that only the 91 initial DBD packet (with the I bit set) may carry the LLS block. The 92 data included in LLS block attached to a Hello packet may be used for 93 dynamic signaling, since Hello packets may be sent at any moment in 94 time. However, delivery of LLS data in Hello packets is not 95 guaranteed. The data sent with an initial DBD packets is guaranteed 96 to be delivered as soon as the adjacency proceeds from ExStart state, 97 but this info may not change dynamically, since sending of an initial 98 DBD packet will bring the adjacency to ExStart state. 100 This memo does not specify how the data transmitted by LLS mechanism 101 should be interpreted by OSPF routers. The interface between OSPF LLS 102 component and its clients is implementation-specific. 104 2.1 Options Field 106 A new bit, called L (L stands for LLS) is introduced to OSPF Options 107 field (see Figure 2). The value of the bit is 0x10. Routers set L 108 bit in Hellow and DBD packets to indicate that the packet contains 109 LLS data block. 111 +---+---+---+---+---+---+---+---+ 112 | * | O | DC| L |N/P| MC| E | * | 113 +---+---+---+---+---+---+---+-+-+ 115 Figure 2: The Options field 117 The L-bit is set only in Hello and DBD packets. It is not set in OSPF 118 LSAs and may be used in them for different purposes. 120 2.2 LLS Data Block 122 The data block used for link-local signaling is formatted as 123 described below (see Figure 3 for illustration). 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Checksum | LLS Data Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 | LLS TLVs | 132 . . 133 . . 134 . . 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 3: Format of LLS Data Block 138 The Checksum field contains the standard IP checksum of the entire 139 contents of the LLS block. 141 The 16-bit LLS Data Length field contains the length (in 32-bit 142 words) of the LLS block including the header and payload. 144 Implementations should not use the Length field in the IP packet 145 header to determine the length of the LLS data block. 147 Note that if the OSPF packet is cryptographically authenticated, the 148 LLS data block must also be cryptographically authenticated. In this 149 case the regular checksum is not calculated and the LLS block will 150 contain a cryptographic authentication TLV (see Section 2.4.2). 152 The rest of the block contains a set of Type/Length/Value (TLV) 153 triplets as described in Section 2.2. All TLVs must be 32-bit 154 aligned (with padding if necessary). 156 2.3 LLS TLVs 158 The contents of LLS data block is constructed using TLVs. See Figure 159 4 for TLV format. 161 The type field contains the TLV ID which is unique for each type of 162 TLVs. The Length field contains the length of the Value field (in 163 bytes) that is variable and contains arbitrary data. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 . . 172 . Value . 173 . . 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 4: Format of LLS TLVs 177 Note that TLVs are always padded to 32-bit boundary, but padding 178 bytes are not included in TLV Length field (though it is included in 179 the LLS Data Length field of the LLS block header). 181 2.4 Predefined TLV 183 2.4.1 Extended Options TLV 185 This subsection describes a TLV called Extended Options (EO) TLV. 186 The format of EO-TLV is shown in Figure 5. 188 Bits in the Value field do not have any semantics from the point of 189 view of LLS mechanism. This field may be used to announce some OSPF 190 capabilities that are link-specific. Also, other OSPF extensions may 191 allocate bits in the bit vector to perform boolean link-local 192 signaling. 194 The length of the Value field in EO-TLV is 4 bytes. 196 The value of the type field in EO-TLV is TBD (temporarily used value 197 is 1). 199 EO-TLV should only appear once in the LLS data block. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | 1 | Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Extended Options | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 5: Format of EO TLV 210 2.4.2 Cryptographic Authentication TLV 212 This document defines a special TLV that is used for cryptographic 213 authentication (CA-TLV) of the LLS data block. This TLV should be 214 inluded in the LLS block when the cryptographic (MD5) authentication 215 is enabled on the corresponding inteface. The message digest of the 216 LLS block should be calculated using the same key as that used for 217 the main OSPF packet. The cryptographic sequence number is included 218 in the TLV and must be the same as the one in the main OSPF packet 219 for the LLS block to be considered authentic. 221 The TLV is constructed as shown Figure 6. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | 2 | AuthLen | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Sequence number | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 . . 232 . AuthData . 233 . . 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 6: Format of Cryptographic Authentication TLV 237 The value of the Type field for CA-TLV is TBD. Temoprary used value 238 is 2. 240 The Length field in the header contains the length of the data 241 portion of the TLV that includes 2 bytes for the Sequence Number and 242 the length of the message digest (MD5) block for the whole LLS block 243 in bytes (this will always be 16 bytes for MD5). So AuthLen field 244 will have value of 18. 246 The Sequence Number field contains the cryptographic sequence number 247 that is used to prevent simple replay attacks. For the LLS block to 248 be considered authentic, the Sequence Number in the CA-TLV must match 249 the Sequence Number in the OSPF packet. 251 The AuthData contains the message digest calculated for the LLS data 252 block. 254 The CA-TLV may appear in the LLS block only once. Also, when present, 255 this TLV should be the last in the LLS block. 257 3 IANA Considerations 259 LLS TLV types are maintained by the IANA. Extensions to OSPF which 260 require a new LLS TLV type must be reviewed by the OSPF working 261 group. In the event that the OSPF working group has disbanded the 262 review shall be performed by a recommended Designated Expert. 264 Following the policies outlined in [IANA], LLS type values in the 265 range of 0-32767 are allocated through an IETF Consensus action and 266 LLS type values in the range of 32768-65536 are reserved for private 267 and experimental use. 269 4 Compatibility Issues 271 The modifications to OSPF packet formats are compatible with standard 272 OSPF, because LLS-incapable routers will not consider the extra data 273 after the packet. 275 5 Security considerations 277 The described technique provides the same level of security as OSPF 278 protocol by allowing LLS data to be authenticated (see Section 2.4.2 279 for more details). 281 6 Acknowledgements 283 The authors would like to acknowledge Russ White for his review of 284 this document. 286 7 References 288 [RFC2328] 289 J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 290 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 291 notes/rfc2328.txt. 293 [IANA]T. Narten, H. Alvestrand. Guidelines for Writing an IANA Con- 294 siderations Section in RFCs. Best current practice RFC 2434. 295 ftp://ftp.isi.edu/in-notes/rfc2434.txt 297 8 Authors' addresses 299 Alex Zinin Barry Friedman 300 Cisco Systems Cisco Systems 301 150 W. Tasman Dr. 170 W. Tasman Dr. 302 San Jose,CA 95134 San Jose,CA 95134 303 USA USA 304 E-mail: azinin@cisco.com E-mail: friedman@cisco.com 306 Liem Nguyen Abhay Roy 307 7025 Kit Creek Rd. Cisco Systems 308 Research Triangle Park, NC 27709 170 W. Tasman Dr. 309 USA San Jose,CA 95134 310 e-mail: lhnguyen@cisco.com USA 311 E-mail: akr@cisco.com 313 Derek M. Yeung 314 Procket Networks 315 3850 N.First Street 316 San Jose, CA 95134 317 Phone: 408-954-7911 318 Fax: 408-987-6166 319 Email: myeung@procket.com