< draft-ietf-trill-directory-assisted-encap-10.txt   draft-ietf-trill-directory-assisted-encap-11.txt >
INTERNET-DRAFT Linda Dunbar INTERNET-DRAFT Linda Dunbar
Intended status: Proposed Standard Donald Eastlake Intended status: Proposed Standard Donald Eastlake
Huawei Huawei
Radia Perlman Radia Perlman
Dell/EMC Dell/EMC
Expires: September 3, 2018 March 4, 2018 Expires: September 7, 2018 March 8, 2018
Directory Assisted TRILL Encapsulation Directory Assisted TRILL Encapsulation
<draft-ietf-trill-directory-assisted-encap-10.txt> <draft-ietf-trill-directory-assisted-encap-11.txt>
Abstract Abstract
This draft describes how data center networks can benefit from non- This draft describes how data center networks can benefit from non-
RBridge nodes performing TRILL encapsulation with assistance from a RBridge nodes performing TRILL encapsulation with assistance from a
directory service. directory service.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 21 skipping to change at page 2, line 21
3. Directory Assistance to Non-RBridge.....................5 3. Directory Assistance to Non-RBridge.....................5
4. Source Nickname in Encapsulation by Non-RBridge Nodes...8 4. Source Nickname in Encapsulation by Non-RBridge Nodes...8
5. Benefits of Non-RBridge Performing TRILL Encapsulation..9 5. Benefits of Non-RBridge Performing TRILL Encapsulation..9
5.1. Avoid Nickname Exhaustion Issue.......................9 5.1. Avoid Nickname Exhaustion Issue.......................9
5.2. Reduce MAC Tables for Switches on Bridged LANs........9 5.2. Reduce MAC Tables for Switches on Bridged LANs........9
6. Manageability Considerations...........................11 6. Manageability Considerations...........................11
7. Security Considerations................................11 7. Security Considerations................................11
8. IANA Considerations....................................12 8. IANA Considerations....................................13
Normative References......................................13 Normative References......................................14
Informative References....................................13 Informative References....................................14
Acknowledgments...........................................13 Acknowledgments...........................................14
Authors' Addresses........................................14 Authors' Addresses........................................15
INTERNET-DRAFT Directory Assisted TRILL Encap INTERNET-DRAFT Directory Assisted TRILL Encap
1. Introduction 1. Introduction
This document describes how data center networks can benefit from This document describes how data center networks can benefit from
non-RBridge nodes performing TRILL encapsulation with assistance from non-RBridge nodes performing TRILL encapsulation with assistance from
a directory service and specifies a method for them to do so. a directory service and specifies a method for them to do so.
[RFC7067] and [RFC8171] describe the framework and methods for edge [RFC7067] and [RFC8171] describe the framework and methods for edge
skipping to change at page 11, line 16 skipping to change at page 11, line 16
6. Manageability Considerations 6. Manageability Considerations
Directory assistance [RFC8171] is required to make it possible for a Directory assistance [RFC8171] is required to make it possible for a
non-TRILL node to pre-encapsulate packets destined towards remote non-TRILL node to pre-encapsulate packets destined towards remote
RBridges. TRILL-ENs have the same configuration options as any pull RBridges. TRILL-ENs have the same configuration options as any pull
directory client. See Section 4 of [RFC8171]. directory client. See Section 4 of [RFC8171].
7. Security Considerations 7. Security Considerations
If the TRILL-ENs are not trusted, they can forge arbitrary ingress
and egress nicknames in the TRILL Headers of the TRILL Data packets
they construct. Decapsulating at egress RBridges that believe such a
forged ingress nickname would send future traffic destined for the
inner source MAC address of the TRILL Data frame to the wrong edge
RBridge if data plane learning is in use. Because of this, an
RBridge port should not be configured to accept encapsulated TRILL
data frame on a link were it does not have an RBridge adjacency
unless the end stations on that link are trusted.
As with any end station, TRILL-ENs can forge the outer MAC addresses
of packets they send (See Sectin 6 of [RFC6325].) Because they pre-
encapsulate, they can also forge inner MAC addresses.
The pre-encapsulation performed by TRILL-ENs also means they can send
data in any VLAN which means that must be trusted in order to enforce
a security policy based on VLANs. (See Section 6.1 of [RFC6325].)
Use of directory assisted encapsulation by TRILL-ENs essentially
involves those TRILL-ENs spoofing edge RBridges to which they are
connected, which is another reason that TRILL-ENs should be trusted
nodes. Such spoofing cannot cause persistently looping traffic
because TRILL has a hop count in the TRILL header [RFC6325] so that,
should there be a loop, a TRILL packet caught in that loop (i.e., an
encapsulated frame) will be discarded. (In the potentially more
dangerous case of multi-destination packets, as compared with known
unicast, where copies could multiply due to forks in the distribution
tree, a Reverse Path Forwarding Check is also used [RFC6325] to
discard packets that appear to be on the wrong link or when there is
disagreement about the distribution tree.)
The mechanism described in this document requires TRILL-ENs to be The mechanism described in this document requires TRILL-ENs to be
aware of the MAC address(es) of the TRILL edge RBridge(s) to which aware of the MAC address(es) of the TRILL edge RBridge(s) to which
the TRILL-EN is attached and the egress RBridge nickname from which the TRILL-EN is attached and the egress RBridge nickname from which
the destination of the packets is reachable. With that information, the destination of the packets is reachable. With that information,
TRILL-ENs can learn a substantial amount about the topology of the TRILL-ENs can learn a substantial amount about the topology of the
TRILL domain. Therefore, there could be a potential security risk TRILL domain. Therefore, there could be a potential security risk
when the TRILL-ENs are not trusted or are compromised. In addition, when the TRILL-ENs are not trusted or are compromised.
if the path between the directory and the TRILL-ENs are attacked,
INTERNET-DRAFT Directory Assisted TRILL Encap
If the path between the directory and the TRILL-ENs is attacked,
false mappings can be sent to the TRILL-EN causing packets from the false mappings can be sent to the TRILL-EN causing packets from the
TRILL-EN to be sent to wrong destinations, possibly violating TRILL-EN to be sent to wrong destinations, possibly violating
security policy. Therefore, a combination of authentication and security policy as to which end stations should receive what data.
encryption is RECOMMENDED between the Directory and TRILL-EN. The Therefore, a combination of authentication and encryption is
entities involved will need to properly authenticate with each other, RECOMMENDED between the Directory and TRILL-EN. The entities involved
provide session encryption, maintain security patch levels, and will need to properly authenticate with each other, provide session
configure their systems to allow minimal access and running processes encryption, maintain security patch levels, and configure their
to protect sensitive information. systems to allow minimal access and running processes to protect
sensitive information.
Use of directory assisted encapsulation by TRILL-ENs essentially For added security against the compromise of data due to its mis-
involves those TRILL-ENs spoofing edge RBridges to which they are delivery for any reason, including the above, end-to-end encryption
connected, which is another reason that TRILL-ENs should be trusted and authentication should be considered; that is, encryption and
nodes. Such spoofing cannot cause looping traffic because TRILL has a authentication from source end station to destination end station.
hop count in the TRILL header [RFC6325] so that, should there be a
loop, a TRILL packet caught in that loop (i.e., an encapsulated
frame) will be discarded. (In the potentially more dangerous case of
multi-destination packets, as compared with known unicast, where
copies could multiply due to forks in the distribution tree, a
Reverse Path Forwarding Check is also used [RFC6325] to discard
packets that appear to be on the wrong link or when there is
disagreement about the distribution tree.)
For Pull Directory and TRILL ES-IS security considerations, see For Pull Directory and TRILL ES-IS security considerations, see
[RFC8171]. [RFC8171].
For general TRILL security considerations, see [RFC6325].
INTERNET-DRAFT Directory Assisted TRILL Encap INTERNET-DRAFT Directory Assisted TRILL Encap
8. IANA Considerations 8. IANA Considerations
This document requires no IANA actions. RFC Editor: please remove This document requires no IANA actions. RFC Editor: please remove
this section before publication. this section before publication.
INTERNET-DRAFT Directory Assisted TRILL Encap INTERNET-DRAFT Directory Assisted TRILL Encap
Normative References Normative References
skipping to change at page 13, line 48 skipping to change at page 15, line 5
Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013,
<https://www.rfc-editor.org/info/rfc7067>. <https://www.rfc-editor.org/info/rfc7067>.
Acknowledgments Acknowledgments
The following are thanked for their contributions: The following are thanked for their contributions:
Igor Gashinsky Igor Gashinsky
Ben Nevin-Jenkins Ben Nevin-Jenkins
The document was prepared in raw nroff. All macros used were defined
within the source file.
INTERNET-DRAFT Directory Assisted TRILL Encap INTERNET-DRAFT Directory Assisted TRILL Encap
Authors' Addresses Authors' Addresses
Linda Dunbar Linda Dunbar
Huawei Technologies Huawei Technologies
5340 Legacy Drive, Suite 175 5340 Legacy Drive, Suite 175
Plano, TX 75024, USA Plano, TX 75024, USA
Phone: +1-469-277-5840 Phone: +1-469-277-5840
 End of changes. 11 change blocks. 
32 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/