idnits 2.17.1 draft-herbert-simple-sr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '... o Reserved: MUST be set to zero w...' RFC 2119 keyword, line 275: '... A sender SHOULD follow the recommen...' RFC 2119 keyword, line 280: '...enable this, a sender MUST ensure that...' RFC 2119 keyword, line 282: '... security option MUST be the last opti...' RFC 2119 keyword, line 287: '... security option MUST be processed by ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1872 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SRHV6' is mentioned on line 84, but not defined -- Looks like a reference, but probably isn't: '0' on line 130 == Missing Reference: 'RFC8200' is mentioned on line 293, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-31) exists of draft-bonica-6man-comp-rtg-hdr-01 == Outdated reference: A later version (-09) exists of draft-bonica-6man-seg-end-opt-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: September 2019 6 March 11, 2019 8 Simple Segment Routing Header 9 draft-herbert-simple-sr-00 11 Abstract 13 This specification defines a simple extension header format for 14 Segment Routing based on the current definition of the Segment 15 Routing extension header defined for IPv6. A Segment Identifier type 16 field is added so that the segment list might contain values other 17 than IPv6 addresses. Optional TLVs in the segment routing header are 18 eliminated; Destination options that precede the routing header are 19 sufficient. Two new destination options are defined: one for Routing 20 header security and another to specify that certain destinations 21 should process certain options. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 Simple segment routing header format . . . . . . . . . . . . . 4 63 2.1 SType values . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3 Routing header security option . . . . . . . . . . . . . . . . 5 65 3.1 HMAC Routing header security . . . . . . . . . . . . . . . . 7 66 3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2.1 Sender operation . . . . . . . . . . . . . . . . . . . . 7 68 3.2.2 Receiver operation . . . . . . . . . . . . . . . . . . . 7 69 4 Process per segment Destination Option . . . . . . . . . . . . 8 70 4.1 Sender operation . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2 Receiver operation . . . . . . . . . . . . . . . . . . . . . 9 72 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 73 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 74 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 76 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1 Introduction 81 This specification defines a simplified segment routing header and 82 generalizes some aspects of segment routing to be applicable to other 83 types of routing headers. The segment routing header is defined in 84 [SRHV6]. 86 The following modifications and additions are defined: 88 * A Segment Identifier type field in the Segment routing header. 90 This field indicates the type of elements in the segment routing 91 list and also indicates the length of each element. Segment 92 Identifier types are defined for IPv6 and IPv4 addresses, as 93 well as types for indices into tables that would map a Segment 94 Identifier to an address. The concept of types for Segment 95 Identifier is a generalization of Segment Routing header 96 compression defined in [SRCOMP]. 98 * Eliminate options (TLVs) from Segment Routing header. 100 Options pertaining to Segment Routing, or more generally any 101 type of Routing header, may be set in Destination Options that 102 precede the Routing header. 104 * Routing header security Destination option. 106 This option provides an extensible method for verifying security 107 of a routing header. An HMAC option is defined that provides the 108 same functionality as the HMAC TLV defined in [SRV6EH] (except 109 that it is generic to work with all types of Routing headers). 111 * Process per segment Destination option. 113 The purpose of this option is to allow a node to indicate that 114 certain Destination options are to be processed only by certain 115 nodes in the Segment List. This is a generalization of the 116 option described in [SRENDOPT]. 118 2 Simple segment routing header format 120 The format of the simple segment routing header is shown below. 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 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Last Entry | SType | Flags | Tag | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 ~ Segment List[0] (length per Stype) ~ 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | | 134 | | 135 ... 136 | | 137 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | | 140 ~ Segment List[n] (length per SType) ~ 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The format is based on that described in [SRV6EH]. Modified or added 145 fields are: 147 o SType: Type of segment identifiers. Possible values are listed 148 below. 150 o Segment List[]. Each element of the segment list contains a 151 segment identifier with the type indicated by SType. The length 152 of each identifier is implied by the SType. 154 Note that the optional TLVs section is not present in the simplified 155 format. The rest of the fields in the format retain the same meaning 156 an format as described in [SRV6EH]. 158 2.1 SType values 160 The following are the SType values: 162 o 0: IPv6 address, 128 bit value 164 o 1: IPv6 identifier, 64 bit value 165 o 2: IPv6 locator, 64 bit value 167 o 3: IPv4 address, 32 bit value 169 o 4: 8 bit map value 171 o 5: 16 bit map value 173 o 6: 32 bit map value 175 o 7: 64 bit map value 177 Values 8 to 13 are reserved. Values 14 and 15 are experimental and 178 may be specified locally in a segment routing domain. 180 The IPv6 identifier provides the low order 64 bits of IPv6 address. 181 The high order 64 bit prefix is assumed to be common for all 182 destinations. A fully qualified IPv6 address is created by combing 183 the upper 64 bit prefix in the destination address of the packet with 184 the identifier value as the low order 64 bits. The identifier type 185 can be considered of form of compressing IPv6 addresses in segment 186 identifiers when all the segment identifiers share the same prefix 187 (.e.g a sixty-four bit prefix is common for all addresses in a 188 segment routing domain. 190 The IPv6 locator provides the high order 64 bits of IPv6 address. The 191 low order 64 bits are assumed to be common for all destinations in a 192 segment routing list. The use case for this would be 193 Identifier/Locator protocols such as ILA or ILNP. A fully qualified 194 address is created by combining the 64 bit prefix in the destination 195 address of the packet with the identifier value as the low order 64 196 bits. The locatorr type can be considered of form of compressing IPv6 197 addresses in segment identifiers when all the segment identifiers 198 share the same low order sixty-four bits. 200 Map values are mapped by receivers to fully qualified segment 201 identifiers. A common use of this would be from receivers to maintain 202 tables that map small segment identifiers to larger addresses. The 203 table is specific within a segment routing domain must be managed 204 accordingly. Using map values can be considerable savings in packet 205 overhead when segment routing is used, particularly when a segment 206 routing list would carry multiple IPv6 addresses. 208 3 Routing header security option 210 The routing header security options is a Destination Option that 211 provides security for a following routing header. 213 The format of the option is: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | Sub-type | Reserved | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 ~ Sub-type specific data ~ 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Fields are: 227 o Type: Destination Option type for Routing Header security. This 228 is a non-modifiable option and must not be ignored. Accordingly, 229 the high order type bits are 010 to reflect that. 231 o Length: Variable length of option data. 233 o Sub-type: Security method used. This specification defines one 234 method of HMAC. See below. 236 o Reserved: MUST be set to zero when sending. 238 o Sub-type specific data: Data that is specific to the sub-type. 239 The sub-type specific data for HMAC is described below. 241 3.1 HMAC Routing header security 243 HMAC Routing header security is a sub-type of routing header 244 security. The format of the sub-type specific data is: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | HMAC Key ID (4 octets) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | // 252 | HMAC (32 octets) // 253 | // 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 where: 258 o HMAC Key ID: 4 octets. 260 o HMAC: 32 octets. 262 The operation of the HMAC with respect routing header is specified in 263 [SRV6EH]. 265 3.2 Operation 267 The section describes the use and processing of the routing header 268 security Destination Option. 270 3.2.1 Sender operation 272 A sender may set a routing header security option in Destination 273 Options that precede a Routing Header. 275 A sender SHOULD follow the recommended ordering in RFC8200 that a 276 routing header immediately follows Destination Options that precede 277 the routing header. As described below, if destination options 278 immediately precede a routing header, a receive may apply the 279 security option to the routing header while processing the security 280 option as an optimization. To enable this, a sender MUST ensure that 281 the Routing header immediately follows the Destination Options, and 282 the routing header security option MUST be the last option in the 283 Destination Options. 285 3.2.2 Receiver operation 287 The security option MUST be processed by the last node in the routing 288 header list of nodes to visit, and MAY be processed by intermediate 289 destinations. If a node does not process the option it MUST skip the 290 option and proceed to the next option. 292 As demonstrated in the HMAC description, the routing header security 293 option may be applied to fields in the routing header. Per [RFC8200], 294 extension headers cannot be processed out of order so care must be 295 taken to ensure processing order semantics are maintained. This 296 specification presents two alternative methods that should yield the 297 same effect. 299 When a node processes a routing header security option in Destination 300 Options, it can record the option data and make a note that the 301 security is to be applied to the routing header. Subsequently, when 302 the routing header is processed, the node can perform security 303 verification as the first step in processing the routing header. 305 An alternative is for a node to perform the security verification 306 when processing the security option in the Destination Options. A 307 receiver MUST only do this if the Routing header immediately follows 308 the Destination Options header and the routing header security option 309 is the last Destination option. 311 4 Process per segment Destination Option 313 A sender MAY indicate that certain destination options preceding a 314 Routing header are applicable to certain segments. A new option is 315 defined for this functionality. This option SHOULD only be used if 316 Destination Options immediately precedes a Routing header. 318 The format of the option is: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | Bit map ... 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 o Type: Destination Option type for the process per segment 327 Destination Options. This is a non-modifiable option and must 328 not be ignored. Accordingly, the high order type bits are 010 to 329 reflect that. 331 o Length: Variable length of the bit map in octets. 333 o Bit map: A variable length bit map that describes which nodes 334 are to process the option. 336 A position in the bit map corresponds to a Segments Left value in the 337 Routing header. For instance, if bit 3 in the bit map is set, then 338 the option is processed by the node when Segments Left is 3. A bit 339 map can indicate that multiple nodes are to process the options. Bits 340 beyond the length of the bit map are assumed be zero. 342 If the length of the bit map is zero (i.e. length of the option data 343 is zero) then any following options are MUST be processed by all 344 intermediate nodes. 346 4.1 Sender operation 348 A sender MAY set the process per segment Destination Option. The 349 Destination Options SHOULD immediately precede a Routing Header. The 350 sender MAY indicate in the bit map that multiple intermediate 351 destinations must process the options that following the process per 352 segment option. Any Destination options MAY follow the process per 353 segment option. A sender MAY direct options at different sets of 354 intermediate destination by setting the per segment Destination 355 option for each set. Options that precede a per segment Destination 356 option are expected to be processed normally by each destination. 358 4.2 Receiver operation 360 When a node receives a process per segment Destination option it 361 performs the following processing: 363 1) Check if the Next Header in the Destination Options header 364 indicates a routing header (i.e. Next Header is equal to 43). 365 If the next header is not a Routing header then processing the 366 Destination Options is complete. Any following options are 367 ignored. 369 2) Extract the Segments Left value from the Routing header 370 immediately following the Destination Options header. 372 3) Determine the value in the bit map of the process per Segment 373 option corresponding to the Segments Left value. 375 - If the bit map value is set (bit is one) then process any 376 following options to the end of the options list or another 377 process per Segment option encountered. 379 - If the bit map value is unset (bit is zero) then skip any 380 following options to the end of the options list or another 381 process per Segment option encountered. 383 4) If another process per Segment option is encountered process it 384 starting from step #3 above 386 5 Security Considerations 388 This document defines new Destination option that is use to provide 389 security for a routing header. 391 6 IANA Considerations 393 IANA is requested to assign two Destination options types. 395 IANA is requested to create a sub-type registry for the routing 396 header security Destination Option. 398 7 References 400 7.1 Normative References 402 7.2 Informative References 404 [SRV6EH] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 405 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 406 (SRH)", draft-ietf-6man-segment-routing-header-16. 408 [SRCOMP] Bonica, R., Xu, X., Chen, G., Zhu, Y., and Yang, G., "The 409 IPv6 Compressed Routing Header (CRH)", draft-bonica-6man- 410 comp-rtg-hdr-01. 412 [SRENDOPT] Bonica, R., Xu, X., Chen, G., Zhu, Y., and Yang, G., "The 413 IPv6 Segment Endpoint Option", draft-bonica-6man-seg-end- 414 opt-02 416 Author's Address 418 Tom Herbert 419 Quantonium 420 Santa Clara, CA 421 USA 423 Email: tom@quantonium.net