Internet DRAFT - draft-eastlake-trill-link-security
draft-eastlake-trill-link-security
INTERNET-DRAFT Donald Eastlake
Updates: 6325, 6361, 7173 Dacheng Zhang
Intended status: Proposed Standard Huawei
Expires: March 23, 2018 September 24, 2017
TRILL: Link Security
<draft-eastlake-trill-link-security-06.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 [RFC6325] [RFC7780] 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 or, if authenticaion is
not available, at least to be oportunisticly encrypted (encrypted
without authentication of endpoints). It MUST require explicit
configuration in such cases to allow the ports to communicate
unencrypted or unsecured. Line speed encryption and authentication
D. Eastlake, et al [Page 3]
INTERNET-DRAFT TRILL: Link Security
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 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. This is appropriate 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, or repeaters.
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-keying-material,
"TRILL Link" | custom, L )
where "|" indicates concatenation, HKDF is the Hash base Key
Derivation Function in [RFC5869], SHA256 is as in [RFC6234], IS-IS-
keying-material 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 [RFC7780].
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:
to be completed ...
[802.1X] is used to establish keying and algorithms for Ethernet link
security ... to be completed ...
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] ...
to be completed ...
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]).
to be completed ...
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
any 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 inner encrypted Data Label is
securely communicated to the egress TRILL swtich.
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 about TRILL hop link security for Etherent, PPP, and
pseudowire TRILL links and edge-to-edge security for a TRILL campus.
See sections of this document on those particular topics.
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>.
[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>.
[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>.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT TRILL: Link Security
[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>.
[RFC8126] - Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, RFC
8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-
editor.org/info/rfc8126>.
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>.
[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection of
Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.
[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
Huawei Technologies
P.R. China
Email: dacheng.zhang@huawei.com
D. Eastlake, et al [Page 19]
INTERNET-DRAFT TRILL: Link Security
Copyright and IPR Provisions
Copyright (c) 2017 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]
