INTERNET-DRAFT Margaret Cullen
Intended Status: Proposed Standard Painless Security
Updates: 7177, 7178 Donald Eastlake
Mingui Zhang
Dacheng Zhang
Huawei
Expires: November 30, 2017 May 31, 2017
TRILL (Transparent Interconnection of Lots of Links) over IP<draft-ietf-trill-over-ip-10.txt>
Abstract
The TRILL (Transparent Interconnection of Lots of Links) protocol
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 specifies transmission of encapsulated TRILL
data and TRILL IS-IS over IP (v4 or v6). so as to use an IP network
as a TRILL link in a unified TRILL campus. This document updates RFC7177 and updates RFC 7178.
Status of This Document
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors or the TRILL Working Group mailing list
<dnsext@ietf.org>.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Margaret Cullen, et al [Page 1]

INTERNET-DRAFT TRILL over UDP1. Introduction
TRILL switches (also know as RBridges) are devices that implement the
IETF TRILL protocol [RFC6325] [RFC7177] [RFC7780]. TRILL provides
transparent forwarding of frames within an arbitrary network
topology, using least cost paths for unicast traffic. It supports
VLANs and Fine Grained Labels [RFC7172] as well as multipathing of
unicast and multi-destination traffic. It uses IS-IS [IS-IS]
[RFC7176] link state routing with a TRILL header having a hop count.
RBridge ports can communicate with each other over various protocols,
such as Ethernet [RFC6325], pseudowires [RFC7173], or PPP [RFC6361].
This document specifies transmission of encapsulated TRILL data and
TRILL IS-IS over IP (v4 or v6 [rfc2460bis]). so as to use an IP
network as a TRILL link in a unified TRILL campus. Three
encapsulations specified herein, two based on UDP and one based on
TCP but provision is made to negotiate other encapsulations. TRILL
over IP allows RBridges with IP connectivity to form a single TRILL
campus, or multiple TRILL networks to be connected as a single TRILL
campus via a TRILL over IP backbone.
The protocol specified in this document connects RBridge ports using
transport over IP in such a way that the ports with IP connectivity
appear to TRILL to be connected by a single multi-access link. If a
set of more than two RBridge ports are connected via a single TRILL
over IP link, each RBridge port in the set can communicate with every
other RBridge port in the set.
To support the scenarios where RBridges are connected via IP paths
(including those 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 (ESP) [RFC4303] for security.
To dynamically select a mutually supported TRILL over IP
encapsulation, normally one with good fast path hardware support, a
method is provided for agreement between adjacent TRILL switch ports
as to what encapsulation to use. Alternatively, where a common
encapsulation is known to be supported by the TRILL switch ports on a
link, they can simply be configured to always use that encapsulation.
This document updates [RFC7177] and [RFC7178] as described in
Sections 5 and 11.3 by making adjacency between TRILL over IP ports
dependent on having a method of encapsulation in common and by
redefining an interval of RBridge Channel protocol numbers to
indicate link technology specific capabilities, in this case
encapsulation methods supported for TRILL over IP.
Margaret Cullen, et al [Page 4]

INTERNET-DRAFT TRILL over UDP3. 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.
3.1 Remote Office Scenario
In the Remote Office Scenario, as shown in the example below, 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 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 campus.
/---------------\ /---------------\
| Remote | | Remote |
| Office | | Office |
| | | |
| +-------+ | | +-------+ |
\---|RBridge|---/ \---|RBridge|---/
+-----+-+ +-+-----+
| |
/---------------------------------------------\
| | The Internet | |
\---------------------------------------------/
| |
+-+-----+ +-----+-+
/----|RBridge|---------------|RBridge|----\
| +-------+ +-------+ |
| |
| Main TRILL Campus |
\-----------------------------------------/
3.2 IP Backbone Scenario
In the IP Backbone Scenario, as shown in the example below, 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
Margaret Cullen, et al [Page 6]

INTERNET-DRAFT TRILL over UDP
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 campus.
/---------------------------------------------\
| Unified TRILL Campus |
| |
| TRILL Over IP Backbone |
| -----+------------+------------+----- |
| | | | |
| +---+---+ +---+---+ +---+---+ |
| |RBridge| |RBridge| |RBridge| |
| +---+---+ +---+---+ +---+---+ |
| | | | |
| ---+--- ---+--- ---+--- |
| TRILL Local Links or Networks |
| |
\---------------------------------------------/
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
unauthorized 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 tunnel,
over the public Internet. It is necessary in this scenario to protect
the integrity and confidentiality of user traffic, as well as
Margaret Cullen, et al [Page 7]

INTERNET-DRAFT TRILL over UDP
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 IP 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 IP unicast to the intended recipients.
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 IP unicast, as discussed later
in this document.
3.3.3 Neighbor Discovery
In the IP Backbone Scenario, TRILL switches that use TRILL over IP
can use the normal TRILL IS-IS Hello mechanisms to discover the
existence of other TRILL switches on the link [RFC7177], and to
establish authenticated communication with them.
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 TRILL switch 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.
Margaret Cullen, et al [Page 8]

INTERNET-DRAFT TRILL over UDP4.2 General TRILL Over IP Packet Formats
In TRILL over IP, we use an IP (v4 or v6) header followed by an
encapsulation header, such as UDP, as the link header. (On the wire,
the IP header will normally be preceded by the lower layer header of
a protocol that is carrying IP; however, this does not concern us at
the level of this document.)
There are multiple IP based encapsulations usable for TRILL over IP
that differ in exactly what appears after the IP header and before
the TRILL Header or the TRILL IS-IS Payload. Those encapsulations
specified in this document are further detailed in Section 5. In the
general specification below, those encapsulation fields will be
represented as "ENCAP Hdr".
4.2.1 Without Security
When TRILL over IP link security is not being used, a TRILL over IP
packet on the wire looks like one of the following:
TRILL Data Packet
+---------+-----------+---------+------------------+
| IP | ENCAP Hdr | TRILL | Native frame |
| Header | for Data | Header | Payload |
+---------+-----------+---------+------------------+
<--- link header ---->
TRILL IS-IS Packet
+---------+-----------+-----------------+
| IP | ENCAP Hdr | TRILL IS-IS |
| Header | for IS-IS | Payload |
+---------+-----------+-----------------+
<--- link header ---->
As discussed above and further specified in Section 5, the ENCAP Hdr
indicates whether the packet is TRILL Data or IS-IS.
4.2.2 With Security
TRILL over IP link security uses IPsec Encapsulating Security
Protocol (ESP) in tunnel mode [RFC4303]. Since TRILL over IP always
starts with an IP Header (on the wire this appears after any lower
layer header that might be required), the modifications for IPsec are
independent of the TRILL over IP ENCAP Hdr that occurs after that IP
Header. The resulting packet formats are as follows for IPv4 and
IPv6:
Margaret Cullen, et al [Page 10]

INTERNET-DRAFT TRILL over UDP
With IPv4:
+-------------+-----+--------------+-----------+-----------+
| new IP Hdr | ESP | TRILL IP Hdr | ENCAP Hdr | ESP |ESP|
|(any options)| Hdr | (any options)| + payload |Trailer|ICV|
+-------------+-----+--------------+-----------+-----------+
|<---------- encryption ---------->|
|<-------------- integrity ------------->|
With IPv6:
+------+-------+-----+------+--------+-----------+-------+---+
| new |new ext| ESP | orig |orig ext| ENCAP Hdr | ESP |ESP|
|IP Hdr| Hdrs | Hdr |IP Hdr| Hdrs | + payload |Trailer|ICV|
+------+-------+-----+------+--------+-----------+-------+---+
|<----------- encryption ---------->|
|<--------------- integrity ------------->|
As shown above, IP Header options are considered part of the IPv4
Header but are extensions ("ext") of the IPv6 Header. For further
information on the IPsec ESP Hdr, Trailer, and ICV, see [RFC4303] and
Section 7 below. "ENCAP Hdr + payload" is the encapsulation header
(Section 5) and TRILL data or the encapsulation header and IS-IS
payload, that is, the material after the IP Header in the diagram in
Section 4.2.1.
This architecture permits the ESP tunnel end point to be separated
from the TRILL over IP RBridge port (see, for example, Section 1.1.3
of [RFC7296]).
4.3 QoS Considerations
In IP, QoS handling is indicated by the Differentiated Services Code
Point (DSCP [RFC2474] [RFC3168]) in the IP Header. The former Type
of Service (TOS) octet in the IPv4 Header and the Traffic Class octet
in the IPv6 Header has been divided as shown in the following diagram
adapted from [RFC3168]. (TRILL support of ECN is beyond the scope of
this document. See [TRILLECN].)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP FIELD | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: Differentiated Services Codepoint
ECN: Explicit Congestion Notification
Within a TRILL switch, priority is indicated by configuration for
TRILL IS-IS packets and for TRILL Data packets by a three bit (0
through 7) priority field and a Drop Eligibility Indicator bit (see
Margaret Cullen, et al [Page 11]

INTERNET-DRAFT TRILL over UDP
Sections 8.2 and 7 of [RFC7780]). (Typically TRILL IS-IS is
configured to use the highest two priorities depending on the IS-IS
PDU.) The priority affects queuing behavior at TRILL switch ports and
may be encoded into the link header, particularly if there could be
priority sensitive devices within the link. For example, if the link
is a bridged LAN, it is commonly encoded into an Outer.VLAN tag's
priority and DEI fields.
TRILL over IP implementations MUST support setting the DSCP value in
the outer IP Header of TRILL packets they send by mapping the TRILL
priority and DEI to the DSCP. They MAY support, for a TRILL Data
packet where the native frame payload is an IP packet, mapping the
DSCP in this inner IP packet to the outer IP Header with the default
for that mapping being to copy the DSCP without change.
The default TRILL priority and DEI to DSCP mapping, which may be
configured per TRILL over IP port, is an follows. Note that the DEI
value does not affect the default mapping and, to provide a
potentially lower priority service than the default priority 0,
priority 1 is considered lower priority than 0. So the priority
sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7.
TRILL Priority DEI DSCP Field (Binary/decimal)
-------------- --- -----------------------------
0 0/1 001000 / 8
1 0/1 000000 / 0
2 0/1 010000 / 16
3 0/1 011000 / 24
4 0/1 100000 / 32
5 0/1 101000 / 40
6 0/1 110000 / 48
7 0/1 111000 / 56
4.4 Broadcast Links and Multicast Packets
TRILL supports broadcast links. These are links to which more than
two TRILL switch ports can be attached and where a packet can be
broadcast or multicast from a port to all or a subset of the other
ports on the link as well as unicast to a specific other port on the
link.
As specified in [RFC6325], TRILL Data packets being forwarded between
TRILL switches can be unicast on a link to a specific TRILL switch
port or multicast on a link to all TRILL switch ports. TRILL IS-IS
packets are always multicast to all other TRILL switches on the link
except for IS-IS MTU PDUs, which may be unicast [RFC7177]. This
distinction is not significant if the link is inherently point-to-
point, such as a PPP link; however, on a broadcast link there will be
Margaret Cullen, et al [Page 12]

INTERNET-DRAFT TRILL over UDP
a packet outer link address that will be unicast or multicast as
appropriate. For example, over Ethernet links, the Ethernet multicast
addresses All-RBridges and All-IS-IS-RBridges are used for
multicasting TRILL Data and TRILL IS-IS respectively. For details on
TRILL over IP handling of multicast, see Section 6.
4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment
IS-IS routers, including TRILL switches, establish adjacency through
the exchange of Hello PDUs on a link [RFC7176] [RFC7177]. The Hellos
transmitted out a port indicate what neighbor ports that port can see
on the link by listing what IS-IS refers to as the neighbor port's
SubNetwork Point of Attachment (SNPA). (For an Ethernet link, which
may be a bridged network, the SNPA is the port MAC address.)
In TRILL Hello PDUs on a TRILL over IP link, the IP addresses of the
IP ports connected to that link are their actual SNPA (SubNetwork
Point of Attachment [IS-IS]) addresses and, for IPv6, the 16-byte
IPv6 address is used as the SNPA; however, for easy in re-using code
designed for the common case of 48-bit SNPAs, in 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] in such Hellos. This synthetic SNPA is derived
from the port IPv4 address is as follows:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 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, when TRILL operates on an IP link, TRILL sees
only IP addresses on that link, not MAC stations, even if the TRILL
over IP Link is being carried over Ethernet. Therefore conflict on
the link between a real MAC address and a TRILL over IP synthetic
SNPA (MAC) address would be impossible in any case.
Margaret Cullen, et al [Page 13]

INTERNET-DRAFT TRILL over UDP5. TRILL over IP Encapsulation Formats
There are a variety of TRILL over IP encapsulation formats possible.
By default TRILL over IP adopts a hybrid encapsulation approach.
There is one format, called "native encapsulation" that MUST be
implemented. Although native encapsulation does not typically have
good fast path support, as a lowest common denominator it can be used
by low bandwidth control traffic to determine a preferred
encapsulation with better performance. In particular, by default, all
TRILL IS-IS Hellos are sent using native encapsulation and those
Hellos are used to determine the encapsulation used for all TRILL
Data packets and all other TRILL IS-IS PDUs (with the exception of
IS-IS MTU-probe and MTU-ack PDUs used to establish adjacency).
Alternatively, the network operator can pre-configure a TRILL over IP
port to use a particular encapsulation chosen for their particular
network's needs and port capabilities. That encapsulation is then
used for all TRILL Data and IS-IS packets on ports so configured.
This is expected to frequently be the case for a managed campus of
TRILL switches.
Section 5.1 discusses general consideration for the TRILL over IP
encapsulation format. Section 5.2 discusses encapsulation agreement.
Section 5.3 discusses broadcast link encapsulation considerations.
The subsequent subsections discuss particular encapsulations.
5.1 Encapsulation Considerations
An encapsulation must provide a method to distinguish TRILL Data
packets and TRILL IS-IS packets or it is not useful for TRILL. In
addition, the following criteria can be helpful is choosing between
different encapsulations:
a) Fast path support - For most applications, it is highly desirable
to be able to encapsulate/decapsulate TRILL over IP at line speed
so a format where existing or anticipated fast path hardware can
do that is best. This is commonly the dominant consideration.
b) Ease of multi-pathing - The IP path between TRILL over IP ports
may include equal cost multipath routes internal to the IP link so
a method of encapsulation that provides variable fields available
for existing or anticipated fast path hardware multi-pathing is
preferred.
c) Robust fragmentation and re-assembly - The MTU of the IP link may
require fragmentation in which case an encapsulation with robust
fragmentation and re-assembly is important. There are known
Margaret Cullen, et al [Page 14]

INTERNET-DRAFT TRILL over UDP
problems with IPv4 fragmentation and re-assembly [RFC6864] which
generally do not apply to IPv6. Some encapsulations can fix these
problems but the encapsulations specified in this document do not.
Therefore, if fragmentation is anticipated with the encapsulations
specified in this document, the use of IPv6 is RECOMMENDED.
d) Checksum strength - Depending on the particular circumstances of
the TRILL over IP link, a checksum provided by the encapsulation
may be a significant factor. Use of IPsec can also provide a
strong integrity check.
5.2 Encapsulation Agreement
TRILL Hellos sent out a TRILL over IP port indicate the
encapsulations that port is willing to support through a mechanism
initially specified in [RFC7178] and [RFC7176] that is hereby
extended. Specifically, RBridge Channel Protocol numbers 0xFD0
through 0xFF7 are redefined to be link technology dependent flags
that, for TRILL over IP, indicate support for different
encapsulations, allowing support for up to 40 encapsulations to be
specified. Support for an encapsulation is indicated in the Hello
PDU in the same way that support for an RBridge Channel was
indicated. (See also section 11.3.) "Support" indicates willingness
to use that encapsulation for TRILL Data and TRILL IS-IS packets
(although TRILL IS-IS Hellos are still sent in native encapsulation
by default unless the port is configured to always use some other
encapsulation).
If, in a TRILL Hello on a TRILL over IP link, support is not
indicated for any encapsulation, then the port from which it was sent
is assumed to support only native encapsulation (see Section 5.4).
An adjacency can be formed between two TRILL over IP ports if the
intersection of the sets of encapsulation methods they support is not
null. If that intersection is null, then no adjacency is formed. In
particular, for a TRILL over IP link, the adjacency state machine
MUST NOT advance to the Report state unless the ports share an
encapsulation [RFC7177]. If no encapsulation is shared, the adjacency
state machine remains in the state from which it would otherwise have
transitioned to the Report state.
If a TRILL over IP port is using an encapsulation different from that
in which Hellos are being exchanged, it is RECOMMENDED that BFD
[RFC7175] or some other protocol that confirms adjacency using TRILL
Data packets be used. As provided in [RFC7177] adjacency is not
actually obtain until such confirmatory protocol succeeds.
If any TRILL over IP packet, other than an IS-IS Hello or MTU PDU in
Margaret Cullen, et al [Page 15]

INTERNET-DRAFT TRILL over UDP
native encapsulation, is received in an encapsulation for which
support is not being indicated by the receiver, that packet MUST be
discarded (see Section 5.3).
If there are two or more encapsulations in common between two
adjacent ports for unicast or the set of adjacent ports for
multicast, a transmitter is free to choose whichever of the
encapsulations it wishes to use. Thus transmissions between adjacent
ports P1 and P2 could use different encapsulations depending on which
port is transmitting and which is receiving.
It is expected to be the normal case in a well-configured network
that all the TRILL over IP ports connected to an IP link (i.e., an IP
network) that are intended to communicate with each other will
support the same encapsulation(s).
5.3 Broadcast Link Encapsulation Considerations
To properly handle TRILL protocol packets on a TRILL over IP link in
the general case, either native IP multicast mode is used on that
link or multicast must be simulated using serial IP unicast, as
discussed in Section 6. (Of course, if the IP link happens to
actually be point-to-point no special provision is needed for
handling IP multicast addressed packets.)
It is possible for the Hellos from a TRILL over IP port P1 to
establish adjacency with multiple other TRILL over IP ports (P2, P3,
...) on a broadcast link. In a well-configured network one would
expect all of the IP ports involved to support the same
encapsulation(s); but, for example, if P1 supports multiple
encapsulations, it is possible that P2 and P3, do not have an
encapsulation in common that is supported by P1. [IS-IS] can handle
such non-transitive adjacencies that are reported as specified in
[RFC7177]. This is generally done, albeit with reduced efficiency, by
forwarding through the designated RBridge (router) on the link. Thus
it is RECOMENDED that all TRILL over IP ports on an IP link be
configured to support one encapsulation in common that has good fast
path support.
If serial IP unicast is being used by P1, it can use different
encapsulations for different transmissions.
If native IP multicast is available for use by P1, it can send one
transmission per encapsulation method by which it has a disjoint set
of adjacencies on the link. If the transmitting port has adjacencies
with overlapping sets of ports that are adjacent using different
encapsulations, use of native multicast with different encapsulations
may result in packet duplication. It would always be possible to use
Margaret Cullen, et al [Page 16]

INTERNET-DRAFT TRILL over UDP
native IP multicast for one encapsulation for which the transmitting
port has adjacencies, perhaps the encapsulation for which it has the
largest number of adjacencies, and serially unicast to other
receivers. These considerations are the reason that a TRILL over IP
port MUST discard any packet received with an encapsulation for which
it has not established an adjacency with the transmitter. Otherwise,
packets would be further duplicated.
5.4 Native Encapsulation
The mandatory to implement "native encapsulation" format of a TRILL
over IP packet, when used without security, is TRILL over UDP as
shown below. This provides simple and direct access by TRILL to the
native datagram service of IP.
+----------+--------+-----------------------+
| 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 8.3
Destination Port - indicates TRILL Data or IS-IS, see Section11.1.
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.
Margaret Cullen, et al [Page 17]

INTERNET-DRAFT TRILL over UDP5.5 VXLAN Encapsulation
VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, like
TRILL over Ethernet over VXLAN over UDP over IP.
+--------+--------+--------+----------+-----------+
| IP | UDP | VXLAN | Ethernet | TRILL |
| Header | Header | Header | Header | Payload |
+--------+--------+--------+----------+-----------+
The outer UDP uses a destination port number indicating VXLAN and the
outer UDP source port MAY be used for entropy as with native
encapsulation (see Section 8.3). The VXLAN header after the outer UDP
header adds a 24 bit Virtual Network Identifier (VNI). The Ethernet
header after the VXLAN header and before the TRILL header consists of
source MAC address, destination MAC address, and Ethertype. The
Ethertype distinguishes TRILL Data from TRILL IS-IS. The destination
and source MAC addresses in this Ethernet header are not used.
A TRILL over IP port using VXLAN encapsulation by default uses a VNI
of 1 for TRILL IS-IS traffic and a VNI of 2 for TRILL data traffic
but can be configured as described in Section 9.2.3.1 to use some
other fixed VNIs or to map from VLAN/FGL to VNI.
5.6 TCP Enacpulstion
TCP may be used for TRILL over IP as specified below. Use of TCP is
convenient to provide congestion control (see Section 8.1) and
reduced packet loss but is likely to cause substantial additional
jitter and delay compared with a UDP based encapsulation.
+----------+--------+-----------------------+
| IP | TCP | TRILL |
| Header | Header | Payload |
+----------+--------+-----------------------+
Where the TCP Header is as follows:
Margaret Cullen, et al [Page 18]

INTERNET-DRAFT TRILL over UDP6. Handling Multicast
By default, both TRILL IS-IS packets and multi-destination TRILL Data
packets are sent to an All-RBridges IPv4 or IPv6 IP multicast Address
as appropriate (see Section 11.2); however, a TRILL over IP port may
be configured (see Section 9) to use a different multicast address or
to use serial IP unicast with a list of one or more unicast IP
addresses of other TRILL over IP ports to which multi-destination
packets are sent. In the serial unicast case the outer IP header of
each copy of the packet sent shows an IP unicast destination address
even through the TRILL header has the M bit set to one to indicate
multi-destination. Serial unicast configuration is necessary if the
TRILL over IP port is connected to an IP network that does not
support IP multicast. In any case, unicast TRILL packets (those with
the M bit in the TRILL Header set to zero) are sent by unicast IP.
Even if a TRILL over IP port is configured to send multi-destination
packets with serial unicast, it MUST be prepared to receive IP
multicast TRILL packets. All TRILL over IP ports default to
periodically transmitting appropriate IGMP (IPv4 [RFC3376]) or MLD
(IPv6 [RFC2710]) packets, so that the TRILL multicast IP traffic can
be sent to them, but may be configured not to do so.
Although TRILL fully supports broadcast links with more than 2
RBridges connected to the link there may be good reasons for
configuring TRILL over IP ports to use serial unicast even where
native IP multicast is available. Use of serial unicast provides the
network manager with more precise control over adjacencies and how
TRILL over IP links will be formed in an IP network. In some
networks, unicast is more reliable than multicast. If multiple point-
to-point TRILL over IP connections between two 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 fails or incorporate a new link that comes up.
Margaret Cullen, et al [Page 20]

INTERNET-DRAFT TRILL over UDP7. Use of IPsec and IKEv2
All TRILL switches (RBridges) that support TRILL over IP MUST
implement IPsec [RFC4301] and support the use of IPsec Encapsulating
Security Protocol (ESP [RFC4303]) in tunnel mode 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,
implementers SHOULD use IS-IS security to protect TRILL IS-IS
packets. However, in this case, the IPsec session still MUST be fully
established before any TRILL Data packets transmission, since IS-IS
security does not provide any protection to data packets, and SHOULD
be fully established before any TRILL IS-IS packet transmission other
than IS-IS Hello or MTU PDUs.
All RBridges that support TRILL over IP MUST implement the Internet
Key Exchange Protocol version 2 (IKEv2) for automated key management.
7.1 Keying
The following subsections discuss pairwise and group keying for TRILL
over IP IPsec.
7.1.1 Pairwise Keying
When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
incorporates the IS-IS shared key in order to bind the TRILL data
session to the IS-IS session. The pre-shared key that will be used
for IKEv2 exchanges for TRILL over IP is determined as follows:
HKDF-Expand-SHA256 ( IS-IS-key,
"TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port )
In the above "|" indicates concatenation, HKDF is as in [RFC5869],
SHA256 is as in [RFC6234], and "TRILL IP" is the eight byte US ASCII
[RFC0020] string indicated. "IS-IS-key" is an IS-IS key usable for
IS-IS security of link local IS-IS PDUs such as Hello, CSNP, and
PSNP. This SHOULD be a link scope IS-IS key. P1-System-ID and
P2-System ID are the six byte System IDs of the two TRILL RBridges,
and P1-Port and P2-Port are the TRILL Port IDs [RFC6325] of the ports
in use on each end. System IDs are guaranteed to be unique within the
TRILL campus. Both of the RBridges involved treat the larger
magnitude System ID, comparing System IDs as unsigned integers, as P1
and the smaller as P2 so both will derive the same key.
Margaret Cullen, et al [Page 21]

INTERNET-DRAFT TRILL over UDP
With [RFC5310] there could be multiple keys identified with 16-bit
key IDs. The key ID when an IS-IS key is in use is transmitted in an
IKEv2 ID_KEY_ID identity field [RFC7296] with Identification Data
length of 2 bytes (Payload Length 6 bytes). The Key ID of the IS-IS-
key is used to identify the IKEv2 shared secret derived as above that
is actually used. ID_KEY_ID identity field(s) of other lengths MAY
occur but their use is beyond the scope of this document.
The IS-IS-shared key from which the IKEv2 shared secret is derived
might expire and be updated as described in [RFC5310]. The IKEv2
pre-shared keys derived from an IS-IS shared key MUST expire within a
lifetime no longer than the IS-IS-shared key from which they were
derived. When the IKEv2 shared secret key expires, or earlier, the
IKEv2 Security Association must be rekeyed using a new shared secret
derived from a new IS-IS shared key.
IKEv2 with certificate based security MAY be used but details of
certificate contents and use policy for this application of IKEv2 are
beyond the scope of this document.
7.1.2 Group Keying
In the case of a TRILL over IP port configured as point-to-point (see
Section 4.2.4.1 of [RFC6325]), there is no group keying and the
pairwise keying determined as in Section 7.1.1 is used for multi-
destination TRILL traffic, which is unicast.
In the case of a TRILL over IP port configured as broadcast but where
the port is configured to use serial unicast (see Section 8), there
is no group keying and the pairwise keying determined as in Section7.1.1 is used for multi-destination TRILL traffic, which is unicast.
The case of a TRILL over IP port configured as broadcast and using
native multicast is beyond the scope of this document. For security
as provided in this document, multicast is handled via serial
unicast.
7.2 Mandatory-to-Implement Algorithms
All RBridges that support TRILL over IP MUST implement IPsec ESP
[RFC4303] in tunnel mode. The implementation requirements for ESP
cryptographic algorithms are as specified for IPsec. That
specification is currently [RFC7321].
Margaret Cullen, et al [Page 22]

INTERNET-DRAFT TRILL over UDP8. Transport Considerations
This section discusses a variety of important transport
considerations.
8.1 Congestion Considerations
This subsection discusses TRILL over UDP congestion considerations.
These are applicable to the UDP based TRILL over IP encapsulation
headers specified in detail in this document. Other encapsulations
would likely have different congestion considerations and, in
particlar, the TCP encapsulation specified in Section 5.6 does not
need congestion control beyond that provided by TCP. Congestion
considerations for additional TRILL encapsulations will be provided
in the document specifying the encapsulation.
One motivation for including UDP or TCP as the outermost part of a
TRILL over IP encapsulation header is to improve the use of multipath
such as Equal Cost Multi-Path (ECMP) in cases where traffic is to
traverse routers that are able to hash on Port and IP address through
addition of entropy in the source port (see Section 8.3). 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.
Section 3.1.11 of [RFC8085] discusses the congestion considerations
for design and use of UDP tunnels; this is important because other
flows could share the path with one or more UDP tunnels,
necessitating congestion control [RFC2914] to avoid destructive
interference.
The default initial determination of the TRILL over IP encapsulation
to be used is through the exchange of TRILL IS-IS Hellos. This is a
low bandwidth process. Hellos are not permitted to be sent any more
often than once per second, and so are very unlikely to cause
congestion. Thus no additional controls are needed for Hellos even
if sent, as is the default, over UDP.
Congestion has potential impacts both on the rest of the network
containing a UDP flow and on the traffic flows using the UDP
encapsulation. These impacts depend upon what sort of traffic is
carried in UDP, as well as the path it follows. The UDP based TRILL
over IP encapsulations specified in this document do not provide any
congestion control and are transmitted as regular UDP packets.
The two subsections below discuss congestion for TRILL over IP
Margaret Cullen, et al [Page 23]

INTERNET-DRAFT TRILL over UDP
traffic with UDP based encapsulation headers in traffic-managed
controlled environments (TMCE, see [RFC8086]) and other environments.
8.1.1 Within a TMCE
Within a TMCE, that is, an IP network that is traffic-engineered
and/or otherwise managed, for example via use of traffic rate
limiters, to avoid congestion, UDP based TRILL over IP encapsulation
headers are appropriate for carrying traffic that is not known to be
congestion controlled. in such cases, operators of TMCE networks
avoid congestion by careful provisioning of their networks, rate-
limiting of user data traffic, and traffic engineering according to
path capacity.
When TRILL over IP using a UDP based encapsulation header carries
traffic that is not known to be congestion controlled in a TMCE
network, the traffic path MUST be entirely within that network, and
measures SHOULD be taken to prevent the traffic from "escaping" the
network to the general Internet. Examples of such measures are:
o physical or logical isolation of the links carrying the traffic
from the general Internet and
o deployment of packet filters that block the UDP ports assigned
for TRILL over IP.
8.1.2 In Other Environments
Where UDP based encapsulation headers are used in TRILL over IP in
environments other than those discussed in Section 8.1.1, specific
congestion control mechanisms are commonly needed. However, if the
traffic being carried by the TRILL over IP link is already congestion
controlled and the size and volatility of the TRILL IS-IS link state
database is limited, then specific congestion control may not be
needed. See [RFC8085] Section 3.1.11 for further guidance.
8.2 Recursive Ingress
TRILL is specified to transport data to and from end stations over
Ethernet and IP is frequently transported over Ethernet. Thus, an end
station native data Ethernet frame "EF" might get TRILL ingressed to
TRILL(EF) that was subsequently sent to a next hop RBridge out a
TRILL over IP over Ethernet port resulting in a packet on the wire of
the form Ethernet(IP(TRILL(EF))). There is a risk of such a packet
Margaret Cullen, et al [Page 24]

INTERNET-DRAFT TRILL over UDP
being re-ingressed by the same TRILL campus, due to physical or
logical misconfiguration, looping round, being further re-ingressed,
and so on. (Or this might occur through a cycle of TRILL campuses.)
The packet would 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 TRILL header with a new TTL.
To protect against this scenario, a TRILL over IP port MUST, by
default, test whether a TRILL packet it is about to transmit appears
to be a TRILL ingress of a TRILL over IP over Ethernet packet. That
is, is it of the form TRILL(Ethernet(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.
8.3 Fat Flows
For the purpose of load balancing, it is worthwhile to consider how
to transport TRILL packets over any Equal Cost Multiple Paths (ECMPs)
existing internal to the IP path between TRILL over IP ports.
The ECMP election for the IP traffic could be based, for example with
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. One
solution to this is to use the UDP Source Port as an entropy field.
(This idea is also introduced in [RFC8086].) For example, for TRILL
Data, this entropy field could be based on some hash of the
Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. Unfortunately,
this can conflict with middleboxes inside the TRILL over IP link (see
8.5). Therefore, in order to better support ECMP, a RBridge SHOULD
set the Source Port to a range of values as an entropy field for ECMP
decisions; this range SHOULD be the ephemeral port range
(49152-65535) except that, if there are middleboxes in the path (see
Section 8.5), it MUST be possible to configure the range of different
Source Port values to a sufficiently small range to avoid disrupting
connectivity.
Margaret Cullen, et al [Page 25]

INTERNET-DRAFT TRILL over UDP8.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 TRILL
switches in the campus) through the originatingLSPBufferSize TLV
[RFC6325] [RFC7177]. The campus minimum MTU (Maximum Transmission
Unit), 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
the largest LSPs.
A method of determining originatingLSPBufferSize for an RBridge with
one or more TRILL over IP ports is described in [RFC7780]. 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, RBridges
will not constrain LSPs or other TRILL IS-IS PDUs to a size smaller
than that. Therefore there may be TRILL over IP links that require
fragmentation to be enabled to accommodate such PDUs. When
fragmentation is enabled, the effective link MTU from the TRILL point
of view is larger than the RBridge port to RBridge port path MTU from
the IP point of view. Path MTU discovery [RFC4821] should be useful
in determining the IP MTU between a pair of RBridge ports with IP
connectivity.
TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
[RFC7177], can be used to obtain added assurance of the MTU of a
link. An appropriate time to confirm MTU, or re-discover it if it
has changed, is when an RBridge notices topology changes in a path
that is in use for TRILL over IP due to LSP updates it receives;
however, MTU can change at other times. For example, two RBridge
ports are connected by a bridged LAN, topology or configuration
changes within that bridged LAN could change the MTU between those
RBridge ports.
For further discussion of these issues, see [IntareaTunnels].
Margaret Cullen, et al [Page 26]

INTERNET-DRAFT TRILL over UDP8.5 Middlebox Considerations
This section gives some middlebox considerations for the IP
encapsulations covered by this document, namely native and VXLAN
encapsulation.
The requirements for the usage of the zero UDP Checksum in a UDP
tunnel protocol are detailed in [RFC6936]. These requirements apply
to the UDP based TRILL over IP encapsulations specified herein
(native and VXLAN), which are applications of UDP tunnel.
Besides the Checksum, the Source Port number of a UDP or TCP based
ENCAP Hdr is also pertinent to the middlebox behavior. Network
Address/Port Translator (NAPT) is the most commonly deployed Network
Address Translation (NAT) device [RFC4787]. For a UDP or TCP tunnel
protocol, the NAPT device establishes a NAT session to translate the
{private IP address, private source port number} tuple to a {public
IP address, public source port number} tuple, and vice versa, for the
duration of the session. This provides the tunnel protocol
application with the "NAT-pass-through" function. NAPT allows
multiple internal hosts to share a single public IP address. The
Source Port number, is used as the demultiplexer of the multiple
internal hosts.
However, the above NAPT behavior conflicts with the behavior that the
Source Port number is used as an entropy (See Section 8.3). Hence,
the network operator MUST ensure the TRILL switch ports sending
through local or remote NAPT middleboxes limit the entropy usage of
the Source Port number, possibly to a single value.
Margaret Cullen, et al [Page 27]

INTERNET-DRAFT TRILL over UDP9. TRILL over IP Port Configuration
This section specifies the configuration information needed at a
TRILL over IP port beyond that needed for a general RBridge port.
9.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 (see Section 4.4.2 of [RFC6325])
with each logical port.
By default a TRILL over IP port discards output packets that fail the
possible recursive ingress test (see Section 10.1) unless configured
to disable that test.
9.2 Additional per IP Address Configuration
The configuration information specified below is per TRILL over IP
port IP address.
The mapping from TRILL packet priority to TRILL over IP
Differentiated Services Code Point (DSCP [RFC2474]) can be
configured. If supported, mapping from an inner DSCP code point, when
the TRILL payload is IP, to the outer TRILL over IP DSCP can be
configured. (See Section 4.3.)
Each TRILL over IP port has a list of acceptable encapsulations it
will use as the basis of adjacency. By default this list consists of
one entry for native encapsulation (see Section 7). Additional
encapsulations MAY be configured and native encapsulation MAY be
removed from this list by configuration. Additional configuration can
be required or possible for specific encapsulations as described in
Section 9.2.3.
Each IP address at a TRILL over IP port uses native IP multicast by
default but may be configured whether to use serial IP unicast
(Section 9.2.2) or native IP multicast (Section 9.2.1). Each IP
address at a TRILL over IP is configured whether or not to use IPsec
(Section 9.2.4).
Regardless of whether they will send IP multicast, TRILL over IP
Margaret Cullen, et al [Page 28]

INTERNET-DRAFT TRILL over UDP
ports emit appropriate IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710])
packets unless configured not to do so. These are sent for the IP
multicast group the port would use if it sent IP multicast.
9.2.1 Native Multicast Configuration
If a TRILL over 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 IP multicast address (IPv4
or IPv6) specified in Section 11.2. The TRILL over IP port may be
configured to use a different IP multicast address for multicasting
packets.
9.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 with the same IP version as the version of the port's IP
address (IPv4 or IPv6). 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. IP packets received from a source IP address
not on the list are discarded.
If this list of destination IP addresses is empty, the port is
disabled.
9.2.3 Encapsulation Specific Configuration
Specific TRILL over IP encapsulation methods may provide for further
configuration as specified below.
9.2.3.1 UDP and TCP Source Port
As discussed above, the UDP based encapsulation (Sections 5.4 and
5.5) and the TCP encapuslation (Section 5.6) start with a header
containing a source port number that can be used for entropy (Section8.3). The range of source port values used defaults to the ephemeral
port range (49152-65535) but can be configured to any other range
including to a single value.
Margaret Cullen, et al [Page 29]

INTERNET-DRAFT TRILL over UDP9.2.3.2 VXLAN Configuration
A TRILL over IP port using VXLAN encapsulation can be configured with
non-default VXLAN Network Identifiers (VNIs) that are used in that
field of the VXLAN header for all TRILL IS-IS and TRILL Data packets
sent using the encapsulation and required in those received using the
encapsulation. The default VNI is 1 for TRILL IS-IS and 2 for TRILL
Data. A TRILL packet received with the an unknown VNI is discarded.
A TRILL over IP port using VXLAN encapsulation can also be configured
to map the Inner.VLAN of a TRILL Data packet being transported to the
value it places in the VNI field and/or to copy the Inner.FGL
[RFC7172] of a TRILL Data packet to the VNI field.
9.2.3.3 Other Encapsulation Configuration
Additional encapsulation methods, beyond those specified in this
document, are expected to be specified in future documents and may
require further configuration.
9.2.4 Security Configuration
A TRILL over IP port can be configured, for the case where IS-IS
security [RFC5310] is in use, as to whether or not IPsec must be
fully established and used for any TRILL IS-IS transmissions other
than IS-IS Hello or MTU PDUs (see Section 7). There may also be
configuration whose details are outside the scope of this document
concerning certificate based IPsec or use of shared keys other than
IS-IS based shared key or how to select what IS-IS based shared key
to use.
Margaret Cullen, et al [Page 30]

INTERNET-DRAFT TRILL over UDP10. 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 3 above.
For communication between end stations in a TRILL campus, security
may be possible at three levels: end-to-end security between those
end stations, edge-to-edge security between ingress and egress
RBridges [LinkSec], and link security to protect a TRILL hop. Any
combination of these can be used, including all three.
TRILL over IP link security protects the contents of TRILL Data and
IS-IS packets, including the identities of the end stations for
data and the identities of the edge RBridges, from observers of
the link and transit devices within the link such as bridges or IP
routers, but does not encrypt the link local IP addresses used in
a packet and does not protect against observation by the sending
and receiving RBridges on the link.
Edge-to-edge TRILL security would protect the contents of TRILL data
packets including the identities of the end stations for data from
transit RBridges but does not encrypt the identities of the edge
RBridges involved and does not protect against observation by
those edge RBridges. It is anticipated that edge-to-edge TRILL
security will be covered in future documents.
End-to-end security does not protect the identities of the end
stations or edge RBridge involved but does protect the content of
TRILL data packets from observation by all RBridges or other
intervening devices between the end stations involved. End-to-end
security should always be considered as an added layer of security
to protect any particularly sensitive information from unintended
disclosure. Such end station to end station security is generally
beyond the scope of TRILL
If VXLAN encapsulation is used, the unused Ethernet source and
destination MAC addresses mentioned in Section 5.5, provide a 96 bit
per packet side channel.
10.1 IPsec
This document specifies that all RBridges that support TRILL over IP
links MUST implement IPsec for the security of such links, 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
Margaret Cullen, et al [Page 31]

INTERNET-DRAFT TRILL over UDP
not secure. IPsec is important, in these cases, to protect the
privacy and integrity of data traffic. However, in cases where IPsec
is impractical due to lack of fast path support, use of TRILL edge-
to-edge security or use by the end stations of end-to-end security
can provide significant security.
Further Security Considerations for IPsec ESP and for the
cryptographic algorithms used with IPsec can be found in the RFCs
referenced by this document.
10.2 IS-IS Security
TRILL over IP is compatible with the use of IS-IS Security [RFC5310],
which can be used to authenticate TRILL switches before allowing them
to join a TRILL campus. This is sufficient to protect against rogue
devices impersonating TRILL switches, but is not sufficient to
protect data packets that may be sent in TRILL over IP outside of the
local network or 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.
Margaret Cullen, et al [Page 32]

INTERNET-DRAFT TRILL over UDP11. IANA Considerations
IANA considerations are given below.
11.1 Port Assignments
IANA is requested to assign destination Ports in the Service Name and
Transport Protocol Port Number Registry [PortRegistry] for TRILL IS-
IS and TRILL Data as shown below.
Service Name: TRILL-IS-IS
Transport Protocol: udp, tcp
Assignee: iesg@ietf.org
Contact: chair@ietf.org
Description: Transport of TRILL IS-IS control PDUs.
Reference: [this document]
Port Number: (TBD1)
Service Name: TRILL-data
Transport Protocol: udp, tcp
Assignee: iesg@ietf.org
Contact: chair@ietf.org
Description: Transport of TRILL Data packets.
Reference: [this document]
Port Number: (TBD2)
11.2 Multicast Address Assignments
IANA is requested to assign one IPv4 and one IPv6 multicast address,
as shown below, which correspond to both the All-RBridges and All-IS-
IS-RBridges multicast MAC addresses that have been 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 sufficient.
(Values recommended to IANA in square brackets)
Name IPv4 IPv6
------------ ------------------ --------------------------
All-RBridges TBD3[233.252.1.32] TBD4[FF0X:0:0:0:0:0:0:BAC1]
The hex digit "X" in the IPv6 variable scope address indicates the
scope and defaults to 8. The IPv6 All-RBridges IP address may be used
with other values of X.
Margaret Cullen, et al [Page 33]

INTERNET-DRAFT TRILL over UDP
Acknowledgements
The following people have provided useful feedback on the contents of
this document: Sam Hartman, Adrian Farrel, Radia Perlman, Ines
Robles, Joe Touch, Mohammed Umair, Lucy Yong.
Some of the material in this document is derived from [RFC8085] and
[RFC8086].
The document was prepared in raw nroff. All macros used were defined
within the source file.
Margaret Cullen, et al [Page 39]

INTERNET-DRAFT TRILL over UDP
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2017 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
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.
Margaret Cullen, et al [Page 41]