INTERNET-DRAFT Donald Eastlake Updates: 6325, 6361, 7173 Huawei Intended status: Proposed Standard Dacheng Zhang Alibaba Expires: October 15, 2016 April 12, 2016 TRILL: Link Security Abstract The TRILL protocol supports arbitrary link technologies between TRILL switches, both point-to-point and broadcast links, and supports Ethernet links between edge TRILL switches and end stations. Communications links are constantly under attack by criminals and national intelligence agencies as discussed in RFC 7258. Link security is an important element of security in depth, particularly for links that are not entirely under the physical control of the TRILL network operator or that include device which may have been compromised. This document specifies link security recommendations for TRILL over Ethernet, PPP, and pseudowire links. It updates RFC 6325, RFC 6361, and RFC 7173. It requires that link encryption MUST be implemented and that all TRILL Data packets between TRILL switch ports capable of encryption at line speed MUST default to being encrypted. [This is a early partial draft.] 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 DNSEXT 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, et al [Page 1] INTERNET-DRAFT TRILL: Link Security Table of Contents 1. Introduction............................................3 1.1 Encryption Requirement and Adjacency...................3 1.2 Terminology and Acronyms...............................4 2. Link Security Default Keying............................5 3. Link Security Specifics.................................6 3.1 Ethernet Links.........................................6 3.2 PPP Links..............................................8 3.3 Pseudowire Links.......................................8 4. Edge-to-Edge Security...................................9 5. Security Considerations................................11 6. IANA Considerations....................................11 Normative References......................................12 Informative References....................................13 Acknowledgments...........................................14 Appendix A: Summary of Changes to RFCs 6325, 6361, 7173...15 Appendix B: Ethernet Secrity to End Stations..............16 Authors' Addresses........................................19 D. Eastlake, et al [Page 2] INTERNET-DRAFT TRILL: Link Security 1. Introduction The TRILL (Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer) protocol supports arbitrary link technologies including both point-to-point and broadcast links and supports Ethernet links between edge TRILL switches and end stations. Communications links are constantly under attack by criminals and national intelligence agencies as discussed in [RFC7258]. Link security in an important element of security in depth for links, paticularly those that are not entirely under the physical control of the TRILL network operator or that include device which may have been compromised, that is, pretty much for all links. TRILL generally uses an existing link security method specified for the technology of the link in question. This document specifies link security recommendations for TRILL over Ethernet [RFC6325], TRILL over PPP [RFC6361], and transport of TRILL by pseudowires [RFC7173], in Sections 3.1, 3.2, and 3.3 respectively. Although the Security Considerations sections of these RFCs mention link security, this document goes further, updating these RFCs as decribed in Appendix A and imposing the new mandatory encryption implementation requirements summarized in Section 1.1. [TRILL-IP] will cover TRILL security over IP links and any other future TRILL-over-X drafts are expected to cover security for TRILL links using technology X. Edge-to-edge security, fron imgress to egress TRILL switch, provides another level of security and is covered in Section 4. TRILL provides autoconfiguration assistance and default keying material, under most circumstances, to support the TRILL goal of having a minimal or zero configuration default. Where better security is not available, TRILL supports opportunistic security [RFC7435]. [This is a partial early draft.] 1.1 Encryption Requirement and Adjacency This document requires that all TRILL data packets between adjacent TRILL switch ports that are capable of encryption at line speed MUST default to being encrypted and authenticated. It MUST require explicit configuration in such cases for the ports to communicate unencrypted or unsecured. Line speed encryption and authentication usually requires hardware assist but there are cases with slower ports and higher powered switch processors where it can be accomplished in sofware. D. Eastlake, et al [Page 3] INTERNET-DRAFT TRILL: Link Security If line speed link encryption and authentication is not available for communication between TRILL switch ports, it MUST still be possible to configure the TRILL switches and ports involved to encrypt and authenticate all TRILL packets sent for cases where the security provided outweighs the reduction in performance. 1.2 Terminology and Acronyms This document uses the acronyms and terms defined in [RFC6325], some of which are repeated below for convenience, and additional acronyms and terms listed below. HKDF: Hash based Key Derivation Function [RFC5869]. Link: The means by which adjacent TRILL switches are connected. May be various technologies and in the common case of Ethernet, can be a "bridged LAN", that is to say, some combination of Ethernet links with zero or more bridges, hubs, repeaters, or the like. MACSEC: Media Access Control (MAC) Security. IEEE Std 802.1AE-2006. MPLS: Multi-Protocol Label Switching. PPP: Point-to-point protocol [RFC1661]. RBridge: An alternative name for a TRILL switch. TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer. TRILL switch: A device implementing the TRILL protocol. An alternative name for an RBridge. 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, et al [Page 4] INTERNET-DRAFT TRILL: Link Security 2. Link Security Default Keying In some cases, it is possible to use keying material derived from the [RFC5310] IS-IS keying material already in place. In such cases, the two byte [RFC5310] Key ID identifies the IS-IS keying material. The keying material actually used in the link security protocol is derived from the IS-IS keying material as follows: HKDF-Expand-SHA256 ( IS-IS-key, "TRILL Link" | custom, L ) where "|" indicates concatenation, HKDF is the Hash base Key Derivation Function in [RFC5869], SHA256 is as in [RFC6234], IS-IS- key is the input keying material, "TRILL Link" is the 10-character ASCII [RFC20] string indicated, "custom" is a byte string dependeng on the link security protocol being used, and L is the length of output keying material needed. D. Eastlake, et al [Page 5] INTERNET-DRAFT TRILL: Link Security 3. Link Security Specifics The following subsection discuss TRILL link security for various technologies. 3.1 Ethernet Links TRILL over Ethernet is specified in [RFC6325] with some additional material on Ethernet link MTU in [rfc7180bis]. Link security between TRILL switch Ethernet ports conforms to IEEE Std 802.1AE-2006 [802.1AE] as amended by IEEE Std 802.1AEbn-2011 [802.1AEbn] and IEEE Std 802.1AEbw-2013 [802.1AEbw]. This security is referred to as MACSEC. TRILL switch Ethernet ports MUST implement MACSEC even if it is implemented in software. When TRILL switch ports are directly connected by Ethernet with no intervening customer bridges, for example by a point to point Ethernet link, MACSEC between them operates as specified herein. There can be intervening Provider Bridges or other forms of transparent Ethernet tunnels. However, if there are one or more customer bridges or similar devices in the path, MACSEC at the TRILL switch port will peer with the nearest such bridge port. This reaults, from the point of view of MACSEC, with a two or more hop path, although it is one TRILL hop. Typically, the TRILL switch ports at the ends of such a path would be unable to negotiate security and agree on keys because of the intervening customer bridge. In such cases where encryption and authenication are required, the adjacent TRILL switch ports would be unable to establish IS-IS communication and would not form an adjacency [RFC7177]. However, it may be possible to configure such bridge ports and distribute such keying material or the like to them so that encryption and authentication can be established on all hops of such mulit-hop Ethernet paths. Methods for accomplishing such distribution to devices other than TRILL switches are beyond the scope of this document. When MACSEC is established between adjacent TRILL switch ports, the frames are as shown in Figure 1. The optional VLAN tagging shown is superfluous in the case of TRILL Data and IS-IS packets. Unless there are VLAN sensitive devices intervening between the TRILL switch ports, or possibly attached to the link between those ports, TRILL Data and IS-IS packets secured with MACSEC SHOULD generally be sent untagged for efficiency. Of course there may be other Ethernet control frames, such as link aggregation control messages or priority based flow control messages, D. Eastlake, et al [Page 6] INTERNET-DRAFT TRILL: Link Security that would also be sent within MACSEC. Typically only the [802.1X] messages used to establish and maintain MACSEC are sent unsecured. +---------------------------------------+ | Outer.MacDA (6 bytes) | +---------------------------------------+ | Outer.MacSA (6 bytes) | +---------------------------------------+ | MACSEC Tag (8 or 16 bytes) | +---------------------------------------+ | Encrypted | | +-------------------------------+ | | | Optional VLAN Tag (4 bytes) | | | +-------------------------------+ | | | TRILL or L2-IS-IS Ethertype | | | +-------------------------------+ | | | TRILL Data or IS-IS Payload | | | +-------------------------------+ | +---------------------------------------+ | ICV (8 or 16 bytes | +---------------------------------------+ | FCS (4 bytes) | +---------------------------------------+ Figures 1. MACSEC Between TRILL Switch Ports Outer.MacDA: 48-bit destination MAC address Outer.MacSA: 48-bit source MAC address MACSEC Tag: See further description below. Encrypted: The encrypted data ICV: The MACSEC Intergrity Check Value FCS: Frame Check Sequence. The strucutre of a MACSEC Tag is as follows: tbd ... [802.1X] is used to establish keying and algorithms for Ethernet link security ... tbd ... D. Eastlake, et al [Page 7] INTERNET-DRAFT TRILL: Link Security 3.2 PPP Links TRILL over PPP is specified in [RFC6361]. Currently specified native PPP security does not meet modern security standards. However, true PPP over HDLC is relatively uncommon today and PPP is normally being conveyed by another protocol, such as PPP over Ethernet or PPP over IP. In those cases it is RECOMMENDED that Ethernet security as described in Section 3 or IP security as described in [TRILL-IP] be used to secure PPP between TRILL switch ports. If it is necessary to use native PPP security [RFC1968] [RFC1994] ...tbd... 3.3 Pseudowire Links TRILL transport over pseudowires is specified in [RFC7173]. No native security is provided for pseudowires as such; however, they are, by definition, carried by some PSN (Packet Switched Network). Link security must be provided by this PSN or by lower level protocols. This PSN is typically an MPLS or IP PSN. In the case of a pseudowire over IP, security SHOULD be provided as is expected to be specified in [TRILL-IP]. If that is not possible but the IP path is only one IP hop, then it may be possible to provide link security at the layer of the link protocol supporting that hop, such as Ethernet (Section 3) or PPP (Section 4). In the case of a pseudowire over MPLS, MPLS also does not have a native security scheme. Thus, security must be provided at the link layer being used, for example Ethernet (Section 3) or IP [TRILL-IP]. D. Eastlake, et al [Page 8] INTERNET-DRAFT TRILL: Link Security 4. Edge-to-Edge Security Edge-to-edge security can be applied to TRILL data packets between the TRILL switch where they are ingressed or created to the TRILL switch where they are egressed or consumed. The edge-to-edge path is viewed as a one hop virtual link from before TRILL encapsulation to after TRILL decapsulation. MACSEC is used on this pseudolink. If default keying is used, it is as specified in Section 2 above with the value of "custom" in Section 2 as specified below, depending on whether the TRILL data packet is TRILL unicast or TRILL multi- destination: Unicast: custom = "Uni" | ingress System ID | egress System ID Multi-destination: custom = "Multi" | Data Label where "|" indicates concatenation, the quoted string "Uni" and "Multi" represent those 3 and 5 character ASCII [RFC20] strings, respectively, ingress System ID and egress System ID are the 6-byte IS-IS System ID of the origin and destination TRILL switches, and Data Label is the contents of the 4-byte (C-VLAN Ethertype plus VLAN ID) or 8-bytes (FGL Ethertypes and value) data labeling area of the TRILL packet with priority/DEI fields set to zero. Where keying is to be negotiated between a pair of TRILL switches for edge-to-edge unicast security, the IEEE 802.1X messages involved are transmitted inside unicast RBridge Channel [RFC7178] messages using RBridge Channel protocol number TBD1. Support for edge-to-edge encryption is indicated by a TRILL switch advertising support for this RBridge Channel protocol. In such 802.1X messages, the System IDs of the TRILL switches are used as their "MAC Addresses". 802.1X in turn uses the Extensible Authentication Protocol (EAP [RFC3748]). tbd ... For edge-to-edge security, the MACSEC tag is inserted in the payload frame and the Inner.DataLabel (VLAN or FGL) is duplicated so that a TRILL Data packet on a transit link (which might not be an Ethernet link) is structured as shown below. The unencrypted copy of the Inner.DataLabel is needed for two reasons: (1) to avoid rejection by and transit RBridges the packet passes through that are sensitive to the Ethertype appearing immediately after the Inner.MacSA and would otherwise discard the packet and (2) to assure proper distribution if the packet is multi-destination. The innter encrypte D. Eastlake, et al [Page 9] INTERNET-DRAFT TRILL: Link Security +---------------------------------------+ | Link Header | +---------------------------------------+ | TRILL Header | +---------------------------------------+ | Inner.MacDA | +---------------------------------------+ | Inner.MacSA | +---------------------------------------+ | Inner.DataLabel | +---------------------------------------+ | MACSEC Tag Edge-to-Edge | +---------------------------------------+ | Encrypted | | +-------------------------------+ | | | Inner.DataLabel | | | +-------------------------------+ | | | Payload Ethertype | | | +-------------------------------+ | | | Payload | | | +-------------------------------+ | +---------------------------------------+ | ICV (8 or 16 bytes | +---------------------------------------+ | Link Trailer | +---------------------------------------+ D. Eastlake, et al [Page 10] INTERNET-DRAFT TRILL: Link Security 5. Security Considerations This document is entirely about TRILL link security for Etherent, PPP, and pseudowire TRILL links. See sections of this document on those particular link technologies. For general TRILL Security Considrations, see [RFC6325]. 6. IANA Considerations IANA is requested to allocate a new RBridge Channel protocol number TBD1 for tunneled 802.1X messages supporting negotiated keys for unicast edge-to-edge security. D. Eastlake, et al [Page 11] INTERNET-DRAFT TRILL: Link Security Normative References [802.1AE] - IEEE Std 802.1AE-2006, IEEE Standard for Local and metropolitan networks / Media Access Control (MAC) Security, 18 August 2006. [802.1AEbn] - IEEE Std 802.1AEbn-2011, IEEE Standard for Local and metropolitan networks / Media Access Control (MAC) Security / Galois Counter Mode - Advanced Encryption Standard - 256 (GCM- AES-256) Cipher Suite, 14 October 2011. [802.1AEbw] - IEEE Std 802.1AEbw-2014, IEEE Standard for Local and metropolitan networks / Media Access Control (MAC) Security / Extended Packet Numbering, 12 February 2014 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, . [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994, . [RFC1968] - Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996, . [RFC2119] -Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5226] - T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," BCP 26 and RFC 5226, May 2008 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, . D. Eastlake, et al [Page 12] INTERNET-DRAFT TRILL: Link Security [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011, . [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, May 2014, . [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014, . [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, . Informative References [RFC1994] - Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996, . [RFC3748] - B. Aboba, et al., "Extensible Authentication Protocol (EAP)," RFC 3748, June 2004 [RFC7258] - Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, . [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, December 2014, . [rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A., Ghanwani, A., and S. Gupta, "TRILL: Clarifications, Corrections, and Updates", draft-ietf-trill-rfc7180bis, work in progress. [TRILL-IP] - Cullen, M., et al., "Transparent Interconnection of Lots of Links (TRILL) over IP", draft-ietf-trill-over-ip, work in progress. D. Eastlake, et al [Page 13] INTERNET-DRAFT TRILL: Link Security Acknowledgments The authors thank the following for their comments and help: tbd D. Eastlake, et al [Page 14] INTERNET-DRAFT TRILL: Link Security Appendix A: Summary of Changes to RFCs 6325, 6361, 7173 tbd ... D. Eastlake, et al [Page 15] INTERNET-DRAFT TRILL: Link Security Appendix B: Ethernet Secrity to End Stations MACSEC could be used between end stations and their adjacent TRILL switch(es) or end-to-end between end stations or both. Since TRILL does not impose administrative requirements on end stations, the choice of keying and crypto suite are beyond the scope of this document. However, some informative explanation and diagrams are provided below to clarify how this might be done. The end station must be properly configured to know if it should apply MACSEC to secure its connection to an edge TRILL switch or to remote end stations or both. The Figure below show an Ethernet frame between a end station and the adjacent edge RBridge secured by MACSEC. +---------------------------------------+ | Outer.MacDA (6 bytes) | +---------------------------------------+ | Outer.MacSA (6 bytes) | +---------------------------------------+ | MACSEC Tag End Station to TRILL edge | +---------------------------------------+ | Encrypted | | +-------------------------------+ | | | Optional VLAN Tag (4 bytes) | | | +-------------------------------+ | | | Payload Ethertype | | | +-------------------------------+ | | | Payload | | | +-------------------------------+ | +---------------------------------------+ | ICV (8 or 16 bytes | +---------------------------------------+ | FCS (4 bytes) | +---------------------------------------+ The Figure below shows an Ethernet frame between an end station and an adjacent edge RBridge where MACSEC is being used end-to-end between that end station and remote end stations. D. Eastlake, et al [Page 16] INTERNET-DRAFT TRILL: Link Security +---------------------------------------+ | Outer.MacDA (6 bytes) | +---------------------------------------+ | Outer.MacSA (6 bytes) | +---------------------------------------+ | Optional Outer.VLAN | +---------------------------------------+ | MACSEC Tag End Station to End Station| +---------------------------------------+ | Encrypted | | +-------------------------------+ | | | Payload Ethertype | | | +-------------------------------+ | | | Payload | | | +-------------------------------+ | +---------------------------------------+ | ICV (8 or 16 bytes | +---------------------------------------+ | FCS (4 bytes) | +---------------------------------------+ The Figure below shows an Ethernet frame between an end station and an adjacent edge RBridge where MACSEC is being used end-to-end between that end station and a remote end stations and, in addition, an outer application of MACSEC is securing traffic between the end station and the adjacent edge RBridge port. D. Eastlake, et al [Page 17] INTERNET-DRAFT TRILL: Link Security +---------------------------------------------+ | Outer.MacDA (6 bytes) | +---------------------------------------------+ | Outer.MacSA (6 bytes) | +---------------------------------------------+ | MACSEC Tag End Station to TRILL edge | +---------------------------------------------+ | Outer.Encrypted | | +--------------------------------------+ | | | Optional VLAN Tag (4 bytes) | | | +--------------------------------------+ | | | MACSEC Tag End Station to End Station| | | +--------------------------------------+ | | | Inner.Encrypted | | | | +-------------------------------+ | | | | | Payload Ethertype | | | | | +-------------------------------+ | | | | | Payload | | | | | +-------------------------------+ | | | +--------------------------------------+ | | | Inner.ICV (8 or 16 bytes) | | | +--------------------------------------+ | +---------------------------------------------+ | Outer.ICV (8 or 16 bytes) | +---------------------------------------------+ | FCS (4 bytes) | +---------------------------------------------+ D. Eastlake, et al [Page 18] INTERNET-DRAFT TRILL: Link Security Authors' Addresses Donald Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Dacheng Zhang Alibaba Beijing, Chao yang District P.R. China Email: dacheng.zdc@alibaba-inc.com D. Eastlake, et al [Page 19] INTERNET-DRAFT TRILL: Link Security Copyright and IPR Provisions Copyright (c) 2016 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, et al [Page 20]