TRILL: Link Security
draft-eastlake-trill-link-security-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Donald E. Eastlake 3rd , Dacheng Zhang | ||
| Last updated | 2015-03-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-eastlake-trill-link-security-00
INTERNET-DRAFT Donald Eastlake
Updates: 6325, 6361, 7173 Huawei
Intended status: Proposed Standard Dacheng Zhang
Alibaba
Expires: September 8, 2015 March 9, 2015
TRILL: Link Security
<draft-eastlake-trill-link-security-00.txt>
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 taking into
account performance considerations. It updates RFC 6325, 6361, and
7173. It requires that all TRILL packets between links ports capable
of encryption at line speed MUST default to being encrypted. [This is
an 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: <rbridge@postel.org>.
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. Ethernet Links..........................................6
3.1 Between TRILL Switches.................................6
3.1.1 Ethernet Link Security Maintenance...................7
3.2 Ethernet Security to End Stations......................8
4. PPP Links..............................................11
5. Pseudowire Links.......................................12
6. Security Considerations................................13
7. IANA Considerations....................................13
Normative References......................................14
Informative References....................................15
Acknowledgments...........................................15
Authors' Addresses........................................16
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL: Link Security
1. Introduction
[This is an early partial draft.]
The TRILL (Transparent Interconnection of Lots of Links or Tuneled
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.
TRILL generally uses an existing link security method specified for
the technology of the link in question. 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 document specifies security recommendations for TRILL over
Ethernet [RFC6325], TRILL over PPP [RFC6361], and transport of TRILL
by pseudowires [RFC7173], in Sections 3, 4, and 5 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 encryption requirement
summarized in Section 1.1.
[TRILL-IP] is expected to cover TRILL security over IP links.
1.1 Encryption Requirement and Adjacency
This document requires that all TRILL packets between 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 encrption 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.
If line speed 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 any reduction in performance.
D. Eastlake, et al [Page 3]
INTERNET-DRAFT TRILL: Link Security
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. 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.
3.1 Between TRILL Switches
TRILL switch Ethernet ports MUST implement MACSEC. 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. Typically, the TRILL switch
ports at the ends of such a path would be unable to negotiate
security and agree on keys so, in cases where encryption and
authenication are required, they 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 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,
that would also be sent within MACSEC. Typically only the [802.1X]
messages used to establish and maintain MACSEC are sent unsecured.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL: Link Security
+---------------------------------------+
| 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 ...
3.1.1 Ethernet Link Security Maintenance
[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 Ethernet Security to End Stations
MACSEC may 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.
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 TRILL switch 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 8]
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 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 9]
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 10]
INTERNET-DRAFT TRILL: Link Security
4. 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...
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL: Link Security
5. 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 12]
INTERNET-DRAFT TRILL: Link Security
6. 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].
7. IANA Considerations
This document requires no IANA actions.
D. Eastlake, et al [Page 13]
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, <http://www.rfc-editor.org/info/rfc20>.
[RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994, <http://www.rfc-
editor.org/info/rfc1661>.
[RFC1968] - Meyer, G., "The PPP Encryption Control Protocol (ECP)",
RFC 1968, June 1996, <http://www.rfc-editor.org/info/rfc1968>.
[RFC2119] -Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc5869>
[RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May
2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011, <http://www.rfc-
editor.org/info/rfc6325>.
D. Eastlake, et al [Page 14]
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, <http://www.rfc-
editor.org/info/rfc6361>.
[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, <http://www.rfc-
editor.org/info/rfc7173>.
[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, <http://www.rfc-
editor.org/info/rfc7177>.
Informative References
[RFC1994] - Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996, <http://www.rfc-
editor.org/info/rfc1994>.
[RFC2153] - W. Simpson, "PPP Vendor Extensions," RFC 2153, May 1997
[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, <http://www.rfc-
editor.org/info/rfc7258>.
[RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, December 2014, <http://www.rfc-
editor.org/info/rfc7435>.
[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] -
Acknowledgments
The authors thank the following for their comments and help:
D. Eastlake, et al [Page 15]
INTERNET-DRAFT TRILL: Link Security
tbd
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 16]
INTERNET-DRAFT TRILL: Link Security
Copyright and IPR Provisions
Copyright (c) 2015 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 17]