idnits 2.17.1 draft-mrw-trill-over-ip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2014) is 3709 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC768' is mentioned on line 347, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' == Outdated reference: A later version (-04) exists of draft-ietf-trill-rfc6327bis-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wasserman 3 Internet-Draft Painless Security 4 Intended status: Standards Track D. Eastlake 5 Expires: August 2, 2014 D. Zhang 6 Huawei Technologies 7 January 31, 2014 9 Transparent Interconnection of Lots of Links (TRILL) over IP 10 draft-mrw-trill-over-ip-04.txt 12 Abstract 14 The Transparent Interconnection of Lots of Links (TRILL) protocol is 15 implemented by devices called TRILL Switches or RBridges (Routing 16 Bridges). TRILL supports both point-to-point and multi-access links 17 and is designed so that a variety of link protocols can be used 18 between TRILL switch ports. This document standardizes methods for 19 encapsulating TRILL in IP(v4 or v6) to provide a unified TRILL 20 campus. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 2, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Use Cases for TRILL over IP . . . . . . . . . . . . . . . . . 3 59 3.1. Remote Office Scenario . . . . . . . . . . . . . . . . . 3 60 3.2. IP Backbone Scenario . . . . . . . . . . . . . . . . . . 4 61 3.3. Important Properties of the Scenarios . . . . . . . . . . 4 62 3.3.1. Security Requirements . . . . . . . . . . . . . . . . 4 63 3.3.2. Multicast Handling . . . . . . . . . . . . . . . . . 5 64 3.3.3. RBridge Neighbor Discovery . . . . . . . . . . . . . 5 65 4. TRILL Packet Formats . . . . . . . . . . . . . . . . . . . . 5 66 4.1. TRILL Data Packet . . . . . . . . . . . . . . . . . . . . 5 67 4.2. TRILL IS-IS Packet . . . . . . . . . . . . . . . . . . . 6 68 5. Link Protocol Specifics . . . . . . . . . . . . . . . . . . . 6 69 6. Port Configuration . . . . . . . . . . . . . . . . . . . . . 7 70 7. TRILL over UDP/IP Format . . . . . . . . . . . . . . . . . . 7 71 8. Handling Multicast . . . . . . . . . . . . . . . . . . . . . 8 72 9. Use of DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10. Transport Considerations . . . . . . . . . . . . . . . . . . 9 74 10.1. Recursive Ingress . . . . . . . . . . . . . . . . . . . 9 75 10.2. Fat Flows . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.3. Congestion Considerations . . . . . . . . . . . . . . . 10 77 11. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 12. Middlebox Considerations . . . . . . . . . . . . . . . . . . 11 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 16.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 16.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Requirements Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Introduction 95 TRILL switches (RBridges) are devices that implement the IETF TRILL 96 protocol [RFC6325] [I-D.eastlake-isis-rfc6326bis] 97 [I-D.ietf-trill-rfc6327bis]. 99 RBridges provide transparent forwarding of frames within an arbitrary 100 network topology, using least cost paths for unicast traffic. They 101 support not only VLANs and Fine Grained Labels 102 [I-D.ietf-trill-fine-labeling] but also multipathing of unicast and 103 multi-destination traffic. They use IS-IS link state routing and 104 encapsulation with a hop count. They are compatible with IEEE 802.1 105 customer bridges, and can incrementally replace them. 107 Ports on different RBridges can communicate with each other over 108 various link types, such as Ethernet [RFC6325] or PPP [RFC6361]. 110 This document defines a method for RBridges to communicate over UDP/ 111 IP(v4 or v6). TRILL over IP will allow remote, Internet-connected 112 RBridges to form a single RBridge campus, or multiple TRILL over IP 113 networks within a campus to be connected as a single TRILL campus via 114 a TRILL over IP backbone. 116 TRILL over IP connects RBridge ports using IPv4 or IPv6 as a 117 transport in such a way that the ports appear to TRILL to be 118 connected by a single multi-access link. Therefore, if more than two 119 RBridge ports are connected via a single TRILL over IP link, any pair 120 of them can communicate. 122 To support the scenarios where RBridges are connected via links (such 123 as the public Internet) that are not under the same administrative 124 control as the TRILL campus, this document specifies the use of 125 Datagram Transport Layer Security (DTLS) [RFC6347] to secure the 126 communications between RBridges running TRILL over IP. 128 3. Use Cases for TRILL over IP 130 This section introduces two application scenarios (a remote office 131 scenario and an IP backbone scenario) which cover the most typical of 132 situations where network administrators may choose to use TRILL over 133 an IP network. 135 3.1. Remote Office Scenario 137 In the Remote Office Scenario, a remote TRILL network is connected to 138 a TRILL campus across a multihop IP network, such as the public 139 Internet. The TRILL network in the remote office becomes a logical 140 part of TRILL campus, and nodes in the remote office can be attached 141 to the same VLANs or Fine Grained 142 Labels[I-D.ietf-trill-fine-labeling] as local campus nodes. In many 143 cases, a remote office may be attached to the TRILL campus by a 144 single pair of RBridges, one on the campus end, and the other in the 145 remote office. In this use case, the TRILL over IP link will often 146 cross logical and physical IP networks that do not support TRILL, and 147 are not under the same administrative control as the TRILL campus. 149 3.2. IP Backbone Scenario 151 In the IP Backbone Scenario, TRILL over IP is used to connect a 152 number of TRILL networks to form a single TRILL campus. For example, 153 a TRILL over IP backbone could be used to connect multiple TRILL 154 networks on different floors of a large building, or to connect TRILL 155 networks in separate buildings of a multi-building site. In this use 156 case, there may often be several TRILL switches on a single TRILL 157 over IP link, and the IP link(s) used by TRILL over IP are typically 158 under the same administrative control as the rest of the TRILL 159 campus. 161 3.3. Important Properties of the Scenarios 163 There are a number of differences between the above two application 164 scenarios, some of which drive features of this specification. These 165 differences are especially pertinent to the security requirements of 166 the solution, how multicast data frames are handled, and how the 167 TRILL switch ports discover each other. 169 3.3.1. Security Requirements 171 In the IP Backbone Scenario, TRILL over IP is used between a number 172 of RBridge ports, on a network link that is in the same 173 administrative control as the remainder of the TRILL campus. While 174 it is desirable in this scenario to prevent the association of rogue 175 RBridges, this can be accomplished using existing IS-IS security 176 mechanisms. There may be no need to protect the data traffic, beyond 177 any protections that are already in place on the local network. 179 In the Remote Office Scenario, TRILL over IP may run over a network 180 that is not under the same administrative control as the TRILL 181 network. Nodes on the network may think that they are sending 182 traffic locally, while that traffic is actually being sent, in a UDP/ 183 IP tunnel, over the public Internet. It is necessary in this 184 scenario to protect the integrity and confidentiality of user 185 traffic, as well as ensuring that no unauthorized RBridges can gain 186 access to the RBridge campus. The issues of protecting integrity and 187 confidentiality of user traffic are addressed by using DTLS for both 188 IS-IS frames and data frames between RBridges in this scenario. 190 3.3.2. Multicast Handling 192 In the IP Backbone scenario, native multicast may be supported on the 193 TRILL over IP link. If so, it can be used to send TRILL IS-IS and 194 multicast data packets, as discussed later in this document. 195 Alternatively, multi-destination packets can be transmitted serially. 197 In the Remote Office Scenario there will often be only one pair of 198 RBridges connecting a given site and, even when multiple RBridges are 199 used to connect a Remote Office to the TRILL campus, the intervening 200 network may not provide reliable (or any) multicast connectivity. 201 The issues such as complex key management also makes it difficult to 202 provide strong data integrity and confidentiality protections for 203 multicast traffic. For all of these reasons, the connections between 204 local and remote RBridges will be treated like point-to-point links, 205 and all TRILL IS-IS control messages and multicast data packets that 206 are transmitted between the Remote Office and the TRILL campus will 207 be serially transmitted, as discussed later in this document. 209 3.3.3. RBridge Neighbor Discovery 211 In the IP Backbone Scenario, RBridges that use TRILL over IP will use 212 the normal TRILL IS-IS Hello mechanisms to discover the existence of 213 other RBridges on the link [I-D.ietf-trill-rfc6327bis], and to 214 establish authenticated communication with those RBridges. 216 In the Remote Office Scenario, a DTLS session will need to be 217 established between RBridges before TRILL IS-IS traffic can be 218 exchanged, as discussed below. In this case, one of the RBridges 219 will need to be configured to establish a DTLS session with the other 220 RBridge. This will typically be accomplished by configuring the 221 RBridge at a Remote Office to initiate a DTLS session, and subsequent 222 TRILL exchanges, with a TRILL over IP-enabled RBridge attached to the 223 TRILL campus. 225 4. TRILL Packet Formats 227 To support the TRILL base protocol standard [RFC6325]. , two types of 228 packets will be transmitted between RBridges: TRILL Data frames and 229 TRILL IS-IS packets. 231 4.1. TRILL Data Packet 233 The on-the-wire form of a TRILL Data packet in transit between two 234 neighboring RBridges is as shown below: 236 +--------------+----------+----------------+-----------+ 237 | TRILL Data | TRILL | Native Frame | Link | 238 | Link Header | Header | Payload | Trailer | 239 +--------------+----------+----------------+-----------+ 241 Where the Encapsulated Native Frame is similar to Ethernet frame 242 format with a VLAN tag or Fine Grained Label 243 [I-D.ietf-trill-fine-labeling] but with no trailing Frame Check 244 Sequence (FCS). 246 4.2. TRILL IS-IS Packet 248 TRILL IS-IS packets are formatted on-the-wire as follows: 250 +--------------+---------------+-----------+ 251 | TRILL IS-IS | TRILL IS-IS | Link | 252 | Link Header | Payload | Trailer | 253 +--------------+---------------+-----------+ 255 The Link Header and Link Trailer in these formats depend on the 256 specific link technology. The Link Header usually contains one or 257 more fields that distinguish TRILL Data from TRILL IS-IS. For 258 example, over Ethernet, the TRILL Data Link Header ends with the 259 TRILL Ethertype while the TRILL IS-IS Link Header ends with the L2 260 -IS-IS Ethertype; on the other hand, over PPP, there are no 261 Ethertypes but PPP protocol code points are included that distinguish 262 TRILL Data from TRILL IS-IS. 264 In TRILL over IP, we will use UDP/IP (v4 or v6) as the link header, 265 and the TRILL packet type will be determined based on the UDP 266 destination port number. In TRILL over IP, no Link Trailer is 267 specified, although one may be added when the resulting IP packets 268 are encapsulated for transmission on a network (e.g. Ethernet). 270 5. Link Protocol Specifics 272 TRILL Data packets can be unicast to a specific RBridge or multicast 273 to all RBridges on the link. TRILL IS-IS packets are always 274 multicast to all other RBridge on the link (except for MTU PDUs, 275 which may be unicast). On Ethernet links, the Ethernet multicast 276 address All-RBridges is used for TRILL Data and All-IS-IS-RBridges 277 for TRILL IS-IS. 279 To properly handle TRILL base protocol packets on a TRILL over IP 280 link, either native multicast mode must be enabled on that link, or 281 multicast must be simulated using serial unicast, as discussed below. 283 In TRILL Hello PDUs used on TRILL IP links, the IP addresses of the 284 connected IP ports are their real SNPA (SubNetwork Point of 285 Attachment) addresses and, for IPv6, the 16-byte IPv6 address is 286 used; however, for easy of code re-use designed for common 48-bit 287 SNPAs, for TRILL over IPv4, a 48-bit synthetic SNPA that looks like a 288 unicast MAC address is constructed for use in the SNPA field of TRILL 289 Neighbor TLVs 290 [I-D.eastlake-isis-rfc6326bis][I-D.ietf-trill-rfc6327bis] on the 291 link. This synthetic SNPA is as follows: 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | 0xFE | 0x00 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | IPv4 upper half | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IPv4 lower half | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 This synthetic SNPA/MAC address has the local (0x02) bit on in the 303 first byte and so cannot conflict with any globally unique 48-bit 304 Ethernet MAC. However, at the IP level, where TRILL operates on an 305 IP link, there are only IP stations, not MAC stations, so conflict on 306 the link with a real MAC address would be impossible in any case. 308 6. Port Configuration 310 Each RBridge physical port used for a TRILL over IP link MUST have at 311 least one IP (v4 or v6) address. Implementations MAY allow a single 312 physical port to operate as multiple IPv4 and/or IPv6 logical ports. 313 Each IP address constitutes a different logical port and the RBridge 314 with those ports MUST associate a different Port ID with each logical 315 port. 317 TBD: MUST be able to configure a list of IP addresses for serial 318 unicast. MUST be able to configure a non-standard IP multi-cast 319 address if native multicast is being used. 321 7. TRILL over UDP/IP Format 323 The general format of a TRILL over UDP/IP packet is shown below. 325 +----------+--------+-----------------------+ 326 | IP | UDP | TRILL | 327 | Header | Header | Payload | 328 +----------+--------+-----------------------+ 330 Where the UDP Header is as follows: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Source Port = Entropy | Destination Port | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | UDP Length | UDP Checksum | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | TRILL Payload ... 341 Source Port - see Section 10.2 343 Destination Port - indicates TRILL Data or IS-IS, see Section 14 345 UDP Length - as specified in [RFC768] 347 UDP Checksum - as specified in [RFC768] 349 The TRILL Payload starts with the TRILL Header (not including the 350 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 351 Intradomain Routeing Protocol Discriminator byte (thus not including 352 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 354 8. Handling Multicast 356 By default, both TRILL IS-IS packets and multi-destination TRILL Data 357 packets are sent to an All-RBridges IPv4 or IPv6 multicast Address as 358 appropriate (see Section 14); however, a TRILL over IP port may be 359 configured to use serial unicast with a list of unicast addresses of 360 other stations to which multi-destination packets are sent. 362 TBD 364 9. Use of DTLS 366 All RBridges that support TRILL over IP MUST implement DTLS and 367 support the use of DTLS to secure both TRILL IS-IS and TRILL data 368 packets. When DTLS is used to secure a TRILL over IP link, the DTLS 369 session MUST be fully established before any TRILL IS-IS or data 370 frames are exchanged. 372 RBridges that implement TRILL over IP SHOULD support the use of 373 certificates for DTLS and, if they support certificates, MUST support 374 the following algorithm: 376 o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] 378 RBridges that support TRILL over IP MUST support the use of pre- 379 shared keys for DTLS. If the communicating RBridges have IS-IS Hello 380 authentication enabled with a pre-shared key, then, by default a key 381 derived from that TRILL Hello pre-shared key is used for DTLS unless 382 some other pre-shared key is configured. The following cryptographic 383 algorithms MUST be supported for use with pre-shared keys: 385 o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246] 387 If the derived default preshared key is used, it is derived as 388 follows: 390 HMAC-SHA256 ("TRILL IP", IS-IS-shared key ) 392 In the above "|" indicates concatenation, HMAC-SHA256 is as described 393 in [FIPS180] [RFC6234] and "TRILL IP" is the eight byte US ASCII 394 [ASCII] string indicated. 396 10. Transport Considerations 398 10.1. Recursive Ingress 400 TRILL is designed to transport end station traffic to and from IEEE 401 802.1Q conformant end stations and IP is frequently transported over 402 IEEE 802.3 or similar protocols supporting 802.1Q conformant end 403 stations. Thus, an end station data frame EF might get TRILL 404 ingressed to TRILL(EF) which was then sent on a TRILL over IP over an 405 802.3 link resulting in an 802.3 frame of the form 406 802.3(IP(TRILL(EF))). There is a risk of such a packet being re- 407 ingressed by the same TRILL campus, due to physical or logical 408 misconfiguration, looping round, being further re-ingressed, etc. 409 The packet might get discarded if it got too large but if 410 fragmentation is enabled, it would just keep getting split into 411 fragments that would continue to loop and grow and re-fragment until 412 the path was saturated with junk and packets were being discarded due 413 to queue overflow. The TRILL Header TTL would provide no protection 414 because each TRILL ingress adds a new Header and TTL. 416 To protect against this scenario, TRILL over IP output ports MUST be 417 able to test whether a TRILL packet they are above to send is, in 418 fact a TRILL ingress of a TRILL over IP over 802.3 or the like 419 packets. That is, is it of the form TRILL(802.3(IP(TRILL(...)))? If 420 so, the default action of the TRILL over IP output port is to discard 421 the packet. However, there are cases where some level of nested 422 ingress is desired so it MUST be possible to configure the port to 423 allow such packets. 425 10.2. Fat Flows 427 For the purpose of load balancing, it could be worthwhile to consider 428 how to transport the TRILL packets over the Equal Cost Multiple Paths 429 (ECMPs) existing in the IP path. 431 The ECMP election for the IP traffics could be based, at least for 432 IPv4, on the quintuple of the outer IP header { Source IP, 433 Destination IP, Source Port, Destination Port, and IP protocol }. 434 Such tuples, however, can be exactly the same for all TRILL Data 435 packets between two RBridge ports, even if there is a huge amount of 436 data being sent. Therefore, in order to support ECMP, a RBridge 437 SHOULD set the Source Port as an entropy field for ECMP decisions. 438 This idea is also introduced in [I-D.yong-tsvwg-gre-in-udp-encap]. 440 10.3. Congestion Considerations 442 TRILL can carry many different protocols as a payload. When a TRILL 443 over IP flow carries primarily IP-based traffic, the aggregate 444 traffic is assumed to be TCP friendly due to the congestion control 445 mechanisms used by the payload traffic. Packet loss will trigger the 446 necessary reduction in offered load, and no additional congestion 447 avoidance action is necessary. When a TRILL over IP flow carries 448 payload traffic that is not known to be TCP friendly and the flow 449 runs across a path that could potentially become congested, 450 additional mechanisms MUST be employed to ensure that the offered 451 load on the TRILL link over IP is reduced appropriately during 452 periods of congestion. This is not necessary in the case of a TRILL 453 link over IP through an over- provisioned network, where the 454 potential for congestion is avoided through the over-provisioning of 455 the network. 457 11. MTU Considerations 459 In TRILL each RBridge advertises the largest LSP frame it can accept 460 (but not less than 1,470 bytes) on any of its interfaces (at least 461 those interfaces with adjacencies to other RBridges in the campus) in 462 its LSP number zero through the originatingLSPBufferSize TLV 463 [RFC6325] [I-D.eastlake-isis-rfc6326bis]. The campus minimum MTU, 464 denoted Sz, is then established by taking the minimum of this 465 advertised MTU for all RBridges in the campus. Links that do not 466 meet the Sz MTU are not included in the routing topology. This 467 protects the operation of IS-IS from links that would be unable to 468 accommodate some LSPs. 470 A method of determining originatingLSPBufferSize for an RBridge with 471 one or more TRILL over IP portsis described in 472 [I-D.ietf-trill-clear-correct]. However, if an IP link either can 473 accommodate jumbo frames or is a link on which IP fragmentation is 474 enabled and acceptable, then it is unlikely that the IP link will be 475 a constraint on the RBridge's originatingLSPBufferSize. On the other 476 hand, if the IP link can only handle smaller frames and fragmentation 477 is to be avoided when possible, a TRILL over IP port might constrain 478 the RBridge's originatingLSPBufferSize. Because TRILL sets the 479 minimum values of Sz at 1,470 bytes, there may be links that meet the 480 minimum MTU for the IP protocol (1,280 bytes for IPv6, theoretically 481 68 bytes for IPv4) on which it would be necessary to enable 482 fragmentation for TRILL use. 484 The optional use of TRILL IS-IS MTU PDUs, as specified in [RFC6325] 485 and [I-D.ietf-trill-rfc6327bis] can provide added assurance of the 486 actual MTU of a link. 488 12. Middlebox Considerations 490 TBD 492 13. Security Considerations 494 TRILL over IP is subject to all of the security considerations for 495 the base TRILL protocol [RFC6325]. In addition, there are specific 496 security requirements for different TRILL deployment scenarios, as 497 discussed in the "Use Cases for TRILL over IP" section above. 499 This document specifies that all RBridges that support TRILL over IP 500 MUST implement DTLS, and makes it clear that it is both wise and good 501 to use DTLS in all cases where a TRILL over IP link will traverse a 502 network that is not under the same administrative control as the rest 503 of the TRILL campus. DTLS is necessary, in these cases to protect 504 the privacy and integrity of data traffic. 506 TRILL over IP is completely compatible with the use of IS-IS 507 security, which can be used to authenticate RBridges before allowing 508 them to join a TRILL campus. This is sufficient to protect against 509 rogue RBridges, but is not sufficient to protect data packets that 510 may be sent, in UDP/IP tunnels, outside of the local network, or even 511 across the public Internet. To protect the privacy and integrity of 512 that traffic, use DTLS. 514 In cases were DTLS is used, the use of IS-IS security may not be 515 necessary, but there is nothing about this specification that would 516 prevent using both DTLS and IS-IS security together. In cases where 517 both types of security are enabled, by default, a key derived from 518 the IS-IS key will be used for DTLS. 520 14. IANA Considerations 522 IANA has allocated the following destination UDP Ports for the TRILL 523 IS-IS and Data channels: 525 UDP Port Protocol 527 (TBD) TRILL IS-IS Channel 528 (TBD) TRILL Data Channel 530 IANA has allocated one IPv4 and one IPv6 multicast address, as shown 531 below, which correspond to the All-RBridges and All-IS-IS-RBridges 532 multicast MAC addresses that the IEEE Registration Authority has 533 assigned for TRILL. Because the low level hardware MAC address 534 dispatch considerations for TRILL over Ethernet do not apply to TRILL 535 over IP, one IP multicast address for each version of IP is 536 sufficient. 538 [Values recommended to IANA:] 540 Name IPv4 IPv6 542 All-RBridges 233.252.14.0 FF0X:0:0:0:0:0:0:205 544 Note: when these IPv4 and IPv6 multicast addresses are used and the 545 resulting IP frame is sent over Ethernet, the usual IP derived MAC 546 address is used. 548 [Need to discuss scopes for IPv6 multicast (the "X" in the addresses) 549 somewhere. Default to "site" scope but MUST be configurable?] 551 15. Acknowledgements 553 This document was written using the xml2rfc tool described in RFC 554 2629 [RFC2629]. 556 The following people have provided useful feedback on the contents of 557 this document: Sam Hartman, Adrian Farrel. 559 Some material has been derived from draft-ietf-mpls-in-udp by Xiaohu 560 Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, and Yongbing Fan. 562 16. References 564 16.1. Normative References 566 [ASCII] "American National Standards Institute (formerly United 567 States of America Standards Institute), "USA Code for 568 Information Interchange", ANSI X3.4-1968, ANSI X3.4-1968 569 has been replaced by newer versions with slight 570 modifications, but the 1968 version remains definitive for 571 the Internet.", 1968. 573 [FIPS180] ""Secure Hash Standard (SHS)", United States of American, 574 National Institute of Science and Technology, Federal 575 Information Processing Standard (FIPS) 180-4", March 2012. 577 [I-D.eastlake-isis-rfc6326bis] 578 Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 579 and A. Banerjee, "Transparent Interconnection of Lots of 580 Links (TRILL) Use of IS-IS", draft-eastlake-isis- 581 rfc6326bis-09 (work in progress), August 2012. 583 [I-D.ietf-trill-clear-correct] 584 Eastlake, D., Zhang, M., Ghanwani, A., Manral, V., and A. 585 Banerjee, "TRILL: Clarifications, Corrections, and 586 Updates", draft-ietf-trill-clear-correct-06 (work in 587 progress), July 2012. 589 [I-D.ietf-trill-rfc6327bis] 590 Eastlake, D., Perlman, R., Ghanwani, A., Yang, H., and V. 591 Manral, "TRILL: Adjacency", draft-ietf-trill-rfc6327bis-03 592 (work in progress), January 2014. 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 598 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 600 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 601 Ghanwani, "Routing Bridges (RBridges): Base Protocol 602 Specification", RFC 6325, July 2011. 604 16.2. Informative References 606 [I-D.ietf-trill-fine-labeling] 607 Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D. 608 Dutt, "TRILL (Transparent Interconnection of Lots of 609 Links): Fine-Grained Labeling", draft-ietf-trill-fine- 610 labeling-07 (work in progress), May 2013. 612 [I-D.yong-tsvwg-gre-in-udp-encap] 613 Crabbe, E., Yong, L., and K. Building, "Generic UDP 614 Encapsulation for IP Tunneling", draft-yong-tsvwg-gre-in- 615 udp-encap-02 (work in progress), October 2013. 617 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 618 June 1999. 620 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 621 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 623 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 624 Security Version 1.2", RFC 6347, January 2012. 626 [RFC6361] Carlson, J. and D. Eastlake, "PPP Transparent 627 Interconnection of Lots of Links (TRILL) Protocol Control 628 Protocol", RFC 6361, August 2011. 630 Authors' Addresses 632 Margaret Wasserman 633 Painless Security 634 356 Abbott Street 635 North Andover, MA 01845 636 USA 638 Phone: +1 781 405-7464 639 Email: mrw@painless-security.com 640 URI: http://www.painless-security.com 642 Donald Eastlake 643 Huawei Technologies 644 155 Beaver Street 645 Milford, MA 01757 646 USA 648 Phone: +1 508 333-2270 649 Email: d3e3e3@gmail.com 650 Dacheng Zhang 651 Huawei Technologies 652 Q14, Huawei Campus 653 No.156 Beiqing Rd. 654 Beijing, Hai-Dian District 100095 655 P.R. China 657 Email: zhangdacheng@huawei.com