< 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/ |