TRILL Working Group Donald Eastlake 3rd INTERNET-DRAFT Huawei Expires: April 16, 2011 October 17, 2011 RBridges: More Proposed TRILL Header Options Abstract The TRILL base protocol standard, RFC 6325, specifies minimal hooks for options and draft-ietf-trill-rbridge-options specifies the format for options and a proposed initial set of options. This draft is a holding location for additional proposed options. It is not intended that this draft will ever progress to be an RFC. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list . Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html D. Eastlake [Page 1] INTERNET-DRAFT Proposed TRILL Header Options Table of Contents 1. Introduction............................................3 1.1 Terminology............................................3 2. Extended Flag Options...................................4 3. TLV Options.............................................5 3.1 Additional Flags TLV Option............................5 3.2 Port ID TLV Option.....................................5 3.3 Extended Options TLV...................................6 3.3.1 Extended Options IANA Considerations.................7 3.4 Vendor Options TLV.....................................8 3.5 Authentication TLV Option..............................8 3.5.1 Authentication Option Computations...................9 3.5.2 Authentication Option Fields and Flags...............9 4. Acknowledgement........................................10 5. Security Considerations................................10 6. IANA Considerations....................................10 7. Normative References...................................11 8. Informative References.................................11 D. Eastlake [Page 2] INTERNET-DRAFT Proposed TRILL Header Options 1. Introduction The IETF has standardized the TRILL protocol [RFC6325] a solution for transparent shortest-path frame routing in multi-hop Ethernet networks with arbitrary topologies, using an existing link-state routing protocol and encapsulation with a hop count. That standard specifies minimal hooks for options and [RFCopt] specifies the format for options and a proposed initial set of options. This draft is a holding location for other proposed TRILL header options. The options described here may or may not ever be adopted as extensions to the TRILL protocol specification. Most of the descriptions herein need at least some further work, may be missing IANA or Security Considerations, or have other problems. It is not intended that this draft will ever progress to be an RFC. 1.1 Terminology The terminology and acronyms of [RFC6325] are used in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. D. Eastlake [Page 3] INTERNET-DRAFT Proposed TRILL Header Options 2. Extended Flag Options Options that appear bit encoded in the TRILL Header options area (extended header flag options) are specified in Section 2.3.1 of [RFCopt] and a specific bit option is specified in Section 3 of [RFCopt]. No additional extended flag options are specified in this version of this document. D. Eastlake [Page 4] INTERNET-DRAFT Proposed TRILL Header Options 3. TLV Options Options that are Type, Length, Value (TLV) encoded in the TRILL Header options area (TLV options) are specified in Section 2.3.2 and 2.3.3 of [RFCopt]. Two specific TLV options are specified in Section 4 of [RFCopt]. A number of potential additional TRILL Header TLV options are specified below. 3.1 Additional Flags TLV Option This option provides a means of adding a variety of additional flags to the TRILL Header beyond the extended header flag options available in the first four octets of the options area. The value of a flags option consists of additional flags, eight per octet, numbered from the high-order to the low-order bit. Thus flag 1 is the 0x80 bit of the first octet, flag 8 is the 0x01 bit of that octet, flag 9 is the 0x80 bit of the second octet, etc. The number of additional flags that can be defined is bounded only by the options space that can be available. All flags not present, because they would be in value octets beyond those specified by the option Length, are considered zero. This option can appear once in a frame for each possible combination of the ingress-to-egress, hop-by-hop, non-critical, critical, mutable and immutable flags (all combinations except for mutable critical hop-by-hop, which is a meaningless). To simplify canonicalization for security, this option MUST NOT be included if all of the flag bits would be zero and the value MUST NOT have any trailing zero octets. Thus its Length MUST be at least 1 and at least the last octet of the value present MUST be non-zero. The option fields and flags are as follows: o Type is 0xTBD. o Length is variable with a minimum value of 1. o IE, NC, MT can be any valid combination producing several variations of this option. 3.2 Port ID TLV Option The primary purpose of the Port ID option is to normally avoid the unicast Inner.MacDA address lookup at the egress RBridge to find the port on which to send a decapsulated native frame. D. Eastlake [Page 5] INTERNET-DRAFT Proposed TRILL Header Options This option provides a 2-octet logical destination port and a 2-octet logical source port that, in some ways, could be considered extensions to the 6-octet inner destination and source MAC addresses in a frame. These logical port designators are local to the destination and source RBridges respectively. They may be any values that those RBridges find convenient to efficiently map to their physical ports except that the value 0x0000 is used to indicate that a logical port designator is unknown and the value 0xFFFF is reserved and MUST NOT appear in a port ID option. Should an RBridge implementing this option receive a frame with a destination port ID of 0xFFFF it handles it as if the destination port ID was 0x0000. RBridges that implement this option learn the Port ID for a remote MAC address from the source Port ID field in the Port ID option, if present, in frames they decapsulate in the same way they can learn the ingress RBridge and VLAN. This information is timed out or replaced in the same manner as remote MAC address information learned from the data plane. Such RBridges include their local Port ID in the source field of a Port ID option when encapsulating a frame when inclusion of this option is indicated by their local policy. For known unicast TRILL data frames, one would expect ingress RBridges implementing this option to include the option if they are sending to egress RBridges that also implement the option. For multi- destination TRILL data frames, inclusion of a Port ID option with a source port ID may make sense but the destination port ID is meaningless and ignored by egress RBridges. The option fields and flags are as follows: o Type is 0xTBD. o Length MUST be 6. The data is the 2-octet destination port ID followed by the 2-octet source port IS followed by two reserved octets. The reserved octets MUST be set to zero when this option is inserted by an ingress RBridge, be copied without change but otherwise ignored by transit RBridges, and be ignored by egress RBridges. o IE and NC MUST be one. This is an ingress-to-egress non- critical option. o MT MUST be zero. This is an immutable option. 3.3 Extended Options TLV This option provides an extension mechanism for shorter options to avoid using up top-level Types in TLV option encoding. These extended options could be referred to as sub-TLV encoded. The value part of an Extended Options TLV consists of extended D. Eastlake [Page 6] INTERNET-DRAFT Proposed TRILL Header Options options each of which is sub-TLV encoded as follows: | 0 1 2 3 4 5 6 7 8| 9 10 11 12 13 14 15| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- | Extended Type | Length | Value... +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- | | | The Extended Type is an unsigned 12-bit number whose high order part is the first octet and whose low order part is the high order four bits of the second octet. The Length field is the low order four bits of the second octet. It gives the length of the extended option value, that is, the number of additional octets after the extended type and length. There is no need for IE, NC, or MT flags in an extended option sub- TLV because each particular extended option inherits its IE, NC, and MT status from the enclosing Extended Options TLV. The length specified in an Extended Options TLV MUST be exactly the sum of the total lengths of the Extended Options that its value area contains, that is, the sum of the enclosed Extended Option sub-TLV lengths plus two times the number of Extended Option sub-TLVs for their initial two octets. If multiple Extended Options are present in an Extended Options TLV, there is no space between them. Thus, while an Extended Option is an integer number of octets, it has no other special alignment. Transit RBridges MUST NOT re-order the extended options within an ingress-to- egress Extended Options TLV. The option fields and flags are as follows: o Type is 0xTBD. o Length minimum 2. o IE, NC, and MT can be any valid combination producing several variations of this option. 3.3.1 Extended Options IANA Considerations The Extended Types 0x000 and 0xFFF are reserved and require IETF standards action for allocation. The values 0x001 through 0xFFE are available for assignment based on RFC publication. The assigning RFC MUST specify, for each extended option type, the allowed values of the IE, NC, and MT bits in the Extended Options TLV that will enclose occurrences of that specific Extended Option. D. Eastlake [Page 7] INTERNET-DRAFT Proposed TRILL Header Options 3.4 Vendor Options TLV This option is provided to supply a standard method for the specification of vendor specific options in a TRILL Header. Vendor identity and specific options are encoded into the value associated with the option. Since vendor specific options could require any valid combination of the IE, NC, and MT bits, they inherit they inherit these from enclosing Vendor Options TLV. Each vendor specific option starts with three bytes of OUI followed by a forth byte that has, in the bottom four bits, the length of the additional value of the vendor specific option in bytes. The top four bits of this fourth byte are available for vendor use, for example, to distinguish different options. Transit RBridges MUST NOT re-order the vendor specific options within an ingress-to-egress Vendor Options TLV. The Vendor Options fields and flags are as follows: o Type is 0xTBD. o Length is variable with a minimum of 4. o IE, NC, and MT can be any valid combination producing several variations of this option. 3.5 Authentication TLV Option [The write-up of this option is not complete.] TRILL provides an authentication option that builds on the IS-IS security keying [RFC5304] [RFC5310] and can be applied to frames with a TRILL Header. The first octet of the option value is the same algorithm selection code as for the IS-IS Authentication TLV (IS-IS TLV #). The value length for the option is variable and depends on the algorithm in the same way as the value in the IS-IS security TLV. Algorithm zero indicates a plain text password which must be configured in code which generates and checks this TLV and is NOT RECOMMENDED. Thus far, other algorithms have indicated HMAC signing of a canonical form of the message using a shared secret that must likewise be configured. This option can appear up to twice in a frame, once for ingress-to- egress authentication and once for hop-by-hop authentication. D. Eastlake [Page 8] INTERNET-DRAFT Proposed TRILL Header Options 3.5.1 Authentication Option Computations For algorithms which depend on the value of the frame (i.e., all strong authentication algorithms), the frame must be canonicalized before the authentication code is computed or verified. This canonicalization is logically done by copying the frame starting with the TRILL Header and modifying the copy as follows: 1. Set the TRILL Header Hop Count to zero. 2. Clear the octets of the Security Option after the algorithm selection code. 3. For all mutable options, setting the option Length to zero and remove any value octets. 4. If an ingress-to-egress authentication code is being computed, since hop-by-hop options can be added or deleted in transit, all hop-by-hop options must be removed from the frame copy. When a critical hop-by-hop option is removed, any required adjustments must be made in the remainder of the frame, as if it was about to be forwarded to an RBridge that did not support that hop-by-hop critical option. 5. Adjust the TRILL Header Op-Length downward as necessary to make it correct for the other adjustments made in the frame copy. The authentication code is then calculated using this copy and either inserted into the authentication option in the real frame for transmission or compared against the authentication code in the real frame for verification. 3.5.2 Authentication Option Fields and Flags The security option fields and flags are as follows: o Type is 0xTBD. o Length MUST be at least 1. o IE is variable. There may be an ingress-to-egress or hop-by-hop security option in a frame or both. o NC and MT MUST be zero. This is a critical, immutable option. D. Eastlake [Page 9] INTERNET-DRAFT Proposed TRILL Header Options 4. Acknowledgement The Port ID option was suggested as part of the TRILL Header by Silvano Gai. 5. Security Considerations -- TBD -- 6. IANA Considerations -- See IANA Considerations sub-sections above. -- D. Eastlake [Page 10] INTERNET-DRAFT Proposed TRILL Header Options 7. Normative References [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFCopt] - D. Eastlake, A. Ghanwani, V. Manral, and C. Bestler, "RBridges: TRILL Header Options", draft-ietf-trill-rbridge- options, work in progress, June 2010. 8. Informative References [RFC5304] - Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 5304, October 2008. [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. D. Eastlake [Page 11] INTERNET-DRAFT Proposed TRILL Header Options Authors' Addresses Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 tel: +1-508-333-2270 email: d3e3e3@gmail.com D. Eastlake [Page 12] INTERNET-DRAFT Proposed TRILL Header Options Copyright and IPR Provisions Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. D. Eastlake [Page 13]