< draft-ietf-trill-directory-assisted-encap-09.txt   encap27fftoc.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: July 17, 2018 January 18, 2018 Expires: September 6, 2018 March 7, 2018
Directory Assisted TRILL Encapsulation Directory Assisted TRILL Encapsulation
<draft-ietf-trill-directory-assisted-encap-09.txt> <draft-ietf-trill-directory-assisted-encap-10.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
The mechanism described in this document requires TRILL-ENs to be If the TRILL-ENs are not trusted, they can forge arbitrary ingress
aware of the MAC address(es) of the TRILL edge RBridge(s) to which and egress nicknames in the TRILL Headers of the TRILL Data packets
the TRILL-EN is attached and the egress RBridge nickname from which they construct. Decapsulating at egress RBridges that believe such a
the destination of the packets is reachable. With that information, forged ingress nickname would send future traffic destined for the
TRILL-ENs can learn a substantial amount about the topology of the inner source MAC address of the TRILL Data frame to the wrong edge
TRILL domain. Therefore, there could be a potential security risk RBridge if data plane learning is in use. Because of this, an
when the TRILL-ENs are not trusted. In addition, if the path between RBridge port should not be configured to accept encapsulated TRILL
the directory and the TRILL-ENs are attacked, false mappings can be data frame on a link were it does not have an RBridge adjacency
sent to the TRILL-EN causing packets from the TRILL-EN to be sent to unless the end stations on that link are trusted.
wrong destinations, possibly violating security policy. Therefore, a
combination of authentication and encryption should be used between
the Directory and TRILL-EN. The entities involved will need to
properly authenticate with each other to protect sensitive
information.
Use of directory assisted encapslation by TRILL-ENs essentially 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 involves those TRILL-ENs spoofing edge RBridges to which they are
connected, which is another reason that TRILL-ENs should be trusted connected, which is another reason that TRILL-ENs should be trusted
nodes. Such spoofing cannot cause looping traffic because TRILL has a nodes. Such spoofing cannot cause looping traffic because TRILL has a
hop count in the TRILL header [RFC6325] so that, should there be 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 loop, a TRILL packet caught in that loop (i.e., an encapsulated
frame) will be discarded. (In the potentially more dangerous case of frame) will be discarded. (In the potentially more dangerous case of
multi-destination packets, as compared with known unicast, where multi-destination packets, as compared with known unicast, where
copies could multiply due to forks in the distribution tree, a copies could multiply due to forks in the distribution tree, a
Reverse Path Forwarding Check is also used [RFC6325] to discard Reverse Path Forwarding Check is also used [RFC6325] to discard
packets that appear to be on the wrong link or when there is packets that appear to be on the wrong link or when there is
disagreement about the distribution tree.) disagreement about the distribution tree.)
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
the TRILL-EN is attached and the egress RBridge nickname from which
the destination of the packets is reachable. With that information,
TRILL-ENs can learn a substantial amount about the topology of the
TRILL domain. Therefore, there could be a potential security risk
when the TRILL-ENs are not trusted or are compromised.
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
TRILL-EN to be sent to wrong destinations, possibly violating
security policy as to which end stations should receive what data.
Therefore, a combination of authentication and encryption is
RECOMMENDED between the Directory and TRILL-EN. The entities involved
will need to properly authenticate with each other, provide session
encryption, maintain security patch levels, and configure their
systems to allow minimal access and running processes to protect
sensitive information.
For added security against the compromise of data due to its mis-
delivery for any reason, including the above, end-to-end encryption
and authentication should be considered; that is, encryption and
authentication from source end station to destination end station.
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. 10 change blocks. 
27 lines changed or deleted 51 lines changed or added

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