[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mrw-trill-over-ip) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17

Network Working Group                                       M. Wasserman
Internet-Draft                                         Painless Security
Intended status: Standards Track                             D. Eastlake
Expires: August 6, 2015                              Huawei Technologies
                                                                D. Zhang
                                                        February 2, 2015

      Transparent Interconnection of Lots of Links (TRILL) over IP


   The Transparent Interconnection of Lots of Links (TRILL) protocol is
   implemented by devices called TRILL Switches or RBridges (Routing
   Bridges).  TRILL supports both point-to-point and multi-access links
   and is designed so that a variety of link protocols can be used
   between TRILL switch ports.  This document standardizes methods for
   encapsulating TRILL in IP (v4 or v6) so as to use IP as a TRILL link
   protocol in a unified TRILL campus.

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 August 6, 2015.

Copyright Notice

   Copyright (c) 2015 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

Wasserman, et al.        Expires August 6, 2015                 [Page 1]

Internet-Draft                TRILL over IP                February 2015

   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.

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 Neighbor Discovery  . . . . . . . . . . . . .   5
   4.  TRILL Packet Formats  . . . . . . . . . . . . . . . . . . . .   5
   5.  Link Protocol Specifics . . . . . . . . . . . . . . . . . . .   6
   6.  RBridge IP Port Configuration . . . . . . . . . . . . . . . .   7
     6.1.  Per IP Port Configuration . . . . . . . . . . . . . . . .   7
     6.2.  Additional per IP Address Cofiguration  . . . . . . . . .   8
       6.2.1.  Native Multicast Configuration  . . . . . . . . . . .   8
       6.2.2.  Serial Unicast Configuration  . . . . . . . . . . . .   8
       6.2.3.  Security Configuration  . . . . . . . . . . . . . . .   8
   7.  TRILL over IP Format  . . . . . . . . . . . . . . . . . . . .   9
   8.  Handling Multicast  . . . . . . . . . . . . . . . . . . . . .  10
   9.  Use of IPsec  . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Default Pre-Shared Keys . . . . . . . . . . . . . . . . .  11
   10. Transport Considerations  . . . . . . . . . . . . . . . . . .  12
     10.1.  Recursive Ingress  . . . . . . . . . . . . . . . . . . .  12
     10.2.  Fat Flows  . . . . . . . . . . . . . . . . . . . . . . .  12
     10.3.  Congestion Considerations  . . . . . . . . . . . . . . .  13
     10.4.  MTU Considerations . . . . . . . . . . . . . . . . . . .  14
   11. Middlebox Considerations  . . . . . . . . . . . . . . . . . .  15
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     13.1.  Port Assignments . . . . . . . . . . . . . . . . . . . .  16
     13.2.  Multicast Address Assignments  . . . . . . . . . . . . .  16
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     15.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

Wasserman, et al.        Expires August 6, 2015                 [Page 2]

Internet-Draft                TRILL over IP                February 2015

1.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   TRILL switches (RBridges) are devices that implement the IETF TRILL
   protocol [RFC6325] [RFC7176] [RFC7177].

   RBridges provide transparent forwarding of frames within an arbitrary
   network topology, using least cost paths for unicast traffic.  They
   support not only VLANs and Fine Grained Labels [RFC7172] but also
   multipathing of unicast and multi-destination traffic.  They use IS-
   IS link state routing and encapsulation with a hop count.

   Ports on different RBridges can communicate with each other over
   various link types, such as Ethernet [RFC6325], pseudowires
   [RFC7173], or PPP [RFC6361].

   This document defines a method for RBridges to communicate over IP
   (v4 or v6).  TRILL over IP will allow Internet-connected RBridges to
   form a single TRILL campus, or multiple TRILL over IP networks within
   a campus to be connected as a single TRILL campus via a TRILL over IP

   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 multi-access link.  Therefore, if more than two
   RBridge ports are connected via a single TRILL over IP link, any pair
   of them can communicate.

   To support the scenarios where RBridges are connected via IP paths
   (such as over the public Internet) that are not under the same
   administrative control as the TRILL campus and/or not physically
   secure, this document specifies the use of IPsec [RFC4301]
   Encapsulating Security Protocol [RFC4303] to secure all or part of
   such paths.

3.  Use Cases for TRILL over IP

   This section introduces two application scenarios (a remote office
   scenario and an IP backbone scenario) which cover typical situations
   where network administrators may choose to use TRILL over an IP
   network to connect TRILL switches.

Wasserman, et al.        Expires August 6, 2015                 [Page 3]

Internet-Draft                TRILL over IP                February 2015

3.1.  Remote Office Scenario

   In the Remote Office Scenario, a remote TRILL network is connected to
   a TRILL campus across a multihop 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 or Fine Grained Labels[RFC7172] 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

3.2.  IP Backbone Scenario

   In the IP Backbone Scenario, TRILL over IP is used to connect a
   number of TRILL networks to form 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 switches on a single TRILL
   over IP link, and the IP link(s) used by TRILL over IP are typically
   under the same administrative control as the rest of the TRILL

3.3.  Important Properties of the Scenarios

   There are a number of differences between the above two application
   scenarios, 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
   TRILL switch ports discover each other.

3.3.1.  Security Requirements

   In the IP Backbone Scenario, TRILL over IP is used between a number
   of RBridge ports, 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 an IP

Wasserman, et al.        Expires August 6, 2015                 [Page 4]

Internet-Draft                TRILL over IP                February 2015

   tunnel, over the public Internet.  It is necessary in this scenario
   to protect the integrity and confidentiality of user traffic, as well
   as ensuring that no unauthorized RBridges can gain access to the
   RBridge campus.  The issues of protecting integrity and
   confidentiality of user traffic are addressed by using IPsec for both
   TRILL IS-IS and TRILL Data packets between RBridges in this scenario.

3.3.2.  Multicast Handling

   In the IP Backbone scenario, native multicast may be supported on the
   TRILL over IP link.  If so, it can be used to send TRILL IS-IS and
   multicast data packets, as discussed later in this document.
   Alternatively, multi-destination packets can be transmitted serially
   by unicast.

   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.
   Issues such as complex key management also make it difficult to
   provide strong data integrity and confidentiality protections for
   multicast traffic.  For all of these reasons, the connections between
   local and remote RBridges will commonly be treated like point-to-
   point links, and all TRILL IS-IS control messages and multicast data
   packets that are transmitted between the Remote Office and the TRILL
   campus will be serially transmitted by unicast, as discussed later in
   this document.

3.3.3.  RBridge Neighbor 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 [RFC7177], and to establish authenticated
   communication with those RBridges.

   In the Remote Office Scenario, an IPsec session will need to be
   established before TRILL IS-IS traffic can be exchanged, as discussed
   below.  In this case, one end will need to be configured to establish
   a IPSEC session with the other.  This will typically be accomplished
   by configuring the RBridge or a border device at a Remote Office to
   initiate an IPsec session and subsequent TRILL exchanges with a TRILL
   over IP-enabled RBridge attached to the TRILL campus.

4.  TRILL Packet Formats

   To support the TRILL base protocol standard [RFC6325], two types of
   packets will be transmitted between RBridges: TRILL Data packets and
   TRILL IS-IS packets.

Wasserman, et al.        Expires August 6, 2015                 [Page 5]

Internet-Draft                TRILL over IP                February 2015

   The on-the-wire form of a TRILL Data packet in transit between two
   neighboring RBridges is as shown below:

      | TRILL Data   |  TRILL   |  Native Frame  |   Link    |
      | Link Header  |  Header  |     Payload    |  Trailer  |

   Where the Encapsulated Native Frame Payload is similar to Ethernet
   frame format with a VLAN tag or Fine Grained Label [RFC7172] but with
   no trailing Frame Check Sequence (FCS).

   TRILL IS-IS packets 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 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 packet type will be determined based on the UDP
   destination port number.  In TRILL over IP, no Link Trailer is
   specified, although one may be added when the resulting 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 (except for MTU PDUs,
   which may be unicast [RFC7177]).  On Ethernet links, the Ethernet
   multicast address All-RBridges is used for TRILL Data and All-IS-IS-
   RBridges for TRILL IS-IS.

Wasserman, et al.        Expires August 6, 2015                 [Page 6]

Internet-Draft                TRILL over IP                February 2015

   To properly handle TRILL base protocol packets on a TRILL over IP
   link, either native multicast mode must be used 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 real SNPA (SubNetwork Point of
   Attachment [IS-IS]) addresses and, for IPv6, the 16-byte IPv6 address
   is used; however, for easy of code re-use designed for common 48-bit
   SNPAs, for TRILL over IPv4, a 48-bit synthetic SNPA that looks like a
   unicast MAC address is constructed for use in the SNPA field of TRILL
   Neighbor TLVs [RFC7176][RFC7177] on the link.  This synthetic SNPA is
   as follows:

                           1 1 1 1 1 1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      |  0xFE         |  0x00         |
      |  IPv4 upper half              |
      |  IPv4 lower half              |

   This synthetic SNPA/MAC address has the local (0x02) bit on in the
   first byte and so cannot conflict with any globally unique 48-bit
   Ethernet MAC.  However, at the IP level, where TRILL operates on an
   IP link, there are only IP stations, not MAC stations, so conflict on
   the link with a real MAC address would be impossible in any case.

6.  RBridge IP Port Configuration

   This section specifies the configuration information needed at a
   TRILL over IP port beyond that needed for a general RBridge port.

6.1.  Per IP Port Configuration

   Each RBridge port used for a TRILL over IP link should have at least
   one IP (v4 or v6) address.  If no IP address is associated with the
   port, perhaps as a transient condition during re-configuration, the
   port is disabled.  Implementations MAY allow a single port to operate
   as multiple IPv4 and/or IPv6 logical ports.  Each IP address
   constitutes a different logical port and the RBridge with those ports
   MUST associate a different Port ID with each logical port.

   By default an RBridge IP port discards output packets that fail the
   possible recursive ingress test (see Section 10.1) unless configured
   to disable that test.

Wasserman, et al.        Expires August 6, 2015                 [Page 7]

Internet-Draft                TRILL over IP                February 2015

6.2.  Additional per IP Address Cofiguration

   The configuration information specified below is per IP address at a
   TRILL over IP port.

   Each IP address at a TRILL over IP port uses native IP multicast by
   default but may be configured whether to use serial unicast
   (Section 6.2.2) or native multicast (Section 6.2.1).  Each IP address
   at a TRILL over IP is configured whether or not to use IPsec
   (Section 6.2.3).

6.2.1.  Native Multicast Configuration

   If a TRILL IP port address is using native IP multicast for multi-
   destination TRILL packets (IS-IS and data), by default transmissions
   from that IP address use the appropriate IP multicast address (IPv4
   or IPv6) specified in Section 13.2.  The RBridge IP port may be
   configured to use a different IP multicast address or multi-
   destination packets.

6.2.2.  Serial Unicast Configuration

   If a TRILL over IP port address has been configured to use serial
   unicast for multi-destination packets (IS-IS and data), it should
   have associated with it a non-empty list of unicast IP destination
   addresses.  Multi-destination TRILL packets are serially unicast to
   the addresses in this list.  Such a TRILL over IP port will only be
   able to form adjacencies [RFC7177] with the RBridges at the addresses
   in this list as those are the only RBridges to which it will send
   TRILL Hellos.

   If the list is empty, there is no way to transmit a multi-destination
   TRILL over IP packet such as a TRILL Hello.  Thus it is impossible to
   achieve adjacency [RFC7177] or if adjacency had been achieved
   (perhaps the list was non-empty and has just been configured to be
   empty), no way to maintain such adjacency.  Thus, in the empty list
   case, TRILL Data multi-destination packets cannot be sent and TRILL
   Data unicast packets will not start flowing or, if they are already
   flowing, will soon cease.

6.2.3.  Security Configuration

   ... tbd ...

Wasserman, et al.        Expires August 6, 2015                 [Page 8]

Internet-Draft                TRILL over IP                February 2015

7.  TRILL over IP Format

   The general format of a TRILL over IP packet without security is
   shown below.

      | IP       | UDP    |  TRILL                |
      | Header   | Header |  Payload              |

   Where the UDP Header is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |    Source Port = Entropy      |      Destination Port         |
      |           UDP Length          |        UDP Checksum           |
      |  TRILL Payload ...

      Source Port - see Section 10.2

      Destination Port - indicates TRILL Data or IS-IS, see Section 14

      UDP Length - as specified in [RFC0768]

      UDP Checksum - as specified in [RFC0768]

   The TRILL Payload starts with the TRILL Header (not including the
   TRILL Ethertype) for TRILL Data packets and starts with the 0x83
   Intradomain Routeing Protocol Discriminator byte (thus not including
   the L2-IS-IS Ethertype) for TRILL IS-IS packets.

   TRILL over IP link security uses IPsec Encapsulating Security
   Protocol (ESP) in tunnel mode.  The resulting packet format is as
   follows for IPv4 and IPv6:

Wasserman, et al.        Expires August 6, 2015                 [Page 9]

Internet-Draft                TRILL over IP                February 2015

     IPv4  | new IP hdr  |     | orig IP hdr   |   |TRILL| ESP   | ESP|
           |(any options)| ESP | (any options) |UDP|Data |Trailer| ICV|
                               |<--------- encryption ---------->|
                         |<------------- integrity ------------->|

     IPv6  | new  |new ext |   | orig |orig ext |   |TRILL| ESP   | ESP|
           |IP hdr| hdrs   |ESP|IP hdr| hdrs    |UDP|Data |Trailer| ICV|
                               |<--------- encryption ----------->|
                           |<------------ integrity ------------->|

   This architecture permits the ESP tunnel termination to be separated
   from the TRILL over IP RBridge port and, for example, placed at a
   physical or administrative security boundary.  If two or more RBridge
   TRILL over IP ports are communicate securely using IPsec, there are
   three possibilities:

   (a) For all ports involved, the IPsec implementation is integrated
   with the RBridge port.  In this case it is straightforward to use the
   default and negotiations specified herein for keying and algorithms.

   (b) Some of the IPsec implementations are integrated with an RBridge
   port and some are not.  For example, on a point-to-point TRILL over
   IP link, IPsec could be integrated with the RBridge port at one end
   but implemented in a separate appliances that could be separated by
   IP routers from the TRILL over IP RBridge port at the other end.  In
   this case mechanisms beyond the scope of this document may be
   required to communicate default or negotiated keying or algorithms
   between such separate appliances and the RBridge port for which they
   are providing TRILL over IP security services.

   (c) For all ports involved, the IPsec implementation is in a separate
   appliance.  In this case, if adequate security is provided, the
   appliances MAY negotiation IPsec keying and algorithms as they see
   fit.  Alternatively, the specifications of this document for keying
   and algorithms are used and mechanisms beyond the scope of this
   document may be required to communicate default or negotiated keying
   or algorithms between such separate appliances and the RBridge port
   for which they are providing TRILL over IP security services

8.  Handling Multicast

   By default, both TRILL IS-IS packets and multi-destination TRILL Data
   packets are sent to an All-RBridges IPv4 or IPv6 multicast Address as
   appropriate (see Section 13.2); however, a TRILL over IP port may be

Wasserman, et al.        Expires August 6, 2015                [Page 10]

Internet-Draft                TRILL over IP                February 2015

   configured (see Section 6) to use serial unicast with a list of one
   or more unicast IP addresses of other TRILL over IP ports to which
   multi-destination packets are sent.  Such configuration is necessary
   if the TRILL over IP port is connected to an IP network that does not
   support IP multicast.  In both cases, unicast TRILL data packets
   would be sent by unicast IP.

   When a TRILL over IP port is using IP multicast, it MUST periodically
   transmit appropriate IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710])
   packets so that the TRILL multicast IP traffic will be sent to it.

   Although TRILL fully supports broadcast links with more than 2
   RBridges connected to the link, even where native IP multicast is
   available, there may be good reasons for configuring TRILL over IP
   ports to use serial unicast.  In some networks, unicast is more
   reliable than multicast.  If multiple unicast connections between
   parts of a TRILL campus are configured, TRILL will in any case spread
   traffic across them, treating them as parallel links, and
   appropriately fail over traffic if a link ceases to operate or
   incorporate a new link that comes up.

9.  Use of IPsec

   All RBridges that support TRILL over IP MUST implement IPsec and
   support the use of IPsec Encapsulating Security Protocol (ESP) to
   secure both TRILL IS-IS and TRILL data packets.  When IPsec is used
   to secure a TRILL over IP link and no IS-IS security is enabled, the
   IPsec session MUST be fully established before any TRILL IS-IS or
   data packets are exchanged.  When there is IS-IS security [RFC5310]
   provided, people may select to use IS-IS security to protect TRILL
   IS-IS packets.  However, in this case, the IPsec session still MUST
   be fully established before any data packets transmission since IS-IS
   security does not provide any protection to data packets.

   ... TBD ...

9.1.  Default Pre-Shared Keys

   The default pre-shared keyes for IPsec usage are derived as follows:

   HMAC-SHA256 ("TRILL IP"| IS-IS-shared key )

   In the above "|" indicates concatenation, HMAC-SHA256 is as described
   in [FIPS180] [RFC6234] and "TRILL IP" is the eight byte US ASCII
   [RFC0020] string indicated.  IS-IS-shared key is a link (or wider
   scope) IS-IS key usable for IS-IS security of link local IS-IS local
   PDUs such as Hello, CSNP, and PSNP.  With [RFC5310]there could be

Wasserman, et al.        Expires August 6, 2015                [Page 11]

Internet-Draft                TRILL over IP                February 2015

   multiple keys identified with 16-bit key IDs.  In this case, the Key
   ID of IS-IS-shared key is also used to identify the derived key.

10.  Transport Considerations

   This section discusses a variety of transport considerations.

10.1.  Recursive Ingress

   TRILL is designed to transport end station traffic to and from end
   stations over IEEE 802.3 and IP is frequently transported over IEEE
   802.3 or similar protocols.  Thus, an end station native data frame
   EF might get TRILL ingressed to TRILL(EF) which was then sent on a
   TRILL over IP over an 802.3 link resulting in an 802.3 frame of the
   form 802.3(IP(TRILL(EF))).  There is a risk of such a packet being
   re-ingressed by the same TRILL campus, due to physical or logical
   misconfiguration, looping round, being further re-ingressed, etc.
   The packet might get discarded if it got too large but if
   fragmentation is enabled, it would just keep getting split into
   fragments that would continue to loop and grow and re-fragment until
   the path was saturated with junk and packets were being discarded due
   to queue overflow.  The TRILL Header TTL would provide no protection
   because each TRILL ingress adds a new Header and TTL.

   To protect against this scenario, a TRILL over IP port MUST by,
   default, test whether a TRILL packet it is about to send is, in fact
   a TRILL ingress of a TRILL over IP over 802.3 or the like packets.
   That is, is it of the form TRILL(802.3(IP(TRILL(...)))?  If so, the
   default action of the TRILL over IP output port is to discard the
   packet rather than transmit it.  However, there are cases where some
   level of nested ingress is desired so it MUST be possible to
   configure the port to allow such packets.

10.2.  Fat Flows

   For the purpose of load balancing, it is worthwhile to consider how
   to transport the TRILL packets over the Equal Cost Multiple Paths
   (ECMPs) existing in the IP path.

   The ECMP election for the IP traffics could be based, at least for
   IPv4, on the quintuple of the outer IP header { Source IP,
   Destination IP, Source Port, Destination Port, and IP protocol }.
   Such tuples, however, could be exactly the same for all TRILL Data
   packets between two RBridge ports, even if there is a huge amount of
   data being sent between a variety of ingress and egress RBridges.
   Therefore, in order to better support ECMP, a RBridge SHOULD set the
   Source Port as an entropy field for ECMP decisions.  (This idea is
   also introduced in [I-D.yong-tsvwg-gre-in-udp-encap].For example, for

Wasserman, et al.        Expires August 6, 2015                [Page 12]

Internet-Draft                TRILL over IP                February 2015

   TRILL Data this entropy field could be based on the Inner.MacDA,
   Inner.MacSA, and Inner.VLAN or Inner.FGL.

10.3.  Congestion Considerations

   Section 3.1.3 of [RFC5405] discussed the congestion implications of
   UDP tunnels.  As discussed in [RFC5405], because other flows can
   share the path with one or more UDP tunnels, congestion control
   [RFC2914] needs to be considered.

   One motivation for encapsulating TRILL in UDP is to improve the use
   of multipath (such as ECMP) in cases where traffic is to traverse
   routers which are able to hash on UDP Port and IP address.  In many
   cases this may reduce the occurrence of congestion and improve usage
   of available network capacity.  However, it is also necessary to
   ensure that the network, including applications that use the network,
   responds appropriately in more difficult cases, such as when link or
   equipment failures have reduced the available capacity.

   The impact of congestion must be considered both in terms of the
   effect on the rest of the network of a UDP tunnel that is consuming
   excessive capacity, and in terms of the effect on the flows using the
   UDP tunnels.  The potential impact of congestion from a UDP tunnel
   depends upon what sort of traffic is carried over the tunnel, as well
   as the path of the tunnel.

   TRILL is used to carry a wide range of traffic.  In many cases TRILL
   is used to carry IP traffic.  IP traffic is generally assumed to be
   congestion controlled, and thus a tunnel carrying general IP traffic
   (as might be expected to be carried across the Internet) generally
   does not need additional congestion control mechanisms.  As specified
   in [RFC5405]:

   "IP-based traffic is generally assumed to be congestion- controlled,
   i.e., it is assumed that the transport protocols generating IP-based
   traffic at the sender already employ mechanisms that are sufficient
   to address congestion on the path.  Consequently, a tunnel carrying
   IP-based traffic should already interact appropriately with other
   traffic sharing the path, and specific congestion control mechanisms
   for the tunnel are not necessary".

   For this reason, where TRILL is tunneled through UDP and used to
   carry IP traffic that is known to be congestion controlled, the UDP
   tunnels MAY be used across any combination of a single or cooperating
   service providers or across the general Internet.

Wasserman, et al.        Expires August 6, 2015                [Page 13]

Internet-Draft                TRILL over IP                February 2015

   However, TRILL is also used to carry traffic that is not necessarily
   congestion controlled.  For example, TRILL may be used to carry
   traffic where specific bandwidth guarantees are provided.

   In such cases congestion may be avoided by careful provisioning of
   the network and/or by rate limiting of user data traffic.  Where
   TRILL is carried, directly or indirectly, over UDP over IP, the
   identity of each individual TRILL flow is in general lost.

   For this reason, where the TRILL traffic is not congestion
   controlled, TRILL over UDP/IP MUST only be used within a single
   service provider that utilizes careful provisioning (e.g., rate
   limiting at the entries of the network while over-provisioning
   network capacity) to ensure against congestion, or within a limited
   number of service providers who closely cooperate in order to jointly
   provide this same careful provisioning.  As such, TRILL over USP/IP
   MUST NOT be used over the general Internet, or over non-cooperating
   service providers, to carry traffic that is not congestion-

   Measures SHOULD be taken to prevent non-congestion-controlled TRILL
   over UDP/IP traffic from "escaping" to the general Internet, for
   example the following:

   a.  Physical or logical isolation of the TRILL over IP links from the
   general Internet.

   b.  Deployment of packet filters that block the UDP ports assigned
   for TRILL-over-UDP.

   c.  Imposition of restrictions on TRILL over UDP/IP traffic by
   software tools used to set up TRILL over UDP paths between specific
   end systems (as might be used within a single data center).

   d.  Use of a "Managed Circuit Breaker" for the TRILL traffic as
   described in [I-D.ietf-tsvwg-circuit-breaker].

10.4.  MTU Considerations

   In TRILL each RBridge advertises in its LSP number zero the largest
   LSP frame it can accept (but not less than 1,470 bytes) on any of its
   interfaces (at least those interfaces with adjacencies to other
   RBridges in the campus) through the originatingLSPBufferSize TLV
   [RFC6325] [RFC7177].  The campus minimum MTU, denoted Sz, is then
   established by taking the minimum of this advertised MTU for all
   RBridges in the campus.  Links that do not meet the Sz MTU are not
   included in the routing topology.  This protects the operation of IS-
   IS from links that would be unable to accommodate some LSPs.

Wasserman, et al.        Expires August 6, 2015                [Page 14]

Internet-Draft                TRILL over IP                February 2015

   A method of determining originatingLSPBufferSize for an RBridge with
   one or more TRILL over IP portsis described in [RFC7180].  However,
   if an IP link either can accommodate jumbo frames or is a link on
   which IP fragmentation is enabled and acceptable, then it is unlikely
   that the IP link will be a constraint on the originatingLSPBufferSize
   of an RBridge using the link.  On the other hand, if the IP link can
   only handle smaller frames and fragmentation is to be avoided when
   possible, a TRILL over IP port might constrain the RBridge's
   originatingLSPBufferSize.  Because TRILL sets the minimum values of
   Sz at 1,470 bytes, there may be links that meet the minimum MTU for
   the IP protocol (1,280 bytes for IPv6, theoretically 68 bytes for
   IPv4) on which it would be necessary to enable fragmentation for
   TRILL use.

   The optional use of TRILL IS-IS MTU PDUs, as specified in [RFC6325]
   and [RFC7177] can provide added assurance of the actual MTU of a

11.  Middlebox Considerations

   ... TBD ...

12.  Security Considerations

   TRILL over IP is subject to all of the security considerations for
   the base TRILL protocol [RFC6325].  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 IPsec, and makes it clear that it is both wise and
   good to use IPsec 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 or is not physically secure.  IPsec
   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
   [RFC5310], which can be used to authenticate RBridges before allowing
   them to join a TRILL campus.  This is sufficient to protect against
   rogue RBridges, but is not sufficient to protect data packets that
   may be sent in IP outside of the local network, or even across the
   public Internet.  To protect the privacy and integrity of that
   traffic, use IPsec.

   In cases were IPsec is used, the use of IS-IS security may not be
   necessary, but there is nothing about this specification that would
   prevent using both IPsec and IS-IS security together.  In cases where

Wasserman, et al.        Expires August 6, 2015                [Page 15]

Internet-Draft                TRILL over IP                February 2015

   both types of security are enabled, by default, a key derived from
   the IS-IS key will be used for IPsec.

13.  IANA Considerations

   IANA considerations are given below.

13.1.  Port Assignments

   IANA has allocated the following destination UDP Ports for the TRILL
   IS-IS and Data channels:

          UDP Port           Protocol

          (TBD)              TRILL IS-IS Channel
          (TBD)              TRILL Data Channel

13.2.  Multicast Address Assignments

   IANA has allocated one IPv4 and one IPv6 multicast address, as shown
   below, which correspond to the All-RBridges and All-IS-IS-RBridges
   multicast MAC addresses that the IEEE Registration Authority has
   assigned for TRILL.  Because the low level hardware MAC address
   dispatch considerations for TRILL over Ethernet do not apply to TRILL
   over IP, one IP multicast address for each version of IP is

   [Values recommended to IANA:]

         Name                 IPv4              IPv6

         All-RBridges      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?]

Wasserman, et al.        Expires August 6, 2015                [Page 16]

Internet-Draft                TRILL over IP                February 2015

14.  Acknowledgements

   This document was written using the xml2rfc tool described in RFC
   2629 [RFC2629].

   The following people have provided useful feedback on the contents of
   this document: Sam Hartman, Adrian Farrel.

   Some material in Section 10.2 is derived from draft-ietf-mpls-in-udp
   by Xiaohu Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, and
   Yongbing Fan.

15.  References

15.1.  Normative References

   [FIPS180]  ""Secure Hash Standard (SHS)", United States of American,
              National Institute of Science and Technology, Federal
              Information Processing Standard (FIPS) 180-4", March 2012.

   [IS-IS]    ""Intermediate system to Intermediate system routeing
              information exchange protocol for use in conjunction with
              the Protocol for providing the Connectionless-mode Network
              Service (ISO 8473)", ISO/IEC 10589:2002.", 2002.

   [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
              October 1969.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710, October

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41, RFC
              2914, September 2000.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

Wasserman, et al.        Expires August 6, 2015                [Page 17]

Internet-Draft                TRILL over IP                February 2015

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405, November

   [RFC6325]  Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, July 2011.

   [RFC7176]  Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D.,
              and A. Banerjee, "Transparent Interconnection of Lots of
              Links (TRILL) Use of IS-IS", RFC 7176, May 2014.

   [RFC7177]  Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V.
              Manral, "Transparent Interconnection of Lots of Links
              (TRILL): Adjacency", RFC 7177, May 2014.

   [RFC7180]  Eastlake, D., Zhang, M., Ghanwani, A., Manral, V., and A.
              Banerjee, "Transparent Interconnection of Lots of Links
              (TRILL): Clarifications, Corrections, and Updates", RFC
              7180, May 2014.

15.2.  Informative References

              Fairhurst, G., "Network Transport Circuit Breakers",
              draft-ietf-tsvwg-circuit-breaker-00 (work in progress),
              September 2014.

              Crabbe, E., Yong, L., and X. Xu, "Generic UDP
              Encapsulation for IP Tunneling", draft-yong-tsvwg-gre-in-
              udp-encap-02 (work in progress), October 2013.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

Wasserman, et al.        Expires August 6, 2015                [Page 18]

Internet-Draft                TRILL over IP                February 2015

   [RFC6361]  Carlson, J. and D. Eastlake, "PPP Transparent
              Interconnection of Lots of Links (TRILL) Protocol Control
              Protocol", RFC 6361, August 2011.

   [RFC7172]  Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D.
              Dutt, "Transparent Interconnection of Lots of Links
              (TRILL): Fine-Grained Labeling", RFC 7172, May 2014.

   [RFC7173]  Yong, L., Eastlake, D., Aldrin, S., and J. Hudson,
              "Transparent Interconnection of Lots of Links (TRILL)
              Transport Using Pseudowires", RFC 7173, May 2014.

Authors' Addresses

   Margaret Wasserman
   Painless Security
   356 Abbott Street
   North Andover, MA  01845

   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

   Phone: +1 508 333-2270
   Email: d3e3e3@gmail.com

   Dacheng Zhang
   Beijing, Chao yang District
   P.R. China

   Email: dacheng.zdc@alibaba-inc.com

Wasserman, et al.        Expires August 6, 2015                [Page 19]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/