Network Working Group M. Wasserman Internet-Draft Painless Security Intended status: Standards Track D. Eastlake Expires: April 26, 2012 D. Zhang Huawei Technologies October 24, 2011 Transparent Interconnection of Lots of Links (TRILL) over IP draft-mrw-trill-over-ip-00.txt Abstract The Transparent Interconnection of Lots of Links (TRILL) protocol is implemented by devices called Routing Bridges (RBridges). TRILL supports both point-to-point and multi-access links and is designed so that a variety of link protocols can be used between RBridge ports. This document standardizes a methods for encapsulating TRILL in UDP/IP(v4 or v6). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 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 Wasserman, et al. Expires April 26, 2012 [Page 1] Internet-Draft TRILL over IP October 2011 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. Table of Contents 1. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases for TRILL over IP . . . . . . . . . . . . . . . . . 3 3.1. Remote Office Scenario . . . . . . . . . . . . . . . . . . 4 3.2. IP Backbone Scenario . . . . . . . . . . . . . . . . . . . 4 3.3. Important Properties of the Scenarios . . . . . . . . . . 4 3.3.1. Security Requirements . . . . . . . . . . . . . . . . 4 3.3.2. Multicast Handling . . . . . . . . . . . . . . . . . . 5 3.3.3. RBridge Discovery . . . . . . . . . . . . . . . . . . 5 4. TRILL Frame Formats . . . . . . . . . . . . . . . . . . . . . 5 4.1. TRILL Data Frame . . . . . . . . . . . . . . . . . . . . . 6 4.2. TRILL IS-IS Frame . . . . . . . . . . . . . . . . . . . . 6 5. Link Protocol Specifics . . . . . . . . . . . . . . . . . . . 6 6. Port Configuration . . . . . . . . . . . . . . . . . . . . . . 7 7. TRILL over UDP/IP Format . . . . . . . . . . . . . . . . . . . 7 8. Handling Multicast . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Multicast of TRILL IS-IS Packets . . . . . . . . . . . . . 7 8.2. Multicast Data Frames . . . . . . . . . . . . . . . . . . 7 9. Use of DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 8 11. Middlebox Considerations . . . . . . . . . . . . . . . . . . . 8 12. Security Considerations . . . . . . . . . . . . . . . . . . . 8 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 15.1. Normative References . . . . . . . . . . . . . . . . . . . 10 15.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Wasserman, et al. Expires April 26, 2012 [Page 2] Internet-Draft TRILL over IP October 2011 1. Requirements Terminology 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 RFC 2119 [RFC2119]. 2. Introduction RBridges are devices that implement the IETF TRILL protocol [RFC6325] [RFC6326] [RFC6327]. RBridges provide transparent forwarding of frames within an arbitrary network topology, using least cost paths for unicast traffic. They support VLANs and multipathing of unicast and multi-destination traffic. They use IS-IS link state routing and a hop count. The are compatible with IEEE customer bridges, and can incrementally replace them. Two or more RBridges can communicate over a variety of different link types, such as Ethernet [RFC6325] or PPP [RFC6361]. This document defines a method for RBridges to communicate over UPD/ IP(v4 or v6). TRILL over IP will allow remote, Internet-connected RBridges to form a single RBridge campus, or multiple TRILL over IP networks within a campus to be connected via a TRILL over IP backbone. TRILL over IP connects RBridge ports using IPv4 or IPv6 as a transport in such a way that the ports appear to TRILL to be connected by a single link. The link will be a multi-access link if more than two RBridge ports are connected to a single TRILL over IP link. To support cases where RBridges are connected via links (such as the public Internet) that are not under the same administrative control as the TRILL campus, this document specifies the use of Datagram Transport Layer Security (DTLS) [RFC4327] to secure communication between RBridges running TRILL over IP. 3. Use Cases for TRILL over IP In this document, we consider two use cases that are typical of situations where network administrators may choose to use TRILL over an IP network: a remote office scenario, and an IP backbone scenario. Wasserman, et al. Expires April 26, 2012 [Page 3] Internet-Draft TRILL over IP October 2011 3.1. Remote Office Scenario In the Remote Office Scenario, a remote TRILL network is connected to a TRILL campus across a multihop non-TRILL IP network, such as the public Internet. The TRILL network in the remote office becomes a logical part of TRILL campus, and nodes in the remote office can be attached to the same VLANs as local campus nodes. In many cases, a remote office may be attached to the TRILL campus by a single pair of RBridges, one on the campus end, and the other in the remote office. In this use case, the TRILL over IP link will often cross logical and physical IP networks that do not support TRILL, and are not under the same administrative control as the TRILL campus. 3.2. IP Backbone Scenario In the IP Backbone Scenario, TRILL over IP is used to connect a number of TRILL networks within a single TRILL campus. For example, a TRILL over IP backbone could be used to connect multiple TRILL networks on different floors of a large building, or to connect TRILL networks in separate buildings of a multi-building site. In this use case, there may often be several TRILL RBridges on a single TRILL over IP link, and the the IP link(s) used by TRILL over IP are typically under the same administrative control as the rest of the TRILL campus. 3.3. Important Properties of the Scenarios There are a number of differences between the two scenarios listed above, some of which drive features of this specification. These differences are especially pertinent to the security requirements of the solution, how multicast data frames are handled, and how the RBridges discover each other. 3.3.1. Security Requirements In the IP Backbone Scenario, TRILL over IP is used between a number of RBridges, on a network link that is in the same administrative control as the remainder of the TRILL campus. While it is desirable in this scenario to prevent the association of rogue RBridges, this can be accomplished using existing IS-IS security mechanisms. There may be no need to protect the data traffic, beyond any protections that are already in place on the local network. In the Remote Office Scenario, TRILL over IP may run over a network that is not under the same administrative control as the TRILL network. Nodes on the network may think that they are sending traffic locally, while that traffic is actually being sent, in a UDP/IP tunnel, over the public Internet. It is necessary in this Wasserman, et al. Expires April 26, 2012 [Page 4] Internet-Draft TRILL over IP October 2011 scenario to protect user privacy, as well as ensuring that no unauthorized RBridges can gain access to the RBridge campus. The data privacy requirement is addressed by the use of DTLS for both IS-IS frames and data frames between RBridges in this scenario. 3.3.2. Multicast Handling In the IP Backbone scenario, native mutlicast may be supported on the TRILL over IP link. If so, it will be used to send TRILL IS-IS and multicast data frames, as discussed later in this document. In the Remote Office Scenario, there will often be only one pair of RBridges connecting a given site, and even when multiple RBridges are used to connect a Remote Office to the TRILL campus, the intervening network may not provide reliable (or any) multicast connectivity. Also, there is no suitable way to provide data privacy for multicast traffic. For all of these reasons, the connections between local and remote RBridges will be treated like point-to-point links, and all TRILL IS-IS control messages and multicast data frames that are transmitted between the Remote Office and the TRILL campus will be serialized, as discussed later in this document. 3.3.3. RBridge Discovery In the IP Backbone Scenario, RBridges that use TRILL over IP will use the normal TRILL IS-IS Hello mechanisms to discover the existence of other RBridges on the link, and to establish authenticated communication with those RBridges. In the Remote Office Scenario, a DTLS session will need to be established between RBridges before TRILL IS-IS traffic can be exchanged, as discussed below. In this case, one of the RBRidges will need to be configured to establish a DTLS session with the other RBridge. This will typically be accomplished by configuring the RBridge at a Remote Office to initiate a DTLS session, and subsequent TRILL exchanges, with an TRILL over IP-enabled RBridge attached to the TRILL campus. 4. TRILL Frame Formats To support the TRILL base protocol standard [RFC6325]. , two types of frames will be transmitted between RBridges: TRILL Data frames and TRILL IS-IS frames. Wasserman, et al. Expires April 26, 2012 [Page 5] Internet-Draft TRILL over IP October 2011 4.1. TRILL Data Frame The on-the-wire form of a TRILL Data frame in transit between two neighboring RBridges is as shown below: +--------------+----------+----------------+-----------+ | TRILL Data | TRILL | Encapsulated | Link | | Link Header | Header | Native Frame | Trailer | +--------------+----------+----------------+-----------+ Where the Encapsulated Native Frame is in Ethernet frame format with a VLAN tag but with no trailing Frame Check Sequence (FCS). 4.2. TRILL IS-IS Frame TRILL IS-IS frames are formatted on-the-wire as follows: +--------------+---------------+-----------+ | TRILL IS-IS | TRILL IS-IS | Link | | Link Header | Payload | Trailer | +--------------+---------------+-----------+ The Link Header and Link Trailer in these formats depend on the specific link technology. The Link Header usually contains one or more fields that distinguish TRILL Data from TRILL IS-IS. For example, over Ethernet, the TRILL Data Link Header ends with the TRILL Ethertype while the TRILL IS-IS Link Header ends with the L2- IS-IS Ethertype; on the other hand, over PPP, there are no Ethertypes but PPP protocol code points are included that distinguish TRILL Data from TRILL IS-IS. In TRILL over IP, we will use UDP/IP (v4 or v6) as the link header, and the TRILL frame type will be determined based on the UDP port number. In TRILL over IP, no Link Trailer is specified, although one may be added when TRILL over IP packets are encapsulated for transmission on a network (e.g. Ethernet). 5. Link Protocol Specifics TRILL Data packets can be unicast to a specific RBridge or multicast to all RBridges on the link. TRILL IS-IS packets are always multicast to all other RBridge on the link. On Ethernet links, the Ethernet multicast address All-RBridges is used for TRILL Data and Wasserman, et al. Expires April 26, 2012 [Page 6] Internet-Draft TRILL over IP October 2011 All-IS-IS-RBridges for TRILL IS-IS. To properly handle TRILL base protocol frames on a TRILL over IP link, either native multicast mode must be enabled on that link, or multicast must be simulated using serial unicast, as discussed below. In TRILL Hello PDUs used on TRILL IP links, the IP addresses of the connected IP ports are their SNPA addresses. Thus, all TRILL Neighbor TLVs in such Hellos MUST specify that the size of the SNPA is 4-bytes for an IPv4 link or 16-bytes for an IPv6 link [rfc6326bis]. Note that SNPA addresses and their size are independent of TRILL System IDs which are 6-bytes. 6. Port Configuration Each RBridge port that is to be used for a TRILL over IP link MUST have at least one IP (v4 or v6) address. Implementations MAY allow a single physical port to operate as multiple IPv4 and/or IPv6 logical ports. TBD: MUST be able to configure list of IP addresses for serial unicast. MUST be able to configure non-standard IP multi-cast addresses. 7. TRILL over UDP/IP Format The general format of a TRILL over UDP/IP packet is shown below. +----------+--------+-----------------------+ | IP | UDP | TRILL | | Header | Header | Payload | +----------+--------+-----------------------+ 8. Handling Multicast 8.1. Multicast of TRILL IS-IS Packets 8.2. Multicast Data Frames 9. Use of DTLS All RBridges that support TRILL over IP MUST implement DTLS and Wasserman, et al. Expires April 26, 2012 [Page 7] Internet-Draft TRILL over IP October 2011 support the use of DTLS to secure both TRILL IS-IS and data traffic. When DTLS is used to secure a TRILL over IP link, the DTLS session MUST be fully established before any TRILL IS-IS or data frames are exchanged. RBridges that implement TRILL over IP MUST support the use of certificates for DTLS authentication, and MUST support the following algorithm: o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] RBridges that support TRILL over IP MAY support the use of pre-shared keys for DTLS authentication. If pre-shared keys are supported, the following cryptographic algorithms MUST be supported for use with pre-shared keys: o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246] 10. MTU Considerations TBD 11. Middlebox Considerations TBD 12. Security Considerations TRILL over IP is subject to all of the security considerations for the base TRILL protocol. In addition, there are specific security requirements for different TRILL deployment scenarios, as discussed in the "Use Cases for TRILL over IP" section above. This document specifies that all RBridges that support TRILL over IP MUST implement DTLS, and makes it clear that it is both wise and good to use DTLS in all cases where a TRILL over IP link will traverse a network that is not under the same administrative control as the rest of the TRILL campus. DTLS is necessary, in these cases to protect the privacy and integrity of data traffic. TRILL over IP is completely compatible with the use of IS-IS security, which can be used to authenticte RBridges before allowing them to join a TRILL campus. This is sufficient to protect against rogue RBridges, but is not sufficient to protect data frames that may be sent, in UDP/IP tunnels, outside of the local network, or even Wasserman, et al. Expires April 26, 2012 [Page 8] Internet-Draft TRILL over IP October 2011 across the public Internet. To protect the privacy and integrity of that traffic, use DTLS. In cases were DTLS is used, the use of IS-IS security may not be necessary, but there is nothing about this specification that would prevent using both DTLS and IS-IS security together. In cases where both types of security are enabled, implementations MAY allow users to configure a single shared key that will be used for both mechanisms. 13. IANA Considerations IANA has allocated the following UDP Ports for the TRILL IS-IS and Data channels: UDP Port Protocol (TBD) TRILL IS-IS Channel (TBD) TRILL Data Channel IANA has allocated one IPv4 and one IPv6 multicast address, as shown below, which correspond to the All-RBridges multicast MAC addresses that the IEEE Registration Authority has assigned for TRILL. [Values recommended to IANA:] TRILL name IPv4 IPv6 All-RBridges 233.252.14.0 FF0X:0:0:0:0:0:0:205 Note: when these IPv4 and IPv6 multicast addresses are used and the resulting IP frame is sent over Ethernet, the usual IP derived MAC address is used. [Need to discuss scopes for IPv6 multicast (the "X" in the addresses) somewhere. Default to "site" scope but MUST be configurable?] 14. Acknowledgements This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]. Wasserman, et al. Expires April 26, 2012 [Page 9] Internet-Draft TRILL over IP October 2011 The following people have provided useful feedback on the contents of this document: Sam Hartman. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4327] Dubuc, M., Nadeau, T., Lang, J., and E. McGinnis, "Link Management Protocol (LMP) Management Information Base (MIB)", RFC 4327, January 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. [RFC6327] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011. [RFC6361] Carlson, J. and D. Eastlake, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011. 15.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Wasserman, et al. Expires April 26, 2012 [Page 10] Internet-Draft TRILL over IP October 2011 Authors' Addresses Margaret Wasserman Painless Security 356 Abbott Street North Andover, MA 01845 USA Phone: +1 781 405-7464 Email: mrw@painless-security.com URI: http://www.painless-security.com Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1 508 333-2270 Email: d3e3e3@gmail.com Dacheng Zhang Huawei Technologies Q14, Huawei Campus No.156 Beiqing Rd. Beijing, Hai-Dian District 100095 P.R. China Phone: Email: zhangdacheng@huawei.com URI: Wasserman, et al. Expires April 26, 2012 [Page 11]