Skip to main content

TRILL: Link Security
draft-eastlake-trill-link-security-03

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 2016-04-12
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-03
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
              <draft-eastlake-trill-link-security-03.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. 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: <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. 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, <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 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, <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>.

   [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, <http://www.rfc-editor.org/info/rfc7178>.

Informative References

   [RFC1994] - Simpson, W., "PPP Challenge Handshake Authentication
         Protocol (CHAP)", RFC 1994, August 1996, <http://www.rfc-
         editor.org/info/rfc1994>.

   [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] - 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]