idnits 2.17.1 draft-nguyen-ospf-lls-01.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 (September 2002) is 7893 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 259, 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 (zinin@psg.com) 3 Internet Draft Barry Friedman (Cisco Systems) 4 Expiration Date: March 2003 Abhay Roy (Cisco Systems) 5 File name: draft-nguyen-ospf-lls-01.txt Liem Nguyen (Cisco Systems) 6 Derek Yeung (Procket) 7 September 2002 9 OSPF Link-local Signaling 10 draft-nguyen-ospf-lls-01.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 vendor 39 specific, backward-compatible technique to perform link-local 40 signaling, i.e., 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). The data included in LLS 91 block attached to a Hello packet may be used for dynamic signaling, 92 since Hello packets may be sent at any moment in time. However, 93 delivery of LLS data in Hello packets is not guaranteed. The data 94 sent with DBD packets is guaranteed to be delivered as soon as the 95 adjacency proceeds 96 This memo does not specify how the data transmitted by the LLS 97 mechanism should be interpreted by OSPF routers. The interface 98 between OSPF LLS component and its clients is implementation- 99 specific. 101 2.1 Options Field 103 A new bit, called L (L stands for LLS) is introduced to OSPF Options 104 field (see Figure 2). The value of the bit is 0x10. Routers set L 105 bit in Hello and DBD packets to indicate that the packet contains LLS 106 data block. 108 +---+---+---+---+---+---+---+---+ 109 | * | O | DC| L |N/P| MC| E | * | 110 +---+---+---+---+---+---+---+-+-+ 112 Figure 2: The Options field 114 The L-bit is set only in Hello and DBD packets. It is not set in OSPF 115 LSAs and may be used in them for different purposes. 117 2.2 LLS Data Block 119 The data block used for link-local signaling is formatted as 120 described below (see Figure 3 for illustration). 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Checksum | LLS Data Length | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | | 128 | LLS TLVs | 129 . . 130 . . 131 . . 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 Figure 3: Format of LLS Data Block 135 The Checksum field contains the standard IP checksum of the entire 136 contents of the LLS block. 138 The 16-bit LLS Data Length field contains the length (in 32-bit 139 words) of the LLS block including the header and payload. 140 Implementations should not use the Length field in the IP packet 141 header to determine the length of the LLS data block. 143 Note that if the OSPF packet is cryptographically authenticated, the 144 LLS data block must also be cryptographically authenticated. In this 145 case the regular LLS checksum is not calculated and the LLS block 146 will contain a cryptographic authentication TLV (see Section 2.4.2). 148 The rest of the block contains a set of Type/Length/Value (TLV) 149 triplets as described in Section 2.2. All TLVs must be 32-bit 150 aligned (with padding if necessary). 152 2.3 LLS TLVs 154 The contents of LLS data block is constructed using TLVs. See Figure 155 4 for the TLV format. 157 The type field contains the TLV ID which is unique for each type of 158 TLVs. The Length field contains the length of the Value field (in 159 bytes) that is variable and contains arbitrary data. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 . . 168 . Value . 169 . . 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 4: Format of LLS TLVs 173 Note that TLVs are always padded to 32-bit boundary, but padding 174 bytes are not included in TLV Length field (though it is included in 175 the LLS Data Length field of the LLS block header). 177 2.4 Predefined TLV 179 2.4.1 Extended Options TLV 181 This subsection describes a TLV called Extended Options (EO) TLV. 182 The format of EO-TLV is shown in Figure 5. 184 Bits in the Value field do not have any semantics from the point of 185 view of LLS mechanism. This field may be used to announce some OSPF 186 capabilities that are link-specific. Also, other OSPF extensions may 187 allocate bits in the bit vector to perform boolean link-local 188 signaling. 190 The length of the Value field in EO-TLV is 4 bytes. 192 The value of the type field in EO-TLV is TBD (temporarily used value 193 is 1). 195 EO-TLV should only appear once in the LLS data block. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | 1 | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Extended Options | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 5: Format of EO TLV 206 2.4.2 Cryptographic Authentication TLV 208 This document defines a special TLV that is used for cryptographic 209 authentication (CA-TLV) of the LLS data block. This TLV should be 210 included in the LLS block when the cryptographic (MD5) authentication 211 is enabled on the corresponding interface. The message digest of the 212 LLS block should be calculated using the same key as that used for 213 the main OSPF packet. The cryptographic sequence number is included 214 in the TLV and must be the same as the one in the main OSPF packet 215 for the LLS block to be considered authentic. 217 The TLV is constructed as shown Figure 6. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | 2 | AuthLen | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Sequence number | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 . . 228 . AuthData . 229 . . 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 6: Format of Cryptographic Authentication TLV 233 The value of the Type field for CA-TLV is TBD. Temporary used value 234 is 2. 236 The Length field in the header contains the length of the data 237 portion of the TLV that includes 4 bytes for the Sequence Number and 238 the length of the message digest (MD5) block for the whole LLS block 239 in bytes (this will always be 16 bytes for MD5). So AuthLen field 240 will have value of 20. 242 The Sequence Number field contains the cryptographic sequence number 243 that is used to prevent simple replay attacks. For the LLS block to 244 be considered authentic, the Sequence Number in the CA-TLV must match 245 the Sequence Number in the OSPF packet. 247 The AuthData contains the message digest calculated for the LLS data 248 block. 250 The CA-TLV may appear in the LLS block only once. Also, when present, 251 this TLV should be the last in the LLS block. 253 3 IANA Considerations 255 LLS TLV types are maintained by the IANA. Extensions to OSPF which 256 require a new LLS TLV type must be reviewed by an designated expert 257 from the routing area. 259 Following the policies outlined in [IANA], LLS type values in the 260 range of 0-32767 are allocated through an IETF Consensus action and 261 LLS type values in the range of 32768-65536 are reserved for private 262 and experimental use. 264 4 Compatibility Issues 266 The modifications to OSPF packet formats are compatible with standard 267 OSPF, because LLS-incapable routers will not consider the extra data 268 after the packet. 270 5 Security considerations 272 The described technique provides the same level of security as OSPF 273 protocol by allowing LLS data to be authenticated (see Section 2.4.2 274 for more details). 276 6 Acknowledgements 278 The authors would like to acknowledge Russ White for his review of 279 this document. 281 7 References 283 [RFC2328] 284 J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 285 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 286 notes/rfc2328.txt. 288 [IANA]T. Narten, H. Alvestrand. Guidelines for Writing an IANA Con- 289 siderations Section in RFCs. Best current practice RFC 2434. 290 ftp://ftp.isi.edu/in-notes/rfc2434.txt 292 8 Authors' addresses 294 Alex Zinin Barry Friedman 295 Cisco Systems 296 170 W. Tasman Dr. 297 San Jose,CA 95134 298 USA USA 299 E-mail: zinin@psg.com E-mail: friedman@cisco.com 301 Liem Nguyen Abhay Roy 302 7025 Kit Creek Rd. Cisco Systems 303 Research Triangle Park, NC 27709 170 W. Tasman Dr. 304 USA San Jose,CA 95134 305 e-mail: lhnguyen@cisco.com USA 306 E-mail: akr@cisco.com 308 Derek M. Yeung 309 Procket Networks 310 3850 N.First Street 311 San Jose, CA 95134 312 Phone: 408-954-7911 313 Fax: 408-987-6166 314 Email: myeung@procket.com