idnits 2.17.1 draft-eastlake-trill-link-security-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7173, but the abstract doesn't seem to directly say this. It does mention RFC7173 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 24, 2017) is 2399 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) == Unused Reference: 'RFC8126' is defined on line 464, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Updates: 6325, 6361, 7173 Dacheng Zhang 3 Intended status: Proposed Standard Huawei 4 Expires: March 23, 2018 September 24, 2017 6 TRILL: Link Security 7 9 Abstract 11 The TRILL protocol supports arbitrary link technologies between TRILL 12 switches, both point-to-point and broadcast links, and supports 13 Ethernet links between edge TRILL switches and end stations. 14 Communications links are constantly under attack by criminals and 15 national intelligence agencies as discussed in RFC 7258. Link 16 security is an important element of security in depth, particularly 17 for links that are not entirely under the physical control of the 18 TRILL network operator or that include device which may have been 19 compromised. This document specifies link security recommendations 20 for TRILL over Ethernet, PPP, and pseudowire links. It updates RFC 21 6325, RFC 6361, and RFC 7173. It requires that link encryption MUST 22 be implemented and that all TRILL Data packets between TRILL switch 23 ports capable of encryption at line speed MUST default to being 24 encrypted. 26 [This is a early partial draft.] 28 Status of This Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Distribution of this document is unlimited. Comments should be sent 34 to the DNSEXT working group mailing list: . 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Table of Contents 53 1. Introduction............................................3 54 1.1 Encryption Requirement and Adjacency...................3 55 1.2 Terminology and Acronyms...............................4 57 2. Link Security Default Keying............................5 59 3. Link Security Specifics.................................6 60 3.1 Ethernet Links.........................................6 61 3.2 PPP Links..............................................8 62 3.3 Pseudowire Links.......................................8 64 4. Edge-to-Edge Security...................................9 66 5. Security Considerations................................11 67 6. IANA Considerations....................................11 69 Normative References......................................12 70 Informative References....................................13 71 Acknowledgments...........................................14 73 Appendix A: Summary of Changes to RFCs 6325, 6361, 7173...15 74 Appendix B: Ethernet Secrity to End Stations..............16 76 Authors' Addresses........................................19 78 1. Introduction 80 The TRILL (Transparent Interconnection of Lots of Links or Tunneled 81 Routing in the Link Layer) protocol [RFC6325] [RFC7780] supports 82 arbitrary link technologies including both point-to-point and 83 broadcast links and supports Ethernet links between edge TRILL 84 switches and end stations. Communications links are constantly under 85 attack by criminals and national intelligence agencies as discussed 86 in [RFC7258]. 88 Link security in an important element of security in depth for links, 89 paticularly those that are not entirely under the physical control of 90 the TRILL network operator or that include device which may have been 91 compromised, that is, pretty much for all links. TRILL generally uses 92 an existing link security method specified for the technology of the 93 link in question. 95 This document specifies link security recommendations for TRILL over 96 Ethernet [RFC6325], TRILL over PPP [RFC6361], and transport of TRILL 97 by pseudowires [RFC7173], in Sections 3.1, 3.2, and 3.3 respectively. 98 Although the Security Considerations sections of these RFCs mention 99 link security, this document goes further, updating these RFCs as 100 decribed in Appendix A and imposing the new mandatory encryption 101 implementation requirements summarized in Section 1.1. 103 [TRILL-IP] will cover TRILL security over IP links and any other 104 future TRILL-over-X drafts are expected to cover security for TRILL 105 links using technology X. 107 Edge-to-edge security, fron imgress to egress TRILL switch, provides 108 another level of security and is covered in Section 4. 110 TRILL provides autoconfiguration assistance and default keying 111 material, under most circumstances, to support the TRILL goal of 112 having a minimal or zero configuration default. Where better security 113 is not available, TRILL supports opportunistic security [RFC7435]. 115 [This is a partial early draft.] 117 1.1 Encryption Requirement and Adjacency 119 This document requires that all TRILL data packets between adjacent 120 TRILL switch ports that are capable of encryption at line speed MUST 121 default to being encrypted and authenticated or, if authenticaion is 122 not available, at least to be oportunisticly encrypted (encrypted 123 without authentication of endpoints). It MUST require explicit 124 configuration in such cases to allow the ports to communicate 125 unencrypted or unsecured. Line speed encryption and authentication 126 usually requires hardware assist but there are cases with slower 127 ports and higher powered switch processors where it can be 128 accomplished in sofware. 130 If line speed link encryption and authentication is not available for 131 communication between TRILL switch ports, it MUST still be possible 132 to configure the TRILL switches and ports involved to encrypt and 133 authenticate all TRILL packets sent. This is appropriate for cases 134 where the security provided outweighs the reduction in performance. 136 1.2 Terminology and Acronyms 138 This document uses the acronyms and terms defined in [RFC6325], some 139 of which are repeated below for convenience, and additional acronyms 140 and terms listed below. 142 HKDF: Hash based Key Derivation Function [RFC5869]. 144 Link: The means by which adjacent TRILL switches are connected. May 145 be various technologies and in the common case of Ethernet, can 146 be a "bridged LAN", that is to say, some combination of 147 Ethernet links with zero or more bridges, hubs, or repeaters. 149 MACSEC: Media Access Control (MAC) Security. IEEE Std 802.1AE-2006. 151 MPLS: Multi-Protocol Label Switching. 153 PPP: Point-to-point protocol [RFC1661]. 155 RBridge: An alternative name for a TRILL switch. 157 TRILL: Transparent Interconnection of Lots of Links or Tunneled 158 Routing in the Link Layer. 160 TRILL switch: A device implementing the TRILL protocol. An 161 alternative name for an RBridge. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2. Link Security Default Keying 169 In some cases, it is possible to use keying material derived from the 170 [RFC5310] IS-IS keying material already in place. In such cases, the 171 two byte [RFC5310] Key ID identifies the IS-IS keying material. The 172 keying material actually used in the link security protocol is 173 derived from the IS-IS keying material as follows: 175 HKDF-Expand-SHA256 ( IS-IS-keying-material, 176 "TRILL Link" | custom, L ) 178 where "|" indicates concatenation, HKDF is the Hash base Key 179 Derivation Function in [RFC5869], SHA256 is as in [RFC6234], IS-IS- 180 keying-material is the input keying material, "TRILL Link" is the 181 10-character ASCII [RFC20] string indicated, "custom" is a byte 182 string dependeng on the link security protocol being used, and L is 183 the length of output keying material needed. 185 3. Link Security Specifics 187 The following subsection discuss TRILL link security for various 188 technologies. 190 3.1 Ethernet Links 192 TRILL over Ethernet is specified in [RFC6325] with some additional 193 material on Ethernet link MTU in [RFC7780]. 195 Link security between TRILL switch Ethernet ports conforms to IEEE 196 Std 802.1AE-2006 [802.1AE] as amended by IEEE Std 802.1AEbn-2011 197 [802.1AEbn] and IEEE Std 802.1AEbw-2013 [802.1AEbw]. This security is 198 referred to as MACSEC. 200 TRILL switch Ethernet ports MUST implement MACSEC even if it is 201 implemented in software. When TRILL switch ports are directly 202 connected by Ethernet with no intervening customer bridges, for 203 example by a point to point Ethernet link, MACSEC between them 204 operates as specified herein. There can be intervening Provider 205 Bridges or other forms of transparent Ethernet tunnels. 207 However, if there are one or more customer bridges or similar devices 208 in the path, MACSEC at the TRILL switch port will peer with the 209 nearest such bridge port. This reaults, from the point of view of 210 MACSEC, with a two or more hop path, although it is one TRILL hop. 211 Typically, the TRILL switch ports at the ends of such a path would be 212 unable to negotiate security and agree on keys because of the 213 intervening customer bridge. In such cases where encryption and 214 authenication are required, the adjacent TRILL switch ports would be 215 unable to establish IS-IS communication and would not form an 216 adjacency [RFC7177]. However, it may be possible to configure such 217 bridge ports and distribute such keying material or the like to them 218 so that encryption and authentication can be established on all hops 219 of such mulit-hop Ethernet paths. Methods for accomplishing such 220 distribution to devices other than TRILL switches are beyond the 221 scope of this document. 223 When MACSEC is established between adjacent TRILL switch ports, the 224 frames are as shown in Figure 1. The optional VLAN tagging shown is 225 superfluous in the case of TRILL Data and IS-IS packets. Unless there 226 are VLAN sensitive devices intervening between the TRILL switch 227 ports, or possibly attached to the link between those ports, TRILL 228 Data and IS-IS packets secured with MACSEC SHOULD generally be sent 229 untagged for efficiency. 231 Of course there may be other Ethernet control frames, such as link 232 aggregation control messages or priority based flow control messages, 233 that would also be sent within MACSEC. Typically only the [802.1X] 234 messages used to establish and maintain MACSEC are sent unsecured. 236 +---------------------------------------+ 237 | Outer.MacDA (6 bytes) | 238 +---------------------------------------+ 239 | Outer.MacSA (6 bytes) | 240 +---------------------------------------+ 241 | MACSEC Tag (8 or 16 bytes) | 242 +---------------------------------------+ 243 | Encrypted | 244 | +-------------------------------+ | 245 | | Optional VLAN Tag (4 bytes) | | 246 | +-------------------------------+ | 247 | | TRILL or L2-IS-IS Ethertype | | 248 | +-------------------------------+ | 249 | | TRILL Data or IS-IS Payload | | 250 | +-------------------------------+ | 251 +---------------------------------------+ 252 | ICV (8 or 16 bytes | 253 +---------------------------------------+ 254 | FCS (4 bytes) | 255 +---------------------------------------+ 257 Figures 1. MACSEC Between TRILL Switch Ports 259 Outer.MacDA: 48-bit destination MAC address 261 Outer.MacSA: 48-bit source MAC address 263 MACSEC Tag: See further description below. 265 Encrypted: The encrypted data 267 ICV: The MACSEC Intergrity Check Value 269 FCS: Frame Check Sequence. 271 The strucutre of a MACSEC Tag is as follows: 273 to be completed ... 275 [802.1X] is used to establish keying and algorithms for Ethernet link 276 security ... to be completed ... 278 3.2 PPP Links 280 TRILL over PPP is specified in [RFC6361]. Currently specified native 281 PPP security does not meet modern security standards. However, true 282 PPP over HDLC is relatively uncommon today and PPP is normally being 283 conveyed by another protocol, such as PPP over Ethernet or PPP over 284 IP. In those cases it is RECOMMENDED that Ethernet security as 285 described in Section 3 or IP security as described in [TRILL-IP] be 286 used to secure PPP between TRILL switch ports. 288 If it is necessary to use native PPP security [RFC1968] [RFC1994] ... 289 to be completed ... 291 3.3 Pseudowire Links 293 TRILL transport over pseudowires is specified in [RFC7173]. 295 No native security is provided for pseudowires as such; however, they 296 are, by definition, carried by some PSN (Packet Switched Network). 297 Link security must be provided by this PSN or by lower level 298 protocols. This PSN is typically an MPLS or IP PSN. 300 In the case of a pseudowire over IP, security SHOULD be provided as 301 is expected to be specified in [TRILL-IP]. If that is not possible 302 but the IP path is only one IP hop, then it may be possible to 303 provide link security at the layer of the link protocol supporting 304 that hop, such as Ethernet (Section 3) or PPP (Section 4). 306 In the case of a pseudowire over MPLS, MPLS also does not have a 307 native security scheme. Thus, security must be provided at the link 308 layer being used, for example Ethernet (Section 3) or IP [TRILL-IP]. 310 4. Edge-to-Edge Security 312 Edge-to-edge security can be applied to TRILL data packets between 313 the TRILL switch where they are ingressed or created to the TRILL 314 switch where they are egressed or consumed. The edge-to-edge path is 315 viewed as a one hop virtual link from before TRILL encapsulation to 316 after TRILL decapsulation. MACSEC is used on this pseudolink. 318 If default keying is used, it is as specified in Section 2 above with 319 the value of "custom" in Section 2 as specified below, depending on 320 whether the TRILL data packet is TRILL unicast or TRILL multi- 321 destination: 323 Unicast: custom = "Uni" | ingress System ID | egress System ID 325 Multi-destination: custom = "Multi" | Data Label 327 where "|" indicates concatenation, the quoted string "Uni" and 328 "Multi" represent those 3 and 5 character ASCII [RFC20] strings, 329 respectively, ingress System ID and egress System ID are the 6-byte 330 IS-IS System ID of the origin and destination TRILL switches, and 331 Data Label is the contents of the 4-byte (C-VLAN Ethertype plus VLAN 332 ID) or 8-bytes (FGL Ethertypes and value) data labeling area of the 333 TRILL packet with priority/DEI fields set to zero. 335 Where keying is to be negotiated between a pair of TRILL switches for 336 edge-to-edge unicast security, the IEEE 802.1X messages involved are 337 transmitted inside unicast RBridge Channel [RFC7178] messages using 338 RBridge Channel protocol number TBD1. Support for edge-to-edge 339 encryption is indicated by a TRILL switch advertising support for 340 this RBridge Channel protocol. In such 802.1X messages, the System 341 IDs of the TRILL switches are used as their "MAC Addresses". 802.1X 342 in turn uses the Extensible Authentication Protocol (EAP [RFC3748]). 344 to be completed ... 346 For edge-to-edge security, the MACSEC tag is inserted in the payload 347 frame and the Inner.DataLabel (VLAN or FGL) is duplicated so that a 348 TRILL Data packet on a transit link (which might not be an Ethernet 349 link) is structured as shown below. The unencrypted copy of the 350 Inner.DataLabel is needed for two reasons: (1) to avoid rejection by 351 any transit RBridges the packet passes through that are sensitive to 352 the Ethertype appearing immediately after the Inner.MacSA and would 353 otherwise discard the packet and (2) to assure proper distribution if 354 the packet is multi-destination. The inner encrypted Data Label is 355 securely communicated to the egress TRILL swtich. 357 +---------------------------------------+ 358 | Link Header | 359 +---------------------------------------+ 360 | TRILL Header | 361 +---------------------------------------+ 362 | Inner.MacDA | 363 +---------------------------------------+ 364 | Inner.MacSA | 365 +---------------------------------------+ 366 | Inner.DataLabel | 367 +---------------------------------------+ 368 | MACSEC Tag Edge-to-Edge | 369 +---------------------------------------+ 370 | Encrypted | 371 | +-------------------------------+ | 372 | | Inner.DataLabel | | 373 | +-------------------------------+ | 374 | | Payload Ethertype | | 375 | +-------------------------------+ | 376 | | Payload | | 377 | +-------------------------------+ | 378 +---------------------------------------+ 379 | ICV (8 or 16 bytes | 380 +---------------------------------------+ 381 | Link Trailer | 382 +---------------------------------------+ 384 5. Security Considerations 386 This document is about TRILL hop link security for Etherent, PPP, and 387 pseudowire TRILL links and edge-to-edge security for a TRILL campus. 388 See sections of this document on those particular topics. 390 For general TRILL Security Considrations, see [RFC6325]. 392 6. IANA Considerations 394 IANA is requested to allocate a new RBridge Channel protocol number 395 TBD1 for tunneled 802.1X messages supporting negotiated keys for 396 unicast edge-to-edge security. 398 Normative References 400 [802.1AE] - IEEE Std 802.1AE-2006, IEEE Standard for Local and 401 metropolitan networks / Media Access Control (MAC) Security, 18 402 August 2006. 404 [802.1AEbn] - IEEE Std 802.1AEbn-2011, IEEE Standard for Local and 405 metropolitan networks / Media Access Control (MAC) Security / 406 Galois Counter Mode - Advanced Encryption Standard - 256 (GCM- 407 AES-256) Cipher Suite, 14 October 2011. 409 [802.1AEbw] - IEEE Std 802.1AEbw-2014, IEEE Standard for Local and 410 metropolitan networks / Media Access Control (MAC) Security / 411 Extended Packet Numbering, 12 February 2014 413 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 414 RFC 20, October 1969, . 416 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 417 STD 51, RFC 1661, July 1994, . 420 [RFC1968] - Meyer, G., "The PPP Encryption Control Protocol (ECP)", 421 RFC 1968, June 1996, . 423 [RFC2119] -Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997, 425 . 427 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 428 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 429 5310, February 2009. 431 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 432 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 433 435 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 436 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 437 2011, . 439 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 440 Ghanwani, "Routing Bridges (RBridges): Base Protocol 441 Specification", RFC 6325, July 2011, . 444 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 445 Interconnection of Lots of Links (TRILL) Protocol Control 446 Protocol", RFC 6361, August 2011, . 449 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 450 "Transparent Interconnection of Lots of Links (TRILL) Transport 451 Using Pseudowires", RFC 7173, May 2014, . 454 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 455 and V. Manral, "Transparent Interconnection of Lots of Links 456 (TRILL): Adjacency", RFC 7177, May 2014, . 459 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 460 Ward, "Transparent Interconnection of Lots of Links (TRILL): 461 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 462 2014, . 464 [RFC8126] - Cotton, M., Leiba, B., and T. Narten, "Guidelines for 465 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 466 8126, DOI 10.17487/RFC8126, June 2017, . 469 Informative References 471 [RFC1994] - Simpson, W., "PPP Challenge Handshake Authentication 472 Protocol (CHAP)", RFC 1994, August 1996, . 475 [RFC3748] - B. Aboba, et al., "Extensible Authentication Protocol 476 (EAP)," RFC 3748, June 2004 478 [RFC7258] - Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is 479 an Attack", BCP 188, RFC 7258, May 2014, . 482 [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection 483 Most of the Time", RFC 7435, December 2014, . 486 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 487 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 488 Lots of Links (TRILL): Clarifications, Corrections, and 489 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 490 . 492 [TRILL-IP] - Cullen, M., et al., "Transparent Interconnection of Lots 493 of Links (TRILL) over IP", draft-ietf-trill-over-ip, work in 494 progress. 496 Acknowledgments 498 The authors thank the following for their comments and help: 500 tbd 502 Appendix A: Summary of Changes to RFCs 6325, 6361, 7173 504 tbd ... 506 Appendix B: Ethernet Secrity to End Stations 508 MACSEC could be used between end stations and their adjacent TRILL 509 switch(es) or end-to-end between end stations or both. Since TRILL 510 does not impose administrative requirements on end stations, the 511 choice of keying and crypto suite are beyond the scope of this 512 document. However, some informative explanation and diagrams are 513 provided below to clarify how this might be done. 515 The end station must be properly configured to know if it should 516 apply MACSEC to secure its connection to an edge TRILL switch or to 517 remote end stations or both. 519 The Figure below show an Ethernet frame between a end station and the 520 adjacent edge RBridge secured by MACSEC. 522 +---------------------------------------+ 523 | Outer.MacDA (6 bytes) | 524 +---------------------------------------+ 525 | Outer.MacSA (6 bytes) | 526 +---------------------------------------+ 527 | MACSEC Tag End Station to TRILL edge | 528 +---------------------------------------+ 529 | Encrypted | 530 | +-------------------------------+ | 531 | | Optional VLAN Tag (4 bytes) | | 532 | +-------------------------------+ | 533 | | Payload Ethertype | | 534 | +-------------------------------+ | 535 | | Payload | | 536 | +-------------------------------+ | 537 +---------------------------------------+ 538 | ICV (8 or 16 bytes | 539 +---------------------------------------+ 540 | FCS (4 bytes) | 541 +---------------------------------------+ 543 The Figure below shows an Ethernet frame between an end station and 544 an adjacent edge RBridge where MACSEC is being used end-to-end 545 between that end station and remote end stations. 547 +---------------------------------------+ 548 | Outer.MacDA (6 bytes) | 549 +---------------------------------------+ 550 | Outer.MacSA (6 bytes) | 551 +---------------------------------------+ 552 | Optional Outer.VLAN | 553 +---------------------------------------+ 554 | MACSEC Tag End Station to End Station| 555 +---------------------------------------+ 556 | Encrypted | 557 | +-------------------------------+ | 558 | | Payload Ethertype | | 559 | +-------------------------------+ | 560 | | Payload | | 561 | +-------------------------------+ | 562 +---------------------------------------+ 563 | ICV (8 or 16 bytes | 564 +---------------------------------------+ 565 | FCS (4 bytes) | 566 +---------------------------------------+ 568 The Figure below shows an Ethernet frame between an end station and 569 an adjacent edge RBridge where MACSEC is being used end-to-end 570 between that end station and a remote end stations and, in addition, 571 an outer application of MACSEC is securing traffic between the end 572 station and the adjacent edge RBridge port. 574 +---------------------------------------------+ 575 | Outer.MacDA (6 bytes) | 576 +---------------------------------------------+ 577 | Outer.MacSA (6 bytes) | 578 +---------------------------------------------+ 579 | MACSEC Tag End Station to TRILL edge | 580 +---------------------------------------------+ 581 | Outer.Encrypted | 582 | +--------------------------------------+ | 583 | | Optional VLAN Tag (4 bytes) | | 584 | +--------------------------------------+ | 585 | | MACSEC Tag End Station to End Station| | 586 | +--------------------------------------+ | 587 | | Inner.Encrypted | | 588 | | +-------------------------------+ | | 589 | | | Payload Ethertype | | | 590 | | +-------------------------------+ | | 591 | | | Payload | | | 592 | | +-------------------------------+ | | 593 | +--------------------------------------+ | 594 | | Inner.ICV (8 or 16 bytes) | | 595 | +--------------------------------------+ | 596 +---------------------------------------------+ 597 | Outer.ICV (8 or 16 bytes) | 598 +---------------------------------------------+ 599 | FCS (4 bytes) | 600 +---------------------------------------------+ 602 Authors' Addresses 604 Donald Eastlake, 3rd 605 Huawei Technologies 606 155 Beaver Street 607 Milford, MA 01757 USA 609 Phone: +1-508-333-2270 610 Email: d3e3e3@gmail.com 612 Dacheng Zhang 613 Huawei Technologies 614 P.R. China 616 Email: dacheng.zhang@huawei.com 618 Copyright and IPR Provisions 620 Copyright (c) 2017 IETF Trust and the persons identified as the 621 document authors. All rights reserved. 623 This document is subject to BCP 78 and the IETF Trust's Legal 624 Provisions Relating to IETF Documents 625 (http://trustee.ietf.org/license-info) in effect on the date of 626 publication of this document. Please review these documents 627 carefully, as they describe your rights and restrictions with respect 628 to this document. Code Components extracted from this document must 629 include Simplified BSD License text as described in Section 4.e of 630 the Trust Legal Provisions and are provided without warranty as 631 described in the Simplified BSD License. The definitive version of 632 an IETF Document is that published by, or under the auspices of, the 633 IETF. Versions of IETF Documents that are published by third parties, 634 including those that are translated into other languages, should not 635 be considered to be definitive versions of IETF Documents. The 636 definitive version of these Legal Provisions is that published by, or 637 under the auspices of, the IETF. Versions of these Legal Provisions 638 that are published by third parties, including those that are 639 translated into other languages, should not be considered to be 640 definitive versions of these Legal Provisions. For the avoidance of 641 doubt, each Contributor to the IETF Standards Process licenses each 642 Contribution that he or she makes as part of the IETF Standards 643 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 644 language to the contrary, or terms, conditions or rights that differ 645 from or are inconsistent with the rights and licenses granted under 646 RFC 5378, shall have any effect and shall be null and void, whether 647 published or posted by such Contributor, or included with or in such 648 Contribution.