idnits 2.17.1 draft-eastlake-trill-rbridge-more-options-03.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 17, 2011) is 4567 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Huawei 3 Expires: April 16, 2011 October 17, 2011 5 RBridges: More Proposed TRILL Header Options 6 8 Abstract 10 The TRILL base protocol standard, RFC 6325, specifies minimal hooks 11 for options and draft-ietf-trill-rbridge-options specifies the format 12 for options and a proposed initial set of options. This draft is a 13 holding location for additional proposed options. It is not intended 14 that this draft will ever progress to be an RFC. 16 Status of This Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Distribution of this document is unlimited. Comments should be sent 22 to the TRILL working group mailing list . 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Terminology............................................3 45 2. Extended Flag Options...................................4 47 3. TLV Options.............................................5 48 3.1 Additional Flags TLV Option............................5 49 3.2 Port ID TLV Option.....................................5 50 3.3 Extended Options TLV...................................6 51 3.3.1 Extended Options IANA Considerations.................7 52 3.4 Vendor Options TLV.....................................8 53 3.5 Authentication TLV Option..............................8 54 3.5.1 Authentication Option Computations...................9 55 3.5.2 Authentication Option Fields and Flags...............9 57 4. Acknowledgement........................................10 58 5. Security Considerations................................10 59 6. IANA Considerations....................................10 60 7. Normative References...................................11 61 8. Informative References.................................11 63 1. Introduction 65 The IETF has standardized the TRILL protocol [RFC6325] a solution for 66 transparent shortest-path frame routing in multi-hop Ethernet 67 networks with arbitrary topologies, using an existing link-state 68 routing protocol and encapsulation with a hop count. That standard 69 specifies minimal hooks for options and [RFCopt] specifies the format 70 for options and a proposed initial set of options. 72 This draft is a holding location for other proposed TRILL header 73 options. The options described here may or may not ever be adopted as 74 extensions to the TRILL protocol specification. Most of the 75 descriptions herein need at least some further work, may be missing 76 IANA or Security Considerations, or have other problems. It is not 77 intended that this draft will ever progress to be an RFC. 79 1.1 Terminology 81 The terminology and acronyms of [RFC6325] are used in this document. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Extended Flag Options 89 Options that appear bit encoded in the TRILL Header options area 90 (extended header flag options) are specified in Section 2.3.1 of 91 [RFCopt] and a specific bit option is specified in Section 3 of 92 [RFCopt]. 94 No additional extended flag options are specified in this version of 95 this document. 97 3. TLV Options 99 Options that are Type, Length, Value (TLV) encoded in the TRILL 100 Header options area (TLV options) are specified in Section 2.3.2 and 101 2.3.3 of [RFCopt]. Two specific TLV options are specified in Section 102 4 of [RFCopt]. 104 A number of potential additional TRILL Header TLV options are 105 specified below. 107 3.1 Additional Flags TLV Option 109 This option provides a means of adding a variety of additional flags 110 to the TRILL Header beyond the extended header flag options available 111 in the first four octets of the options area. 113 The value of a flags option consists of additional flags, eight per 114 octet, numbered from the high-order to the low-order bit. Thus flag 1 115 is the 0x80 bit of the first octet, flag 8 is the 0x01 bit of that 116 octet, flag 9 is the 0x80 bit of the second octet, etc. The number of 117 additional flags that can be defined is bounded only by the options 118 space that can be available. All flags not present, because they 119 would be in value octets beyond those specified by the option Length, 120 are considered zero. 122 This option can appear once in a frame for each possible combination 123 of the ingress-to-egress, hop-by-hop, non-critical, critical, mutable 124 and immutable flags (all combinations except for mutable critical 125 hop-by-hop, which is a meaningless). To simplify canonicalization for 126 security, this option MUST NOT be included if all of the flag bits 127 would be zero and the value MUST NOT have any trailing zero octets. 128 Thus its Length MUST be at least 1 and at least the last octet of the 129 value present MUST be non-zero. 131 The option fields and flags are as follows: 133 o Type is 0xTBD. 134 o Length is variable with a minimum value of 1. 135 o IE, NC, MT can be any valid combination producing several 136 variations of this option. 138 3.2 Port ID TLV Option 140 The primary purpose of the Port ID option is to normally avoid the 141 unicast Inner.MacDA address lookup at the egress RBridge to find the 142 port on which to send a decapsulated native frame. 144 This option provides a 2-octet logical destination port and a 2-octet 145 logical source port that, in some ways, could be considered 146 extensions to the 6-octet inner destination and source MAC addresses 147 in a frame. These logical port designators are local to the 148 destination and source RBridges respectively. They may be any values 149 that those RBridges find convenient to efficiently map to their 150 physical ports except that the value 0x0000 is used to indicate that 151 a logical port designator is unknown and the value 0xFFFF is reserved 152 and MUST NOT appear in a port ID option. Should an RBridge 153 implementing this option receive a frame with a destination port ID 154 of 0xFFFF it handles it as if the destination port ID was 0x0000. 156 RBridges that implement this option learn the Port ID for a remote 157 MAC address from the source Port ID field in the Port ID option, if 158 present, in frames they decapsulate in the same way they can learn 159 the ingress RBridge and VLAN. This information is timed out or 160 replaced in the same manner as remote MAC address information learned 161 from the data plane. Such RBridges include their local Port ID in the 162 source field of a Port ID option when encapsulating a frame when 163 inclusion of this option is indicated by their local policy. 165 For known unicast TRILL data frames, one would expect ingress 166 RBridges implementing this option to include the option if they are 167 sending to egress RBridges that also implement the option. For multi- 168 destination TRILL data frames, inclusion of a Port ID option with a 169 source port ID may make sense but the destination port ID is 170 meaningless and ignored by egress RBridges. 172 The option fields and flags are as follows: 174 o Type is 0xTBD. 175 o Length MUST be 6. The data is the 2-octet destination port ID 176 followed by the 2-octet source port IS followed by two reserved 177 octets. The reserved octets MUST be set to zero when this 178 option is inserted by an ingress RBridge, be copied without 179 change but otherwise ignored by transit RBridges, and be 180 ignored by egress RBridges. 181 o IE and NC MUST be one. This is an ingress-to-egress non- 182 critical option. 183 o MT MUST be zero. This is an immutable option. 185 3.3 Extended Options TLV 187 This option provides an extension mechanism for shorter options to 188 avoid using up top-level Types in TLV option encoding. These extended 189 options could be referred to as sub-TLV encoded. 191 The value part of an Extended Options TLV consists of extended 192 options each of which is sub-TLV encoded as follows: 194 | 0 1 2 3 4 5 6 7 8| 9 10 11 12 13 14 15| 195 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- 196 | Extended Type | Length | Value... 197 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- 198 | | | 200 The Extended Type is an unsigned 12-bit number whose high order part 201 is the first octet and whose low order part is the high order four 202 bits of the second octet. 204 The Length field is the low order four bits of the second octet. It 205 gives the length of the extended option value, that is, the number of 206 additional octets after the extended type and length. 208 There is no need for IE, NC, or MT flags in an extended option sub- 209 TLV because each particular extended option inherits its IE, NC, and 210 MT status from the enclosing Extended Options TLV. 212 The length specified in an Extended Options TLV MUST be exactly the 213 sum of the total lengths of the Extended Options that its value area 214 contains, that is, the sum of the enclosed Extended Option sub-TLV 215 lengths plus two times the number of Extended Option sub-TLVs for 216 their initial two octets. 218 If multiple Extended Options are present in an Extended Options TLV, 219 there is no space between them. Thus, while an Extended Option is an 220 integer number of octets, it has no other special alignment. Transit 221 RBridges MUST NOT re-order the extended options within an ingress-to- 222 egress Extended Options TLV. 224 The option fields and flags are as follows: 226 o Type is 0xTBD. 227 o Length minimum 2. 228 o IE, NC, and MT can be any valid combination producing several 229 variations of this option. 231 3.3.1 Extended Options IANA Considerations 233 The Extended Types 0x000 and 0xFFF are reserved and require IETF 234 standards action for allocation. The values 0x001 through 0xFFE are 235 available for assignment based on RFC publication. The assigning RFC 236 MUST specify, for each extended option type, the allowed values of 237 the IE, NC, and MT bits in the Extended Options TLV that will enclose 238 occurrences of that specific Extended Option. 240 3.4 Vendor Options TLV 242 This option is provided to supply a standard method for the 243 specification of vendor specific options in a TRILL Header. Vendor 244 identity and specific options are encoded into the value associated 245 with the option. Since vendor specific options could require any 246 valid combination of the IE, NC, and MT bits, they inherit they 247 inherit these from enclosing Vendor Options TLV. 249 Each vendor specific option starts with three bytes of OUI followed 250 by a forth byte that has, in the bottom four bits, the length of the 251 additional value of the vendor specific option in bytes. The top four 252 bits of this fourth byte are available for vendor use, for example, 253 to distinguish different options. 255 Transit RBridges MUST NOT re-order the vendor specific options within 256 an ingress-to-egress Vendor Options TLV. The Vendor Options fields 257 and flags are as follows: 259 o Type is 0xTBD. 260 o Length is variable with a minimum of 4. 261 o IE, NC, and MT can be any valid combination producing several 262 variations of this option. 264 3.5 Authentication TLV Option 266 [The write-up of this option is not complete.] 268 TRILL provides an authentication option that builds on the IS-IS 269 security keying [RFC5304] [RFC5310] and can be applied to frames with 270 a TRILL Header. 272 The first octet of the option value is the same algorithm selection 273 code as for the IS-IS Authentication TLV (IS-IS TLV #). The value 274 length for the option is variable and depends on the algorithm in the 275 same way as the value in the IS-IS security TLV. Algorithm zero 276 indicates a plain text password which must be configured in code 277 which generates and checks this TLV and is NOT RECOMMENDED. Thus far, 278 other algorithms have indicated HMAC signing of a canonical form of 279 the message using a shared secret that must likewise be configured. 281 This option can appear up to twice in a frame, once for ingress-to- 282 egress authentication and once for hop-by-hop authentication. 284 3.5.1 Authentication Option Computations 286 For algorithms which depend on the value of the frame (i.e., all 287 strong authentication algorithms), the frame must be canonicalized 288 before the authentication code is computed or verified. This 289 canonicalization is logically done by copying the frame starting with 290 the TRILL Header and modifying the copy as follows: 292 1. Set the TRILL Header Hop Count to zero. 294 2. Clear the octets of the Security Option after the algorithm 295 selection code. 297 3. For all mutable options, setting the option Length to zero and 298 remove any value octets. 300 4. If an ingress-to-egress authentication code is being computed, 301 since hop-by-hop options can be added or deleted in transit, all 302 hop-by-hop options must be removed from the frame copy. When a 303 critical hop-by-hop option is removed, any required adjustments 304 must be made in the remainder of the frame, as if it was about to 305 be forwarded to an RBridge that did not support that hop-by-hop 306 critical option. 308 5. Adjust the TRILL Header Op-Length downward as necessary to make it 309 correct for the other adjustments made in the frame copy. 311 The authentication code is then calculated using this copy and either 312 inserted into the authentication option in the real frame for 313 transmission or compared against the authentication code in the real 314 frame for verification. 316 3.5.2 Authentication Option Fields and Flags 318 The security option fields and flags are as follows: 320 o Type is 0xTBD. 321 o Length MUST be at least 1. 322 o IE is variable. There may be an ingress-to-egress or hop-by-hop 323 security option in a frame or both. 324 o NC and MT MUST be zero. This is a critical, immutable option. 326 4. Acknowledgement 328 The Port ID option was suggested as part of the TRILL Header by 329 Silvano Gai. 331 5. Security Considerations 333 -- TBD -- 335 6. IANA Considerations 337 -- See IANA Considerations sub-sections above. -- 339 7. Normative References 341 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997 344 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 345 Ghanwani, "Routing Bridges (RBridges): Base Protocol 346 Specification", RFC 6325, July 2011. 348 [RFCopt] - D. Eastlake, A. Ghanwani, V. Manral, and C. Bestler, 349 "RBridges: TRILL Header Options", draft-ietf-trill-rbridge- 350 options, work in progress, June 2010. 352 8. Informative References 354 [RFC5304] - Li, T. and R. Atkinson, "Intermediate System to 355 Intermediate System (IS-IS) Cryptographic Authentication", RFC 356 5304, October 2008. 358 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 359 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 360 5310, February 2009. 362 Authors' Addresses 364 Donald E. Eastlake 3rd 365 Huawei Technologies 366 155 Beaver Street 367 Milford, MA 01757 369 tel: +1-508-333-2270 370 email: d3e3e3@gmail.com 372 Copyright and IPR Provisions 374 Copyright (c) 2011 IETF Trust and the persons identified as the 375 document authors. All rights reserved. 377 This document is subject to BCP 78 and the IETF Trust's Legal 378 Provisions Relating to IETF Documents 379 (http://trustee.ietf.org/license-info) in effect on the date of 380 publication of this document. Please review these documents 381 carefully, as they describe your rights and restrictions with respect 382 to this document. Code Components extracted from this document must 383 include Simplified BSD License text as described in Section 4.e of 384 the Trust Legal Provisions and are provided without warranty as 385 described in the Simplified BSD License. The definitive version of 386 an IETF Document is that published by, or under the auspices of, the 387 IETF. Versions of IETF Documents that are published by third parties, 388 including those that are translated into other languages, should not 389 be considered to be definitive versions of IETF Documents. The 390 definitive version of these Legal Provisions is that published by, or 391 under the auspices of, the IETF. Versions of these Legal Provisions 392 that are published by third parties, including those that are 393 translated into other languages, should not be considered to be 394 definitive versions of these Legal Provisions. For the avoidance of 395 doubt, each Contributor to the IETF Standards Process licenses each 396 Contribution that he or she makes as part of the IETF Standards 397 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 398 language to the contrary, or terms, conditions or rights that differ 399 from or are inconsistent with the rights and licenses granted under 400 RFC 5378, shall have any effect and shall be null and void, whether 401 published or posted by such Contributor, or included with or in such 402 Contribution.