Ethernet Security Specification Announcement
As part of the on-going efforts to provide information assurance for National Security Systems (NSS) and leveraging the use of existing public standards and protocols, an NSA team has been analyzing Ethernet security standards and as a result has produced the Ethernet Security Specification (ESS).
This specification describes the use of public standards and protocols for Ethernet Data Encryption (EDE) to protect NSSs. The ESS is intended to be a source of information for product developers as well as NSS system architects, integrators and administrators interested in secure Ethernet data transmission.
This version concentrates on present and near-term NSS requirements but it is expected that this will be a living document where future versions will address new public standards and their impact to EDE.
The ESS can be obtained by accessing the public NCSMO website and navigating to the ‘ESS Team’ folder and ‘Documentation’ subfolder.
Any voluntary comments should be emailed to: [email protected]. Comments should include the commentators name, title, phone number, affiliation, and affiliation address.
19 October 2011
Ver. 0.5
Ethernet Security Specification (ESS) Version 0.5
02 October, 2011
Prepared By: National Security Agency 9800 Savage Road Fort George G. Meade, MD 20755
Ver. 0.5 Change Table
Version Number Description Date 0.1 Original Draft Release for Team Review 2011-06-13 0.2 Updates from Internal Review. 2011-06-30 Remove ‗DRAFT‘ watermark. Remove classification markings for declassification. 0.3 Correct typographical error: EAP-IKE to EAP- 2011-07-25 TLS 0.4 Standards/Equity Review Updates: 2011-09-14 Clarify intended audience and objective of document. Remove out-of-scope features. 0.5 Scope/Purpose section - rename and rewrite. 2011-10-02 Introduction section – reword. General - Use ‗Ethernet Data Encryption (EDE) term and replace ‗ESS device‘ with ‗NSS EDE device‘. Add EDE definition to Section 6. Add subsection column to Table 1. Add to Table 3 description. General - Use and define ‗Committee on National Security Systems (CNSS). Add draft title to bis RFCs Section 5.2.1, 4th paragraph – replace ‗shall‘ with ‗should‘. Add references to AES-128 as needed and differentiation between use of 128 and 256.
2 of 100
Ver. 0.5
Table of Contents
1. Purpose 10
1.1. Introduction 10
1.2. References 12
1.2.1. IEEE, RFC, and ISO/IEC, References 12
1.2.2. Other References 14
1.2.3. Websites 15
2. Definitions 16
3. Description 22
3.1. Use Cases 22
3.1.1. Point-to-Point 22
3.1.2. Shared Media LAN/WAN 22
3.1.3. Carrier Ethernet 23
3.2. The Ethernet Frame 25
3.3. Ethernet Architectures / Services and Virtual LANs 25
3.3.1. Virtual Bridged Local Area Networks 26
3.3.2. Provider Bridges 27
3.3.3. Provider Backbone Bridges (PBB) 28
3.3.4. Carrier Ethernet 30
3.3.5. Data Center Bridging (DCB) 31
3.4. Supported Bandwidths 31
3.5. Requirement Types 31
4. Network Scenarios and Ethernet Security 32
4.1. Single Physical Hop 34
4.1.1. Single Physical Hop between End Stations or VLAN-unaware Bridges 34 3 of 100
Ver. 0.5 4.1.2. Single Physical Hop between Provider Bridges 36
4.1.3. Single Physical Hop between Provider Backbone Bridges 38
4.2. Single Virtual Hop 40
4.2.1. Single Virtual Hop through a Metro Ethernet Network (MEN) 41
4.2.1.1. Port-based Ethernet Service UNI 41
4.2.1.2. VLAN-Based Service and Bundling Service 42
4.2.2. Single Virtual Hop in the Provider Bridged Network 47
4.2.2.1. Encryption in the Provider Bridge 47
4.2.2.2. Encryption on the Customer Side of a Provider Edge Bridge for a Single Virtual Hop 48
4.2.2.2.1. Port-based Interface Encryption on the Customer Side of a Provider Edge Bridge for a Single Virtual Hop 48
4.2.2.2.2. Service-Multiplexed Interface Encryption on the Customer Side of a Provider Edge Bridge for a Single Virtual Hop 50
4.2.2.3. Encryption on the network side of a Provider Edge Bridge for a Single Virtual Hop 51
4.2.3. Single Virtual Hop for a PBBN 52
4.2.3.1. Single Virtual Hop Encryption in the Provider Backbone Bridge 52
4.2.3.2. Encryption for a Single Virtual Hop on Customer Side of Provider Backbone Edge Bridge 53
4.2.3.2.1. Port-based Interface Encryption on the Customer Side of a Provider Backbone Edge Bridge for a Single Virtual Hop 53
4.2.3.2.2. Service-Multiplexed Interface Encryption on the Customer Side of a Provider Backbone Edge Bridge for a Single Virtual Hop 55
4.2.3.3. Encryption between I and B components of Provider Backbone Edge Bridge 58
4.2.3.4. Encryption on Provider side of B-component for a Single Virtual Hop in a PBBN 60
4.2.3.4.1. Bypass MAC-in-MAC encapsulation 61
4.2.3.4.2. I-Tag Encryption 61
4.3. End Station to End Station across a Cloud 62
4.4. Summary – Network Scenarios and Ethernet Security 62 4 of 100
Ver. 0.5 5. Security Specification 65
5.1. Ethernet Security 65
5.1.1. Cipher Suites 66
5.1.1.1. MACsec Protocol Cipher Suites 66
5.1.1.2. MACsec Key Agreement (MKA) Cipher Suites 67
5.1.1.3. EAP Method 68
5.1.1.4. IKE Cryptographic Algorithms 68
5.1.2. Supported Logical Secure Association (SA) Topologies 69
5.1.2.1. Single pair-wise SA 70
5.1.2.2. Multiple pair-wise SA 70
5.1.2.3. One to Many SA 71
5.1.3. Supported Encrypted Data Flow Topologies 71
5.1.3.1. Single Point-to-Point 71
5.1.3.2. Multiple Point-to-Point 71
5.1.3.3. Point-to-multipoint Service 72
5.1.3.4. Multi-Access Service 72
5.1.4. Additional Security Services 72
5.1.4.1. Replay Protection 73
5.2. Keying Architecture and Management 74
5.2.1. MACsec Key Agreement Protocol (MKA) 74
5.2.2. Secure Connectivity Association (CA) Creation 76
5.2.2.1. Extensible Authentication Protocol (EAP) 77
5.2.2.2. Pre-Shared Key (PSK) 78
5.2.2.2.1. Internet Key Exchange (IKE) 79
5.2.2.2.2. Pre-Placed Key (PPK) 79
5.2.3. Key Lifespan 80 5 of 100
Ver. 0.5 5.2.4. Certificates 80
5.2.5. Scenarios 81
5.2.5.1. Pairwise CA 81
5.2.5.1.1. PSK-based Pairwise CA 81
5.2.5.1.2. EAP-based Pairwise CA 81
5.2.5.2. Group CA 82
5.2.5.2.1. PSK-based Group CA 82
5.2.5.2.2. Building a Group CA from pairwise CAs 82
5.3. Ethernet Implementations – Miscellaneous Issues 83
5.3.1. Quality of Service 83
5.3.2. VLAN Tags 83
5.3.3. Encryption Bypass of Data 83
5.3.4. Encryption Bypass of Frames 84
5.3.5. Flow Control 84
5.3.6. Equal Cost Multi-Path (ECMP) 85
5.3.7. Bidirectional Forwarding Detection (BFD) 85
5.3.8. Nesting 85
5.3.9. Tunneling Across a Trusted Network 86
5.3.10. Multi-access LANs 86
5.3.11. Link Aggregation (LAG – Link Aggregate Group) 87
5.4. Ethernet Management 88
5.4.1. Initialization 88
5.4.2. Configuration Management 88
5.4.3. Ethernet Operations, Administration and Maintenance 88
5.4.4. Community of Interest (COI) 88
5.4.5. Management Information Base (MIB) 89 6 of 100
Ver. 0.5 5.5. IEEE / ESS Conformance 89
6. Abbreviations and Acronyms 97
7 of 100
Ver. 0.5 Table of Figures Figure 1- Point-to-Point Use Case...... 22 Figure 2 – Shared Media LAN / WAN Use Case...... 23 Figure 3 – Carrier Service E-Line / E-LAN / E-Tree Use Case...... 24 Figure 4 - The Standard Ethernet Frame as Defined by IEEE Std. 802.3-2008...... 25 Figure 5 - The Standard Ethernet Frame C-Tag Transformation as Defined by IEEE Std. 802.1Q- 2005...... 27 Figure 6- Standard Ethernet Frame with IEEE Std. 802.1ad-2005 S-Tag Transformation...... 28 Figure 7 – Standard Ethernet Frame with IEEE Std. 802.1ah-2008, with IB-BEB One-to-one S- tagged Interface Transformation...... 29 Figure 8 – Standard Ethernet Frame with IEEE Std. 802.1ah-2008, with I-BEB One-to-one S- tagged Interface Transformation...... 30 Figure 9- MACsec Security Tag - SecTAG, IEEE Std. 802.1AE-2006...... 33 Figure 10- Standard Ethernet Frame Transformation with MACsec, IEEE Std. 802.1AE-2006.. 35 Figure 11 - NSS EDE Device Peers Following a MAC Bridge (IEEE Std. 802.1D-2004) – Single Physical Hop...... 35 Figure 12 – NSS EDE Device and MACsec Implementation Peerage Between VLAN-unaware Bridges, IEEE Std. 802.1D-2004, Single Physical Hop...... 36 Figure 13- S-Tagged Ethernet Frame Transformed by MACsec, IEEE Std. 802.1AE-2006...... 37 Figure 14 – NSS EDE Device Peers Between Provider Bridges – IEEE Std. 802.1ad-2005, Single Physical Hop...... 37 Figure 15 – NSS EDE Device with a Provider Bridge Network Port-based Service Interface MACsec Peer Instantiation, IEEE Std. 802.1ad-2005, Single Physical Hop...... 38 Figure 16- I/B Tagged Ethernet Frame – IEEE Std. 802.1ah-2008, Followed by MACsec Transformation – IEEE Std. 802.1AE-2006 For a Single Physical Hop Topology...... 39 Figure 17 – NSS EDE Device Peers Between Provider Backbone Edge Bridges – IEEE Std. 802.1ah-2008, Single Physical Hop...... 39 Figure 18 - Metro Ethernet Network – NSS EDE Device Peers for an EPL...... 42 Figure 19 – Standard Ethernet Frame with C-Tag, IEEE Std. 802.1Q-2005; Followed by the ESS Transformation with C-Tag Encryption Bypass...... 43 Figure 20 – MACsec Capable VLAN Aware MAC Bridge with NSS EDE Device Peer Communicating over MEN...... 44 Figure 21 – Standard Ethernet Frame with (Optional) C-Tag and S-Tag Transformation Followed by the ESS / MACsec Transformation...... 44 Figure 22 – MACsec Interface Stack with C-Tagging (Optional), MACsec, and S-Tagging...... 45 Figure 23 – I/B Tagged Ethernet Frame – IEEE Std. 802.1ah-2008 Followed by the ESS Transformation For a Single Virtual Hop Topology Traversing MEF VLAN-Based or Bundling Service UNIs...... 46 Figure 24 – MEN Topology of an EVP-LAN...... 47 Figure 25 - Standard Ethernet Frame with C-Tag (Optional) And S-Tag Transformation Followed by MACsec Transformation...... 47 Figure 26 – Standard Ethernet Frame with C-Tag (Optional) and S-Tag (Optional) Transformation Followed by MACsec Transformation...... 49 Figure 27 – NSS EDE Device Peers at the Customer Edge and a Port-based Service Interface to a Provider Bridge Network – IEEE Std. 802.1ad-2005, Single Virtual Hop...... 49 Figure 28 – NSS EDE Device at the Customer Edge and a Provider Bridge Network Port-based Service Interface MACsec peer instantiation, IEEE Std. 802.1ad-2005, Single Virtual Hop...... 50 Figure 29 - C-tagged Service Interface of a PBN with NSS EDE Device Peers at Customer Side 8 of 100
Ver. 0.5 of Provider Edge Bridge...... 51 Figure 30- Single Virtual Hop Topology for NSS EDE Device Peers at Provider Side of Provider Edge Bridge...... 52 Figure 31 – I/B Tagged Ethernet Frame Transformation with Ethernet Encryption within a PBBN Bridge...... 53 Figure 32 – Frame Transformation at Customer Side of PBBN Followed by PBB Encapsulation...... 54 Figure 33 – Port-Based Service Interface of a PBBN with NSS EDE Device Peers at Customer Side in a Single Virtual Hop Scenario...... 55 Figure 34 – I-Tagged Service Interface Ethernet Frame Security Transformation at the Customer Side of the Customer BEB...... 56 Figure 35 – I-Tagged Service Interface of a PBBN with NSS EDE Device Peers at Customer Controlled BEB Side Topology...... 57 Figure 36 – I-Tagged Service Interface of a PBBN with MACsec and the NSS EDE Device Peers at Customer Controlled BEB Side...... 57 Figure 37- Interface Stack with C-Tagging (Optional), MACsec, S-Tagging, and I-Tagging...... 58 Figure 38 – EDE Between I and B Components of Provider Edge Bridge...... 59 Figure 39 – NSS EDE Device Peers Between I and B Components of the Provider Backbone Edge Bridge in a PBBN...... 59 Figure 40 – MACsec and NSS EDE Device Peer Interoperability Between I- and B-Components of the Provider Backbone Edge Bridge in a PBBN...... 60 Figure 41 – NSS EDE Peers at Provider Side of Provider Backbone Edge Bridge...... 61
Table of Tables Table 1 – Summary of Network Scenarios and the ESS Security Goals and Recommendations. . 64 Table 2- Cipher Suites...... 66 Table 3 – Re-key Intervals...... 75 Table 4 - IEEE vs. ESS Conformance Requirements...... 96
9 of 100
Ver. 0.5
1. Purpose
The Ethernet Security Specification (ESS) describes the use of public standards and protocols for Ethernet Data Encryption (EDE) to protect National Security Systems (NSSs). Certain NSS applications may have additional Government requirements such as the need for a standalone NSS EDE device or the need to protect SECRET and TOP SECRET information in different ways. The ESS will address the requirements using various architectures for using a standalone NSS EDE device with another NSS EDE device or an embedded EDE service. The ESS identifies standards conformance issues in each architecture as well as the need for any additional security requirements.
The ESS is intended to be a source of information for product developers as well as system integrators and administrators.
The ESS concentrates on present and near-term NSS requirements. Items under consideration for future standardization include:
Data Center Bridging. Rates above 100 Gbps.
1.1. Introduction
The ESS will be based on the Media Access Control (MAC) Security standard (MACsec), IEEE Std. 802.1AE-2006, and the companion Key Exchange / Key Management standard, IEEE Std. 802.1X-2010. MACsec as defined by the IEEE, is designed to provide port level authentication and data confidentiality on a hop-by-hop basis for MAC-layer Ethernet frames. Additional public standards and protocols will be identified as needed.
ESS will describe the mandatory and optional requirements that a standalone NSS EDE device must implement to provide the features needed to protect NSSs and to be compliant with the identified public standards and protocols.
The ESS provides a general picture of the Ethernet technology as it pertains to security, implementation of existing security standards and protocols, and their interrelationship to Ethernet. For this purpose the document is subdivided into the following sections:
Section 1: provides the purpose and introduction to the document, and a documentation reference subsection. Section 2: provides definitions for the terms used in this document. Section 3: provides the Use Case Scenarios that shall be addressed in this document; presents a description of the Ethernet Standard Frame; presents a definition of various Ethernet architectures, services, and Virtual LANs; provides the bandwidths that this specification supports; and presents a definition of the requirement types covered in this specification. 10 of 100
Ver. 0.5 Section 4 and 5 in combination describe various security architectures and provide guidance to the Committee on National Security Systems (CNSS) members seeking to architect a secure Ethernet network using Ethernet encryption, and to developers seeking to build an Ethernet encryption device using existing standards and protocols. o Section 4: addresses the use of an NSS EDE device in various networking topologies. o Section 5: addresses how to implement the ESS security solutions in an NSS EDE device. Section 6: provides a list of the acronyms used in this document.
NOTE: For purposes of this specification ―the User‖, ―NSS user‖ or ―user‖ shall refer to a National Security Community member interested in Ethernet security methods and/or interested in the use of EDE devices in National Security System(s) (NSS(s)).
NOTE: For purposes of this specification references to a ‗network administrator‘, ‗network architect‘ shall refer to a person or persons employed or contracted by a National Security Community User to perform network functions as defined by the designated role.
NOTE:Whenever used in this specification ―NSS EDE device‖ shall refer to the Ethernet data encryption device intended for government use implementing the requirements and goals as specified in the ESS.
11 of 100
Ver. 0.5 1.2. References
1.2.1. IEEE, RFC, and ISO/IEC, References
IEEE Std. 802.1ad-2005, IEEE Standard for Local and Metropolitan Area Networks, Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges.
IEEE Std. 802.1AE-2006, IEEE Standard for Local and Metropolitan Area Networks, Media Access Control (MAC) Security.
P802.1AEbn/D0.8, Draft Amendment to IEEE Std. 802.1AE-2006, Draft Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security, Amendment 1: Galois Counter Mode-Advanced Encryption Standard-256 (GCM-AES-256) Cipher Suite.
IEEE Std. 802.1ag-2007, IEEE Standard for Local and Metropolitan Area Networks, Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management.
IEEE Std. 802.1ah-2008, IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges.
IEEE Std. 802.1AR-2009, IEEE Standard for Local and Metropolitan Area Networks – Secure Device Identity.
IEEE Std. 802.1D-2004, IEEE Standard for Local and Metropolitan Area Networks – Media Access Control (MAC) Bridges.
IEEE Std. 802.1Q-2005, IEEE Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks.
IEEE Std. 802.1Qau/D2.4-2009, Draft Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks- Amendment: Congestion Notification.
IEEE Std. 802.1Qay-2009, IEEE Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks, Amendment 10: Provider Backbone Bridge Traffic Engineering.
IEEE Std. 802.1Qaz/D2.0-2010, Draft Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks, Amendment XX: Enhanced Transmission Selection for Bandwidth Sharing Between Traffic Classes.
IEEE Std. 802.1Qbb/D2.3-2010, Draft Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks, Amendment: Priority-based Flow Control.
IEEE Std. 802.1X-2010, IEEE Standard for Local and Metropolitan Area Networks – Port-Based Network Access Control.
IEEE Std. 802.3-2008, Section 1 through 5 – IEEE Standard for Information Technology – 12 of 100
Ver. 0.5 Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements, Part 3: Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.
IEEE Std. 802.3ba-2010, IEEE Standard for Information Technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, Amendment 4: Media Access Control Parameters, Physical Layers and Management Parameters for 40 Gb/s and 100 Gb/s.
IEEE Std. 802.3ah-2004, IEEE Standard for Information Technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements, Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, Amendment: Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks.
IETF RFC 2991, Multipath Issues in Unicast and Multicast Next-Hop Selection, November 2000.
IETF RFC 3024, Reverse Tunneling for Mobile IP, revised, January 2001.
IETF RFC 3394, Advanced Encryption Standard (AES) Key Wrap Algorithm, September 2002.
IETF RFC 4108, Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages, August 2005.
IETF RFC 4291, IP Version 6 Addressing Architecture, February 2006.
IETF RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS), May 2006.
IETF RFC 4869, Suite B Cryptographic Suites for IPSec, May 2007. Draft-law-rfc4869bis, Suite B Cryptographic Suites for IPSec, April 2011.
IETF RFC 5216, The EAP-TLS Authentication Protocol, March 2008.
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, August 2008.
IETF RFC 5247, Extensible Authentication Protocol (EAP) Key Management Framework, August 2008.
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008.
IETF RFC 5288, AES Galois Counter Mode (GCM) Cipher Suites for TLS, August 2008.
IETF RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM), August 2008. 13 of 100
Ver. 0.5
IETF RFC 5430, SUITE B Profile for Transport Layer Security (TLS), March 2009. Draft-salter-rfc5430bis, Suite B Profile for Transport Layer Security (TLS), April 2011.
IETF RFC 5649, Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm, August 2009.
IETF RFC 5759, SUITE B Certificate and Certificate Revocation List (CRL) Profile, January 2010.
IETF RFC 5880 – Bidirectional Forwarding Detection (BFD), June 2010.
IETF RFC 5881 – Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop), June 2010.
IETF RFC 5882 – Generic Application of Bidirectional Forwarding Detection (BFD), June 2010.
IETF RFC 5883 – Bidirectional Forwarding Detection (BFD) for Multihop Paths, June 2010.
IETF RFC 5884 – Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs), June 2010.
IETF RFC 5953, Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP), August 2010.
IETF RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), September 2010.
IETF draft-bhatia-bfd-crypto-auth-03, BFD Generic Cryptographic Authentication, January 2011.
MEF Technical Specification 6.1, Ethernet Services Definitions – Phase 2, April 2008.
MEF Technical Specification 10.2, Ethernet Services Attributes Phase 2, October 2009.
MEF Technical Specification 12.1, Carrier Ethernet Network Architecture Framework, Part 2: Ethernet Service Layer – Base Elements, April 2010.
MEF Technical Specification 16, Ethernet Local Management Interface, January 2006.
1.2.2. Other References
NIST Special Publication (SP) 800-38D, National Institute of Standards and Technology, Recommendation for Block Cipher Modes of operation: Galois/Counter Mode (GCM) and GMAC, November 2007.
Federal Information Processing Standards Publication 197 (NIST, FIPS 197), Announcing the
14 of 100
Ver. 0.5 ADVANCED ENCRYPTION STANDARD (AES), November 2001.
NIST Special Publication 800-56A, National Institute of Standards and Technology, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptology (Revised), March 2007.
NIST Inter-Agency Report 7316, National Institute of Standards and Technology, Assessment of Access Control Systems, September 2006.
U.S. Government Approved Protection Profile, Security Requirements for Network Devices, Version 1.0, 10 December 2010.
1.2.3. Websites
The Metro Ethernet Forum (MEF) website: http://metroethernetforum.org. For publications click on Information Center, and click on MEF Technical Specifications.
The Institute of Electrical and Electronics Engineers (IEEE) website: http://www.ieee.org. For publications: http://standards.ieee.org/about/get.
The Internet Engineering Task Force (IETF) website: http://www.ietf.org.
The National Security Agency (NSA) website for Suite B cryptography: http://www.nsa.gov/ia/programs/suiteb_cryptography/.
The National Institute of Standards and Technology (NIST) website: http://www.nist.gov.
The National Information Assurance Partnership (NIAP) for Protection Profiles website: http://www.niap-ccevs.org.
15 of 100
Ver. 0.5 2. Definitions
Advanced Encryption Standard (AES): A symmetric key encryption standard defined in NIST, FIPS 197. Association Number (AN): A 2-bit number that is concatenated with the Secure Channel Identifier to identify a Secure Association. The AN is carried in the SecTAG. Authentication exchange: The two-party conversation between systems performing an authentication process. Authentication process: The cryptographic operations and supporting data frames that perform the actual authentication. Authentication server: An entity in EAP that provides an authentication service to an Authenticator. This service determines, from the credentials provided by the Supplicant, whether the Supplicant is authorized to access the services provided by the system in the context of a peer relationship with the Authenticator. Authenticator: An entity that facilitates authentication of other entities attached to the same LAN. B-BEB: Backbone Edge Bridge (BEB) for a PBBN containing a B-Component. B-Component (B-Comp): A B-component is part of a PBBN, see IEEE Std. 802.1ah-2008. It is comprised of an S-VLAN component with the EISS on each Provider Network Port supported by the use of an S-Tag, and the EISS on each Customer Backbone Port supported by the use of both an S-Tag and an I-Tag. The B-Comp handles part of the relaying and filtering of frames across the backbone. Backbone Core Bridge (BCB): An S-VLAN Bridge used within the core of a Provider Backbone Bridged Network. Backbone Edge Bridge (BEB): A system that encapsulates customer frames for transmission across a Provider Backbone Bridge Network. Backbone Service Instance Identifier (I-SID): A field of the I-Tag that identifies the backbone service instance of the frame.
Backbone Service Instance Tag (I-Tag): A VLAN tag used by Backbone Edge Bridges.
Backbone VLAN (B-VLAN): A VLAN identified by a Backbone VLAN ID. Backbone VLAN ID (B-VID): A VLAN identifier conveyed in a B-Tag. Backbone VLAN Tag (B-Tag): An S-TAG used in conjunction with backbone MAC addresses. Black: Designation applied to encrypted information and the information systems, the associated areas, circuits, components, and equipment processing that information.
16 of 100
Ver. 0.5 Bridged Local Area Network: A concatenation of individual IEEE 802 LANs interconnected by MAC Bridges. CA: See Secure Connectivity Association. CAK: See Secure Connectivity Association Key. Cipher Suite: A set of one or more algorithms, designed to provide any number of the following: data confidentiality, data authenticity, and data integrity. Common Port: An instance of the insecure MAC Internal Sublayer Service used by the MACsec Security Entity (SecY) to provide transmission and reception of frames for both the controlled and uncontrolled ports (red-side). Controlled Port: The access point used to provide the secure MAC Service to a client of a SecY. Cryptographic Key: A secret parameter that determines the operation of a cryptographic function such as: the transformation from plain text to cipher text and vice versa, synchronized generation of keying material, digital signature computation or validation. Customer Backbone Port (CBP): A Backbone Edge Bridge Port that can receive and transmit I-tagged frames for multiple customers, and can assign B-VIDs and translate I-SID on the basis of the received I-SID. Customer MAC Address (C-MAC): A MAC address within a Customer Bridged Network (CBN) or Provider Bridged Network. Customer MAC Addresses are carried within an I-TAG in a Provider Backbone Bridged Network. Customer VLAN Tag (C-Tag): A VLAN tag associated with VLAN aware bridged standardized in IEEE Std. 802.1Q-2005. Data Center: An environmentally controlled, centralized, concentrated, redundant, uninterruptible, and dedicated facility including a large collection of information systems, providing computing services by securely delivering applications and data across a network to remote users. Data Integrity: A property whereby data has not been altered in an unauthorized or unintended manner since it was created, transmitted or stored. Enhanced Internal Sublayer Service (EISS): Based on the ISS with the added functionality to handle tags. Ethernet Line (E-Line): MEF Ethernet Service Type for Point-to-Point service. Ethernet LAN (E-LAN): MEF Ethernet Service Type for Multipoint-to-Multipoint service. Ethernet Tree (E-Tree): MEF Ethernet Service Type for Rooted-Multipoint EVC. This service provides traffic separation between ‗Leaf‘ UNIs. Galois/Counter Mode (GCM): An algorithm for authenticated encryption with associated data and its specialization, GMAC, for generating a message authentication code (MAC) on data that
17 of 100
Ver. 0.5 is not encrypted. GCM and GMAC are modes of operation for an underlying approved symmetric key block cipher. GMAC: A specialization of GCM for generating a message authentication code on data that is not encrypted. Hub: A device used to interconnect network segments operating at Layer 1 of the OSI Model. Traditionally, a hub performs no manipulation or analysis of frames passing through the device. Frames received at one port are delivered to all other ports on the device. I- component (I-comp): Is comprised of an S-VLAN component with the EISS on each Customer Network Port supported by the use of an S-Tag, and the EISS for each Virtual Instance Port configured on a Provider Instance Port supported by the use of both an S-Tag and an I-Tag. I-SID: See Backbone Service Instance Identifier. I-tagged frame: A frame that contains a Backbone Service Instance tag immediately following the Source MAC address field. Initialization Vector (IV): A vector used in defining the starting point of an encryption process within a cryptographic algorithm. Integrity Check Value (ICV): A value that is derived by performing a cryptographic transformation on the data unit for which data integrity services are provided. The ICV is sent with the protected data unit and is recalculated and compared by the receiver to detect data modification. Internal Sublayer Service (ISS): Based on the MAC Service with frame relay functionality added. KaY: See MAC Security Key Agreement Entity. Key Management: Process and procedures defined in a cryptographic system for the secure generation, exchange, storage, safeguarding, use, vetting, and replacement of keys. Key Management Domain (KMD): A string that identifies systems that share cached CAKs used by MKA. MAC Bridge: A designation used in IEEE to define a device used to interconnect network segments, relaying and filtering frames between separate MACs of the bridged LAN. MAC Bridges operate at Layer 1 and 2 of the OSI Model, below the MAC service boundary and is transparent to protocols operating above the boundary.
MAC in MAC: Street name denoting a PBBN and the use of B-Tags and I-Tags as defined in the IEEE Std. 802.1ah-2008 standard. MAC Security Key Agreement Entity (KaY): Is an entity that provides / updates cryptographic keys. It is defined and required by IEEE Std. 802.1AE-2006 and specified in IEEE Std. 802.1X- 2010, and used by MKA. MAC Security Entity (SecY): The entity that operates the MAC Security protocol within a system. It is specified in IEEE Std. 802.1AE-2006. 18 of 100
Ver. 0.5 MAC Security TAG (SecTAG): A protocol header, comprising a number of octets and beginning with an EtherType, that is pre-pended to the service data unit supplied by the client of the protocol, and is used to provide security guarantees. MAC Service Data Unit (MSDU): A sequence of zero or more octets that compose the data to be communicated with a single MAC Service request or indication. MACsec Key Agreement Protocol (MKA): Is a protocol defined in IEEE Std. 802.1X-2010 that enables PAEs to discover other PAEs, to confirm mutual possession of a CAK and hence to prove a past mutual authentication, to agree the secret keys (SAKs) used by MACsec for symmetric shared key cryptography, and to ensure that the data protected by MACsec has not been delayed. Master Session Key (MSK): A secret key created by EAP and used to derive one or more cryptographic keys. Multipoint: Involving or potentially involving more than one participant in the role of receiver, or in the role of transmitter, in a single data transfer or set of related data transfers. Network Identity (NID): A UTF-8 (IETF RFC 3629) string identifying a network or network service used by MKA. Nonce: A non-repeating value used in key management protocols to thwart replay and other types of attacks. Packet Number (PN): A monotonically increasing value used to uniquely identify a MACsec frame in the sequence of frames transmitted using a Secure Association. It forms part of the MACsec Security Tag and is used in the MACsec cipher suite IV. Port Access Entity (PAE): The protocol entity defined in IEEE Std. 802.1X-2010 associated with a port whose access to network peers is being controlled. Port Identifier: A 16-bit number that is unique within the scope of the address of the port. Point to Point: A point to point connection is defined as a dedicated communication link between two systems. Pre-Shared Key (PSK): A key used to initiate MKA that is obtained by means other than EAP. Protocol Data Unit (PDU): A unit of data specified in a protocol and consisting of protocol information and, possibly, user data. Provider Backbone Bridge (PBB): A Backbone Core Bridge or a Backbone Edge Bridge. Provider Backbone Bridge Network (PBBN): A network using Backbone Edge Bridges and Backbone Core Bridges to interconnect Provider Bridged Networks and other networks – specified in IEEE Std. 802.1ah-2008. Provider Bridge Network (PBN): A network using Provider Bridges to offer customer protocol transparent connectivity – specified in IEEE Std.802.ad-2005.
19 of 100
Ver. 0.5 Provider Edge Bridge: A system comprising a single S-VLAN component and one or more C- VLAN components implemented in accordance to IEEE Std. 802.1Q-2005. Provider Edge Port: A C-VLAN component port within a Provider Edge Bridge that connects to a Customer Network Port and receives and transmits frames for a single customer. Provider Network Port: An S-VLAN component port on a Provider Bridge that can transmit and receive frames for multiple customers. Provider Instance Port (PIP): The set of Virtual Instance Ports that are supported by a single instance of the Internal Sublayer Service (ISS). Red: In cryptographic systems, refers to information or messages that contain sensitive or classified information that is not encrypted.
Router: A device used to interconnect network segments operating at Layer 3 of the OSI Model. Device implementations can include sophisticated traffic manipulation schemes, firewalls, etc.
Q in Q: Street name denoting a PBN and the use of S-Tags as defined in the IEEE Std. 802.1ad- 2005 standard. S-VLAN component: A VLAN-aware bridge component with each Port supported by an instance of the EISS that can recognize, insert, and remove Service VLAN tags. Secure Association (SA): A security relationship that provides security guarantees for frames transmitted from one member of a CA to the others. Each SA is supported by a single secret key, or a single set of keys where the cryptographic operations used to protect one frame require more than one key. Secure Association Identifier (SAI): An identifier for an SA, comprising the SCI concatenated with the Association Number (AN). Secure Association Key (SAK): The symmetric secret key used by an SA. Secure Channel (SC): A security relationship used to provide security guarantees for frames transmitted from one member of a CA to the others. An SC is supported by a sequence of SAs thus allowing the periodic use of fresh keys without terminating the relationship. Secure Channel Identifier (SCI): A globally unique identifier for a secure channel, comprising a globally unique MAC Address and a Port Identifier, unique within the system allocated that address. Secure Connectivity Association (CA): A security relationship, established and maintained by key agreement protocols, that comprises a fully connected subset of the service access points in stations attached to a single LAN that are to be supported by MACsec. Secure Connectivity Association Key (CAK): Secret key possessed by members of a given CA. Secure Connectivity Association Key Name (CKN): A text that identifies a CAK. SecTAG: See MAC Security Tag. 20 of 100
Ver. 0.5 SecY: See MAC Security Entity. Service-Multiplexed Interface: Service associated with a Provider Bridge that can be C-tagged or S-tagged. See IEEE Std. 802.1ad-2005 Clause 15.4 and Clause 15.5 for details. Service Provider: An organization that contracts to provide one or more service instances to a customer. Service VLAN tag (S-Tag): A VLAN tag association with VLAN service provided by a Service Provider.
Spanning Tree Algorithm and Protocol (STP): This protocol ensures loop free topology over an Ethernet bridged network and is standardized by IEEE Std. 802.1D-2004. Supplicant: An entity at one end of a point-to-point LAN segment that seeks to be authenticated by an Authenticator attached to the other end of that link. Switch: Street name denoting an IEEE bridge. Uncontrolled Port: The access point used to provide the insecure MAC Service to a client of a SecY. User Network Interface (UNI): Term used by MEF to define the physical demarcation point between the responsibility of the Service Provider and the responsibility of the Subscriber. Virtual Port: A MAC Service or Internal Sublayer Service access point that is created on demand. Virtual ports can be used to provide separate secure connectivity associations over the same LAN. VLAN-aware Bridge: A bridge that recognizes frames with a VLAN tag and can insert or remove tag headers. VLAN Tag: Tag that allows a VLAN Identifier to be conveyed, facilitating consistent VLAN classification of the frame throughout the network and enabling segregation of frames assigned to different VLANs. It also allows priority to be conveyed with the frame when using IEEE 802 LAN MAC control methods that provide no inherent capability to signal priority. VLAN-unaware Bridge: A bridge that does not recognize VLAN-tagged frames.
21 of 100
Ver. 0.5 3. Description
This section lays the groundwork for discussing the various security architectures. Subsection 3.1 identifies three general NSS Ethernet Use Cases. Subsection 3.2 provides a brief description of the standard Ethernet data frame. Subsection 3.3 provides a brief description of the various Ethernet Services including virtualization. Subsection 3.4 addresses the bandwidths addressed by the ESS. Subsection 3.5 provides a definition of the language used to differentiate between specification types.
3.1. Use Cases
The following Ethernet Encryption Use Cases were considered: Point-to-Point. Shared Media LAN / WAN. Carrier Ethernet.
3.1.1. Point-to-Point
A point to point connection is defined as a dedicated communication link between two systems. Figure 1 depicts a point-to-point connection with Ethernet encryption devices securing the connection. In this scenario, the communication connection (value above the link) and the secure connection (value below the link), are seen as the same and do not vary along the path.
1 1 1 1 2 Customer Customer 1 1 1 1 System System
Ethernet Ethernet Encryptor Encryptor
Figure 1- Point-to-Point Use Case.
3.1.2. Shared Media LAN/WAN
A more complex scenario is a shared media LAN/WAN as shown in Figure 2. Communication connections exist between four end-stations residing on three Customer Systems. An Ethernet switch connected to Customer System 1 (CS1) manages the traffic, tagging each frame as needed for routing to its destination (NSS user configured). A switch or router sits inside ‗the cloud‘
22 of 100
Ver. 0.5 managing the distribution of frames to the intended recipient. Depending on how the NSS user configures the switch the communication connection could be implemented as various scenarios.
One scenario could be communication connections 1, 2, 3 and 4, each representing point-to-point connections that in turn could be four point-to-point Secure Connection Associations (CAs) 1, 2, 3 and 4.
A second scenario can be implemented by the router/switch NSS user configuration. Here the communication connections are the same from the point of view of the end-stations, but since end-stations 3 and 4 reside on the same customer system 4 (CS4), the router/switch can aggregate the destination frames by using a VLAN tag – in this case 5. The CAs would be defined as 1, 2 and 5.
The third scenario aggregates all communication connections into one tag, 6.
The Secure Connections managed by the Ethernet Encryption devices shall not change the data flow as defined by the neighboring customer system and/or Ethernet switch, but shall add restrictions depending on the secure associations (SAs) allowed to be established. Subsection 5.1.2 provides definitions for the various SA topologies that can be supported. Subsection 5.1.3 provides definitions of the encrypted data flow topologies supported: point-to-point, multiple point-to-point, point-to-multipoint, and multi-access services.
Virtualization and the use of tags in an Ethernet network without security are covered in subsection 3.3. The impacts of VLAN tags on securing Ethernet traffic are covered in Section 4.
Customer 1 System (CS2) 1 Ethernet 1 Encryptor (EE2) 6 1 Customer Customer 1,2,3,4 2 System 2 1,2,3,4 2 System (CS1) 3 2 (CS3) 4 1,2,(3)5,(4)5 1,2,5 6 Ethernet 6 6 Ethernet 3,4 Encryptor (EE3) 5 3 Customer Encryptor 6 3,4 System 4 (EE1) 5 (CS4) 6 Ethernet Encryptor (EE4)
Figure 2 – Shared Media LAN / WAN Use Case.
3.1.3. Carrier Ethernet
Carrier Ethernet is defined as the extensions to Ethernet that enable common carriers to provide their services via an Ethernet customer interface. The Metro Ethernet Forum (MEF) was created 23 of 100
Ver. 0.5 to clarify and standardize the services provided. MEF defines Carrier Ethernet as a ubiquitous, standardized, carrier-class Service and Network that provides: Standardized services. Scalability. Reliability. Quality of Service. Service Management.
Carrier Ethernet provides 3 distinct service types: Ethernet Line (E-Line), Ethernet LAN (E- LAN), and Ethernet Tree (E-Tree). E-Line is a point-to-point service. E-LAN is a multipoint-to- multipoint service. E-Tree is a multipoint service connecting one or more roots and a set of leaves, but preventing interleaved communication. When considering the transport of secure Ethernet frames over any of the above mentioned service types, the ESS shall also consider the service attributes of the User Network Interface (UNI) that are split into All to One Bundling (Port-based) or Service Multiplexed (VLAN-based) – see subsection 4.2.1. For details on Carrier Ethernet service types MEF has multiple specifications including MEF 6.1, MEF 10.2 and MEF 12.1.
NOTE: Detail information on Carrier Ethernet and services provided is out of scope for this specification. Refer to http://metroethernetforum.org for specifications, white papers, etc.
Figure 3 depicts a generic use case of a pair of customer system peers interconnecting via Carrier Ethernet with a pair of Ethernet encryption peers securing traffic over the Metro Ethernet Network (MEN). The communication connections are no different from those supported in the shared media LAN/WAN depicted in Figure 2.
1 Customer System Ethernet (CS2) 1 Encryptor 1
Customer Customer 1,2,3,4 2 1,2,3,4 2 System System 2 Ethernet (CS3) (CS1) 1,2,3,4 1,2,3,4 Encryptor 1,2,(3)5,(4)5 1,2,5 3,4 E-Line/ 3 3,4 3,4 Customer E-LAN/ 4 System Ethernet E-Tree 5 3,4 (CS4) 5 Encryptor Services Ethernet Encryptor
Figure 3 – Carrier Service E-Line / E-LAN / E-Tree Use Case.
24 of 100
Ver. 0.5 3.2. The Ethernet Frame
The standard Ethernet Frame as defined in IEEE Std. 802.3-2008 is depicted in Figure 4. For a detailed description of the fields refer to IEEE Std. 802.3-2008 Section 1, Clause 3.
NOTE: Whenever used in this specification ―the Ethernet frame‖ or ―the standard Ethernet frame‖ shall refer to the description provided in IEEE Std. 802.3-2008, unless otherwise clearly indicated by the text.
Destination Source Type/ Payload Frame Check Address Address Length Sequence (FCS) 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets
MAC Addresses MSDU – MAC Service Data Unit
Figure 4 - The Standard Ethernet Frame as Defined by IEEE Std. 802.3-2008.
3.3. Ethernet Architectures / Services and Virtual LANs
The IEEE Standards body defines several mechanisms for logical segregation of Layer 2 traffic accomplished by applying various VLAN tags to the Ethernet Frame. How these tags relate to the different Ethernet Architectures and Services impacts the data flow of a frame through the different network types. The tags can be defined as: Customer VLAN Tag (C-Tag). Service VLAN Tag (S-Tag). Backbone Service Instance Tag (I-Tag). Backbone VLAN Tag (B-Tag). Customer Edge VLAN Tag (CE-Tag).
The administration of a secure architecture is independent of the implementation and use of the various tags, but it is important that the ESS complement and not interfere with their function. See Section 4 for detailed descriptions on the ESS handling of tags listed in this section.
It is relevant to distinguish virtual LAN (VLAN) mechanisms that cause an intervening bridged LAN to appear as a single physical LAN segment to the edge points of the VLAN, versus VLAN mechanisms for which the VLAN appears as a simple (bridged) subset of the underlying physical bridged LAN. To secure data traffic, connections are expected to reside on a single LAN, hop- to-hop, and so it is important to realize that virtual services enable a ‗bridged LAN‘ to appear to a Customer Bridge as a single LAN. This distinction and its importance to Ethernet data security is described in detail in subsection 4.2.
It is important to understand the underlying differences between a bridge, a hub, and a switch both as a part of the foundation for understanding MACsec, and to better define the intended 25 of 100
Ver. 0.5 nature of a ―standalone‖ NSS EDE device. ESS defines ―standalone‖ as a device that appears to bridges as if it is a hub, and should be as operationally simple as a hub in terms of frame relay and filtering. In particular, for any in-coming red-side frame, there must be one and only one secure MAC Service port (supported by a SecY) to relay the frame based on static principles rather than a learned topology. When there is only one Secure MAC Service port at all, the behavior is identical to a hub. When there are multiple secure MAC Service ports, the relay filtering shall be based on VLAN tags, and there must be a unique secure MAC Service port in the ESS device for each supported VLAN. So for each configured VLAN, the ESS device also behaves like a hub. The NSS EDE device will differ from a hub as it will include higher layer entities providing, for example, MKA and EAP functionality.
The following subsections depict the impact to a standard Ethernet frame from each of the above mentioned tags.
NOTE: For information outside the scope of this document, the reader is encouraged to read referenced IEEE standards, RFCs, MEN specifications, etc.
3.3.1. Virtual Bridged Local Area Networks
IEEE Std. 802.1Q-2005 defines the operation of Bridges that define, operate and administer VLANs within the Virtual Bridged Local Area Networks – also known as VLAN aware bridges. This standard relies on the application of the Customer VLAN Tag (C-Tag) to the Ethernet Frame as depicted in Figure 5. For a detailed description of the tag fields refer to IEEE Std. 802.1Q-2005, Clause 9 and Appendix C, Figure C-3.
The C-tagged virtual LAN presents a (bridged) subset of the full bridged LAN to any device served by the virtual LAN. In addition, devices can be attached to a C-VLAN at any physical segment of the VLAN, meaning there is no functional difference between edge segments where frames are untagged versus service-multiplexed segments in which frames are tagged. Because of this, a C-VLAN can never appear as a ―single LAN―– a fundamental requirement for establishing secure Connectivity Associations (CAs) (more on this in subsection 4.2).
26 of 100
Ver. 0.5 Standard Ethernet Frame MAC Addresses MSDU
6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets
DA SA Type/ Payload FCS Length ------DA SA C-Tag Prefix Type/ Payload FCS Length 4 Octets
C-Tag Tag Control Ethertype Information 2 Octets 2 Octets
Ethertype User CFI VLAN Identifier (VID) = 81-00 Priority 3 Bits 1 Bit 12 Bits Standard Ethernet Frame with C-Tag – 802.1Q-2005
Figure 5 - The Standard Ethernet Frame C-Tag Transformation as Defined by IEEE Std. 802.1Q- 2005.
3.3.2. Provider Bridges
IEEE Std. 802.1ad-2005, also known as Q-in-Q, further extends the definition of Virtual Services to apply to service providers. This standard relies on the application of the Service VLAN Tag (S-Tag) to the Ethernet Frame as depicted in Figure 6. For a detailed description of the tag fields refer to IEEE Std. 802.1ad-2005, Clause 9.
A critical feature of Provider Bridges is that the S-VLAN is a provider construct – whether an enterprise or external service provider. IEEE Std. 802.1ad-2005 enables this VLAN construct to be transparent to customer equipment; thus an S-VLAN becomes a separate MAC sub-layer. The Enhanced Internal Sub-layer Service (EISS) of the Provider Edge Bridge sees the other Provider Edge Bridges as if they all reside on a single (bridgeless) LAN segment.
In other words, S-VLANs create a provider core, called a Provider Bridged Network (PBN) that presents service to edge points. There is an inside and outside. At the edge points (i.e. on the outside), the S-VLAN behaves like a single physical LAN segment, even though on the inside it can be a complex bridged physical LAN. Users of an S-VLAN can only connect to the S-VLAN at the edge. Spanning Trees for routing (whether "simple", "rapid", or "multiple") computed
27 of 100
Ver. 0.5 outside the PBN treat a PBN or concatenation of PBNs as a single segment, whereas the spanning trees inside the PBN cover the entire bridged network and address space-inside and outside the PBN.
Standard Ethernet Frame MAC Addresses MSDU
6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets
DA SA Type/ Payload FCS Length ------DA SA S-Tag Prefix Type/ Payload FCS Length 4 Octets
S-Tag Tag Control Ethertype Information 2 Octets 2 Octets
Ethertype PCP DEI VLAN Identifier (VID) = 88-A8 3 Bits 1 Bit 12 Bits Standard Ethernet Frame with S-Tag – 802.1ad-2005
Figure 6- Standard Ethernet Frame with IEEE Std. 802.1ad-2005 S-Tag Transformation.
3.3.3. Provider Backbone Bridges (PBB)
IEEE Std. 802.1ah-2008, also known as MAC-in-MAC, further extends the definition of Virtual Services to apply to Provider Backbone Bridges (PBBs). This standard relies on the application of the Backbone Service Instance Tag (I-Tag), Backbone VLAN Tag (B-Tag), Backbone Destination MAC Address (B-DA) and Backbone Source MAC Address (B-SA) to the Ethernet Frame as depicted in Figure 7. For a detailed description of the tag fields refer to IEEE Std. 802.1ah-2008, Clause 9, and Clause 25, Figure 25-6.
NOTE: The Customer Destination and Source MAC addresses become part of the I-Tag.
Provider Bridged Backbone Networks (PBBNs) are similar to PBNs for NSS users of the network. A PBBN behaves like a single Physical LAN segment for devices that are outside the PBBN but connected to it. However the PBBN edge bridges map customer source and destination addresses to corresponding PBBN Edge Bridge addresses. This way the routing spanning trees in the backbone are not burdened with learning the attached customer networks, 28 of 100
Ver. 0.5 but need only concern themselves with routing through the backbone itself. The provision of PBBN Edge Bridge addresses enables the PBBN to route all Ethernet frames edge-to-edge.
Standard Ethernet Frame MAC Addresses MSDU
6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets
DA SA Type/ Payload FCS Length ------B-DA B-SA B-Tag I-Tag Type/ Payload FCS Length
B-Tag TPID PCP Backbone VID I-Tag TPID I-Tag C-DA C-SA (Ethertype) /DEI (Ethertype) TCI / SID 2 Octets 4 Bits 12 Bits 2 Octets 4 Octets 6 Octets 6 Octets
Ethertype Ethertype Res1 UCA = 88-A8 = 88-E7 PCP DEI Res2 I-SID
3 Bits 1 Bit 1 Bit 1 Bit 2 Bits 24 Bits
Standard Ethernet Frame with I/B-Tag – 802.1ah-2008
Figure 7 – Standard Ethernet Frame with IEEE Std. 802.1ah-2008, with IB-BEB One-to-one S- tagged Interface Transformation.
Figure 8 depicts the scenario where the transformed frame includes a Provider Service Instance tag only. For a detailed description of the frame refer to IEEE Std. 802.1ah-2008, Clause 25.
29 of 100
Ver. 0.5 Standard Ethernet Frame
MAC Addresses MSDU
6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets
DA SA Type/ Payload FCS Length
------
B-DA B-SA I-Tag Type/ Payload FCS Length TPID/TCI/ C-DA C-SA SID 6 6 6 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets Octets
MAC Addresses MSDU
I-Tagged Ethernet Frame – 802.1ah-2008
Figure 8 – Standard Ethernet Frame with IEEE Std. 802.1ah-2008, with I-BEB One-to-one S- tagged Interface Transformation.
3.3.4. Carrier Ethernet Carrier Ethernet Standards are defined by the Metro Ethernet Forum (MEF). However, as described in subsection 3.1.3, the Service Attribute of the UNI defines whether the Service Type is dependent on IEEE defined VLAN tags to determine the routing of the Ethernet frame.
Carrier Ethernet provides two distinct service attribute identifications used at the UNIs defined as All-to-One Bundling (Port-based) and Service Multiplexed (VLAN-based) (see subsection 3.1.3 for more details). For Service Multiplexed service the UNIs rely on the VLAN tags for processing of the frame. The tags are referred to as Customer Edge tags (CE-Tag) and can be the C-Tag (subsection 3.3.1), and/or the S-Tag (or B-Tag as the tags share the same EtherType) (subsection 3.3.2).
As in the case of Provider Bridges, for securing the Ethernet data it is important that the Metropolitan Ethernet Network (MEN) be conceived as a single physical LAN or as a single bridge.
MENs can be configured to appear in two different ways to attached customer devices. An MEN can be made to act like a single physical LAN segment, or it can be made to act like a single monolithic bridge. In the first case, customer spanning trees treat the MEN like a single LAN segment, and the User Network Interface (UNI) equipment is basically not visible. In the second case, the set of all UNI devices belonging to the same VLAN act as if they are a single bridge; thus the MEN is visible in the customer spanning tree, but as a bridge rather than as a network.
30 of 100
Ver. 0.5 3.3.5. Data Center Bridging (DCB)
The Data Center Bridging (DCB) architecture is being developed to improve and expand Ethernet networking and management capabilities in the data center. DCB is a collection of open standards, amendments to the Ethernet Virtual Bridged LAN that is being worked on by the IEEE 802.1 working group. The standards are as follows:
IEEE Std. 802.1Qbb/D2.3-2010 (draft) for Priority-based Flow Control (PFC). IEEE Std. 802.1Qaz/D2.0-2010 (d raft) for Enhanced Transmission Selection (ETS) that enables bandwidth management between traffic types for multiprotocol links. The standard also includes the Data Center Bridging Exchange (DCBx) Protocol. IEEE Std. 802.1Qau/D2.4-2009 (d raft) details the Congestion Notification standards.
ESS authors are researching the use of the Pause frame as a simplified method of flow control and will address it for the next revision. DCB standards will be looked at in a later revision.
3.4. Supported Bandwidths
The standards specified in this specification were developed to support Ethernet data rates up to 100 Gbps (ref IEEE Std. 802.3ba-2010). Required and recommended algorithms and modes are in the process of being evaluated for faster speeds, such as 400 Gbps and higher (IEEE working group formed March 2011). As the need to support higher speeds becomes necessary, standards shall be updated and published.
3.5. Requirement Types
For consistency with existing expression of IEEE standards, the ESS shall use requirement terminology as follows:
shall: used for mandatory standards.
may: used to describe implementation or administrative choices.
should: used for recommended choices.
31 of 100
Ver. 0.5
4. Network Scenarios and Ethernet Security
The IEEE Standards body has documented the process to secure Ethernet communication in IEEE Std. 802.1AE-2006 – known as the MACsec Protocol. Inherent to establishing a secure network architecture with MACsec is the presence of an end-to-end MAC Service connection between encrypting peers, be it a single physical or virtual hop (see the appropriate subsections for definitions).
This section addresses various network scenarios, how the Ethernet frame is transformed with each scenario, special handling of the frame data for interoperation between an ESS and a MACsec implementation, how to incorporate into a network a standalone encryption device implementing the ESS, as well as interoperability between a standalone encryption device and a bridge that has built in the encryption functionality.
Many of the network scenarios addressed in ESS are not covered in IEEE Std. 802.1AE-2006 because the standards addressing them did not exist in 2006, as for example the PBBN standard IEEE Std. 802.1ah-2008. IEEE Std. 802.1X-2010 fills in some gaps, but still does not address MACsec use over MEN or PBBN. In addition, for those cases that are covered, ESS addresses how the scenario can be met with a standalone encryption device and still be interoperable with a MACsec implementation.
Because of the ‗standalone‘ nature of the NSS EDE device, the ESS has additional goals that are as follows and that will be addressed with each network scenario.
Interoperability with existing commercial standards. Interoperability between a standalone NSS EDE device and a bridge incorporating encryption functionality. Earmarking scenarios that are inoperable or not recommended due to frame manipulation and/or connectivity issues.
IEEE Std. 802.1AE-2006 Clause 11 provides a description of how to format the protected data to ensure the transport of the frame over different network topologies. Part of this process includes the addition of a security tag (SecTAG) to the Ethernet frame. Figure 9 depicts the layout of the SecTAG and its fields. For a general description of the tag fields see IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
32 of 100
Ver. 0.5 SecTAGField
MACsec TCI / SL PN Secure Channel Identifier (SCI) Ethertype AN 2 1 1 4 8 Octets Octet Octet
System Identifier Port Ethertype Number = 88-E5 6 2 Octets Octets V=0 ES SC SCB E C AN SCI Field
1 1 1 1 1 1 2 Bit Bit Bit Bit Bit Bit Bits TCI/AN Field
Figure 9- MACsec Security Tag - SecTAG, IEEE Std. 802.1AE-2006. The placement of the SecTAG in an Ethernet frame varies depending where in the communication path the frame is transformed. Details will be provided in each of the following subsections.
IEEE Std. 802.1AE-2006 depicts the transformation where the MAC Security Entity is an integral part of the frame processing. In the case of the ESS, security processing is performed outside of the normal frame handling, creating a unique implementation of the security transformation, such as the ICV calculation and handling of VLAN tags – see subsection 5.1.1.2 for a detailed explanation. Another consideration for ESS is the architectural topology following the transformation must be taken into account to ensure that the frame will reach its final destination.
The following sections depict how the ESS is implemented for various network scenarios. Most of the scenarios are derived from the general Use Cases portrayed in subsection 3.1. The remaining scenarios are provided for completeness and will be identified as such.
Various figure types are provided to depict each network scenario. These figures include:
Frame Transformation - The frame transformation figure depicts the Ethernet frame before any security processing (above the dashed line) and then as the frame appears after the security transformation has completed (below the dashed line). In some cases a third level is provided depicting the frame after further processing in the network path. Network Topology - The network topology diagrams depict the various devices included in the topology, interconnections, and placement of the NSS EDE device.
33 of 100
Ver. 0.5 Internal Organization / Service Interface - The internal organization / service interface diagrams are similar to the network topology diagrams except that they include the protocols / standards used and their placement within the topology. Internal Stack - The internal stack diagram shows the order of execution of each standard /protocol within a system.
4.1. Single Physical Hop
The scope of encryption in a single physical hop is between direct peers (end stations or bridges of any kind) connected by a single physical media link. More specifically, it is a set of peers belonging to a single collision domain. The only intervening devices that can exist in a single physical hop are hubs and repeaters. Any tags included in the frame are encrypted with the payload.
In order to describe the ESS handling of the Ethernet frame in a single physical hop scenario this section is further divided into the type of peers as this determines the original format of the Ethernet frame to be secured. The types of peers addressed are:
Between end stations or VLAN-unaware bridges – untagged standard Ethernet frame. Between Provider Bridges – S-Tagged standard Ethernet frame. Between Provider Backbone Bridges – I/B-tagged standard Ethernet frame.
NOTE: The network scenarios described in the following subsections have not been identified in NSS user Use Cases but are included here for completeness.
4.1.1. Single Physical Hop between End Stations or VLAN- unaware Bridges
IEEE Std. 802.3-2008 defines the standard for Ethernet communication between End Stations. IEEE Std. 802.1D-2004 defines the standard for Ethernet communication between MAC Bridges. The Ethernet frame layout is common to these two standards and is described in subsection 3.2.
Figure 10 depicts the security transformation of a standard Ethernet frame for transmittal. For Security Tag (SecTAG) details see Figure 9. The transformation of the frame is described in detail in IEEE Std. 802.1AE-2006 Clauses 8, 9, and 10. The ICV calculation is defined in IEEE Std. 802.1AE-2006 Clause 8.3. On receipt, the frame is verified using the Integrity Check Value (ICV), and the frame transformation is reversed.
NOTE: MACsec allows 8 byte SecTAGs for point-to-point connections where the SCI is omitted. For ESS, the SCI shall always be included in the SecTAG making the field a consistent length of 16 bytes.
34 of 100
Ver. 0.5 Standard Ethernet Frame MAC Addresses MSDU
6 6 2 46 to 1500 4
DA SA Type/ Payload FCS Length ------
DA SA SecTAG Secure Data Integrity FCS Check Value (ICV)
16 16
MPDU – MACSec Protocol Data Unit Standard Ethernet Frame with MACSec Security Tag NOTE: Field sizes in Octets Figure 10- Standard Ethernet Frame Transformation with MACsec, IEEE Std. 802.1AE-2006.
For the transformation depicted in Figure 10 to occur, the NSS EDE device peers would need to be placed as depicted in Figure 11. The Customer System could be a User end station and the frame transformation would be the same.
Customer System Customer System VLAN Unaware Bridge VLAN Unaware Bridge
LLC LLC
ISS ISS
802.1D NSS EDE NSS EDE 802.1D Device Device
MAC MAC
LAN Single Physical Hop LAN
Figure 11 - NSS EDE Device Peers Following a MAC Bridge (IEEE Std. 802.1D-2004) – Single Physical Hop.
An NSS EDE device peer placed in this scenario will interoperate with a peer bridge incorporating standardized MACsec functionality. The following figure depicts this scenario 35 of 100
Ver. 0.5 between an NSS EDE device and a MACsec peer.
Customer System Customer System VLAN Unaware Bridge VLAN Unaware Bridge
LLC LLC
802.1AE
ISS NSS EDE ISS Device 802.1D 802.1D
MAC MAC
LAN LAN
Figure 12 – NSS EDE Device and MACsec Implementation Peerage Between VLAN-unaware Bridges, IEEE Std. 802.1D-2004, Single Physical Hop.
4.1.2. Single Physical Hop between Provider Bridges
A single physical hop transformation between Provider Bridges involves Service tagged Ethernet frames containing a VLAN tag commonly referred to as an S-Tag. Subsection 3.3.2 provides a brief description of the Provider Bridge Ethernet frame – for more detail on the frame and standard see IEEE Std. 802.1ad-2005.
In order to secure Ethernet traffic on a single physical hop between Provider Bridges, an NSS EDE device needs the Ethernet frame transformation as depicted in Figure 13. The security transformation depicts an S-Tagged Ethernet frame followed by an S-Tagged Ethernet frame with a Security Tag (SecTAG). For this transformation the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3. IEEE Std. 802.1AE-2006 describes the general security transformation in Clauses 8, 9, 10 and 11. IEEE Std. 802.1AE-2006 Clause 11.4 deals specifically with VLAN tagged Ethernet frames.
The SecTAG field is the same as that portrayed in Figure 9, and the tag fields are described in IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
36 of 100
Ver. 0.5 Standard Ethernet Frame with S-Tag, 802.1ad-2005
MAC Addresses MSDU
6 6 4 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets
DA SA S-Tag Prefix Type/ Payload FCS Length ------
DA SA SecTAG Secure Data ICV FCS (including S-Tag Prefix, Type/ Length and Payload)
MPDU
S-Tagged Ethernet Frame with MACsec Security Tag
Figure 13- S-Tagged Ethernet Frame Transformed by MACsec, IEEE Std. 802.1AE-2006. Figure 14 portrays the location of the NSS EDE device peers in relation to the Provider Bridge peers providing Ethernet security in a single physical hop.
Customer Customer System System LLC S-VLAN Bridge LLC LLC S-VLAN Bridge LLC MAC Relay MAC Relay Entity EISS EISS Entity
802.1ad 802.1ad
ISS ISS NSS EDE NSS EDE ISS ISS Device Device 802.1D 802.1D 802.1D 802.1D
MAC MAC MAC MAC MAC MAC
Customer Provider Provider Customer Network Port Network Port Network Port Network Port
LAN LAN Single Physical Hop LAN LAN
Figure 14 – NSS EDE Device Peers Between Provider Bridges – IEEE Std. 802.1ad-2005, Single Physical Hop.
An NSS EDE device peer will interoperate with the standardized MACsec protocol peer implementation. The following figure depicts this scenario between an NSS EDE device and a MACsec peer.
37 of 100
Ver. 0.5
Customer Customer System System LLC S-VLAN Bridge LLC LLC S-VLAN Bridge LLC MAC Relay MAC Relay Entity EISS EISS Entity 802.1AE 802.1ad
ISS ISS NSS EDE 802.1ad ISS Device ISS 802.1D 802.1D 802.1D 802.1D MAC MAC MAC MAC MAC MAC
Customer Provider Provider Customer Network Port Network Port Network Port Network Port
LAN LAN LAN LAN
Figure 15 – NSS EDE Device with a Provider Bridge Network Port-based Service Interface MACsec Peer Instantiation, IEEE Std. 802.1ad-2005, Single Physical Hop.
4.1.3. Single Physical Hop between Provider Backbone Bridges
A single physical hop transformation between Provider Backbone Bridges involves a Backbone Service Instance and Backbone VLAN tagged Ethernet frames containing VLAN tags commonly referred to as I-Tag and B-Tag. Subsection 3.3.3 provides a brief description of the Ethernet frame from a Provider Backbone Bridge – for more detail on the frame and standard see IEEE Std. 802.1ah-2008.
In order to secure Ethernet traffic on a single physical hop between Provider Backbone Bridges, an NSS EDE device shall implement the Ethernet frame transformation as depicted in Figure 16. The frame security transformation depicts an I/B-Tagged Ethernet frame followed by an I/B- Tagged Ethernet frame with a Security Tag (SecTAG) transformation. For this transformation the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3. IEEE Std. 802.1AE-2006 describes the general security transformation in Clauses 8, 9, 10 and 11. IEEE Std. 802.1AE-2006 Clause 11.4 deals specifically with VLAN tagged Ethernet frames.
The SecTAG field is the same as that portrayed in Figure 9, and the tag fields are described in IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
38 of 100
Ver. 0.5 Standard Ethernet Frame with I/B Tag – 802.1ah-2008
MAC Addresses MSDU
6 6 4 6 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets Octets Octets
B-DA B-SA B-Tag I-Tag Type/ Payload FCS Length TPID/TCI C-DA C-SA /SID ------
B-DA B-SA SecTAG Secure Data ICV FCS (including B-Tag, I-Tag, Type/Length, Payload)
MPDU
I/B-Tagged Ethernet Frame with MACsec Security Tag
Figure 16- I/B Tagged Ethernet Frame – IEEE Std. 802.1ah-2008, Followed by MACsec Transformation – IEEE Std. 802.1AE-2006 For a Single Physical Hop Topology. Figure 17 portrays the location of the NSS EDE device peers securing Ethernet traffic in a single physical hop in a Provider Backbone Bridge Network between the Backbone Edge Bridge and the Backbone Core Bridge.
Customer System Customer System / Bridge / Bridge Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge LLC LLC
LLC I-Comp LLC B-Comp B-VLAN Bridge B-Comp LLC I-Comp LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS (If PBB) MAC Relay MAC Relay MAC Relay (If PBB) Entity Entity Entity EISS EISS EISS EISS EISS EISS NSS EDE ISS Device ISS (If PB) ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS (If PB) Peers
Customer Provider Customer Provider Provider Provider Customer Provider Customer Network Instance Backbone Network Network Network Backbone Instance Network Port Port Port Port Ports Port Port Port Port
LAN Internal LAN LAN LAN LAN LAN Internal LAN LAN
Figure 17 – NSS EDE Device Peers Between Provider Backbone Edge Bridges – IEEE Std. 802.1ah-2008, Single Physical Hop.
Usage of an NSS EDE device peer meets the ESS security goal of interoperability with a peer implementation of the existing standard IEEE Std. 802.1AE-2006. In addition, this scenario provides for MAC source and destination address anonymity.
39 of 100
Ver. 0.5 4.2. Single Virtual Hop
The definition of a single virtual hop in the context of the ESS is derived from multiple sources from the IEEE standards and MEF Specifications as follows:
1. IEEE Std. 802.1AE-2006 explicitly distinguishes between the definition of ―LAN‖ and ―Bridged Local Area Network‖. In particular, ―The term… LAN [is] used exclusively to refer to an individual LAN…without the inclusion of Bridges‖, Note following Clause 3.3. 2. IEEE Std. 802.1AE-2006 Clause 6 begins: ―MACsec provides secure communications between stations that are attached to the same LAN.‖ 3. Bridges are transparent to end stations, but not to other bridges. The restriction of MACsec to use over a single LAN can be relaxed only when the network between MACsec stations handles both incoming bridge frames and customer frames equivalently to a single LAN. This is hinted in IEEE Std. 802.1AE-2006 Clause 7.3.2 NOTE 1, where it says ―a Provider Bridged Network appears to Customer Bridges as a single LAN providing full connectivity independent of the operation of Customer Bridge protocols.‖ 4. A key element for distinguishing between a network that constitutes a virtual LAN for IEEE Std. 802.1AE-2006 purposes versus a network that constitutes a Bridged LAN is how the network treats customer frames carrying the Bridge Group Address (established in IEEE Std. 802.1Q-2005). Clause 8.13.5 of IEEE Std. 802.1Q-2005 and updated by IEEE Std. 802.1ad-2005 states ―frames with this destination address both reach all peer protocol entities attached to the same LAN and do not reach protocol entities attached to other LANs. The Bridge Group Address is therefore… always filtered by Customer Bridges and C-VLAN components of Provider Edge Bridges.‖ So the set of peers shall be the stations that are served by an insecure MAC service that are eligible to participate in MACsec are the stations that are mutually reachable using the Bridge Group Address. The ESS may be excluding true end stations this way, but the ESS has not identified any end-station to end-station Use Cases and so will not address it in this first iteration of the specification. 5. IEEE Std. 802.1ad-2005 Clause 16.3 states ―Frames received by Customer Network Ports and addressed to the Bridge Group Address are subject to service instance selection and relay in the same way as customer data frames.‖ There is an equivalent statement in IEEE Std. 802.1ah-2008 Clause 25.7. In both cases, a new group address is required for Provider Bridges, so that their protocol frames stay restricted to single LANs. 6. MENs can qualify as a virtual LAN for the ESS purposes when configured to tunnel layer 2 control protocols (Ref MEF 10.2, section 6.5.1.4 footnote 4, and section 6.7). MEF 10.2 Section 7.1.3 defines the different processing options the UNI has for layer 2 control frames. The option ―Pass to EVC‖ delegates responsibility to the EVC that in turn can be set to ―Tunnel‖ and so be compatible with the ESS. Otherwise, there is no provision at a UNI to interact with network elements inside the provider network (other than CoS and DEI). With the above mentioned configuration, a frame presented to a UNI customer port carrying the Bridge Group Address is delivered to all other UNIs in the same EVC, just as if they were connected by a single physical LAN. 7. The MKA frames are required to use the bridge group address, and so that limits the placement of MACsec peers in a LAN architecture.
40 of 100
Ver. 0.5 8. The definition/derivation above is not based on tagging. However, tags are taken into consideration if more than one virtual LAN is accessible at the same network customer port.
A single virtual hop is allowed in the following architectural scenarios: Across an MEN Across a PBN Across a PBBN
In contrast, a C-VLAN does not constitute a single virtual hop. A C-VLAN is a subset of a LAN that may include bridges in that LAN. Frames addressed to the bridge group address (a feature used by MKA) have no guarantee of reaching all end-stations of a C-VLAN, the way they do of reaching all Customer Equipment connected to an MEN (when the MEN is configured as described herein), or of reaching all edge bridges of a PBN or PBBN.
In each of the following subsections, consideration must be taken to ensure interoperability with existing standards. Diagrams will be provided for clarity as needed.
4.2.1. Single Virtual Hop through a Metro Ethernet Network (MEN)
As of the release of this specification, the Metro Ethernet Forum (MEF) has not identified Ethernet Security within their scope of interest. Review of the MEF specification for an Ethernet Virtual Connection (EVC), shows that there is no guarantee that the provider side of the User Network Interface (UNI) will be Ethernet. So for purposes of the ESS, the scope of encryption is between the UNIs defining the EVC. In other words, all Ethernet security is outside the realm of the UNI, so all security processing is required on the Customer side of the connection.
In order to satisfy the ESS Single Virtual Hop requirement, a network administrator would need to configure an MEN to tunnel layer 2 control protocols. As defined in MEF 10.2 Section 7.1.3, the UNI is set to ―Pass to EVC‖ and in turn the EVC is set to ―tunnel‖.
The ESS handling of Ethernet frames varies depending on the service identification used at the UNI and the frame data used by the MEN. The ESS handling is different for Port-based (All to One Bundling) vs. VLAN-Based service (Service Multiplexed) as explained in the following subsections.
4.2.1.1. Port-based Ethernet Service UNI
All-to-One Bundling is a UNI attribute in which all VLAN IDs are associated with a single EVC. Ethernet services using All-to-One Bundling UNIs are referred to as Port-based or ‗Private‘ – see MEF 6.1 for further detail. For purposes of the ESS, this represents the case where all tags are encrypted and the CoS is derived from the EVC.
41 of 100
Ver. 0.5 Depending if the Customer Edge (CE) is represented by an end-station, VLAN-unaware bridge, PBN, or PBBN, an NSS EDE device developer would need to implement the Ethernet frame transformation at the Ethernet Encryption device as depicted in Figure 10, Figure 13 and Figure 16.
An NSS EDE device between a CE and its UNI will interoperate with a remote CE implementing IEEE Std. 802.1AE-2006. The PBBN scenario provides for customer source and destination MAC address anonymity.
The following figure, Figure 18, shows the Ethernet encryption device Peers in relation to an EPL MEN service. Here the NSS EDE device would be placed between the Customer Edge (CE) and the MEN UNI. In this scenario all VLAN tags shall be encrypted with the user data.
Metro Ethernet Network NSS EDE NSS EDE CE Device Device CE UNI EPL UNI
EVC
Figure 18 - Metro Ethernet Network – NSS EDE Device Peers for an EPL. In the case of an Ethernet Private LAN (EP-LAN) (Port-Based E-LAN Service Type) or an Ethernet Private Tree (EP-Tree) (Port-Based E-Tree Service Type) the Ethernet Encryption device Peers relation would not change from that portrayed in Figure 18. The difference would be internal to the MEN and is out of scope of the ESS - for details refer to MEF 6.1 and 10.2.
4.2.1.2. VLAN-Based Service and Bundling Service
VLAN-Based Service is defined as a UNI service attribute in which the UNI can be in more than one EVC instance. VLAN-Based Service is also referred to as Service Multiplexed and as ‗Virtual Private‘ – see MEF 6.1. The Bundling Service is a UNI attribute where more than one CE-VLAN ID can be associated with an EVC – see MEF 10.2 Section 7.9.
In order to support both of these service types, the NSS EDE device developer needs to leave tag(s) exposed. Depending on the system topology before the UNI connection the NSS EDE device peers will need to transform the Ethernet frame differently.
42 of 100
Ver. 0.5 In the case where the CE is a VLAN-aware Bridge (IEEE Std. 802.1Q-2005), the C-Tag would need to bypass encryption as shown in Figure 19. This particular use case scenario is not recommended for NSS user for multiple reasons:
This scenario is inoperable since a Customer VLAN aware bridge to Customer VLAN aware bridge does not qualify as a ―single LAN‖ connection as described in subsections 3.3.1 and 4.2. Should the peer encryption device be built into the customer equipment as defined in IEEE Std. 802.1AE-2006 Clause 11.4 and IEEE Std. 802.1X-2010 – the frame transformations would not allow the devices supporting the security protocol to interoperate, as MACsec would encrypt a Tag if present in the frame – see Figure 20. Since the frame transformation would be different, the input used to compute the ICV would differ from that expected in IEEE Std. 802.1AE-2006 Clause 8.3.
Standard Ethernet Frame with C-Tag, 802.1Q-2005
MAC Addresses MSDU
6 6 4 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets
DA SA C-Tag Prefix Type/ Payload FCS Length ------
DA SA C-Tag SecTAG Secure Data ICV FCS Prefix (including Type/ Length and Payload)
MPDU
C-Tagged Ethernet Frame with MACsec Security Tag
Figure 19 – Standard Ethernet Frame with C-Tag, IEEE Std. 802.1Q-2005; Followed by the ESS Transformation with C-Tag Encryption Bypass.
43 of 100
Ver. 0.5
Customer System Customer System VLAN aware Bridge VLAN aware Bridge
LLC LLC MAC Relay MAC Relay Entity EISS EISS Entity 802.1Q 802.1Q 802.1AE Metro Ethernet ISS MACsec Network NSS EDE ISS Device 802.1D 802.1D MAC MAC UNI UNI
LAN
EVC Figure 20 – MACsec Capable VLAN Aware MAC Bridge with NSS EDE Device Peer Communicating over MEN.
In the case where the CE is a Provider Bridge Network (IEEE Std. 802.1ad-2005), the Ethernet frame transformation implemented by the NSS EDE device developer would be similar except that the S-Tag is not encrypted; see Figure 21.
Standard Ethernet Frame with optional C-Tag, 802.1Q-2005 and PB S-Tag, 802.1ad-2005 MAC Addresses MSDU
6 6 4 4 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets
DA SA S-Tag C-Tag Type/ Payload FCS Prefix Prefix (opt) Length ------
DA SA S-Tag SecTAG Secure Data ICV FCS Prefix (including C-Tag Prefix (opt), Type/ Length and Payload)
MPDU C-Tagged and S-Tagged Ethernet Frame with MACsec Transformation 802.1AE-2006
Figure 21 – Standard Ethernet Frame with (Optional) C-Tag and S-Tag Transformation Followed by the ESS / MACsec Transformation.
For the above transformation to be feasible in ESS, the ESS interface stack defined by the NSS EDE device developer would be as depicted in Figure 22. SecY and KaY would only be instantiated after the ‗802.1Q Bridge Port connectivity‘ instantiation and not after the ‗802.1ad S- 44 of 100
Ver. 0.5 Tagging‘ instantiation. The ICV computation in the NSS EDE device would need to be unique for this scenario where the S-Tag would not be included in the data used to compute the ICV. For details refer to IEEE Std. 802.1AE-2006 Clause 11.7 and IEEE Std. 802.1X-2010 Clause 7.7 and following sub-clauses.
An NSS EDE device between a CE and its UNI will interoperate with a remote CE implementing IEEE Std. 802.1AE-2006 with an internal stack as depicted in Figure 22.
Higher Layer MKA to other Customer Bridges attached to PBN Entities PAE MAC Relay Entity LLC MKA to Provider’s S-VLAN aware Bridge PAE EISS 802.1Q C-Tagging LLC (opt) ISS ISS
LLC 802.1Q Bridge Port connectivity ISS Secure ISS MACsec across provider’s network MACsec – SecY & KaY
Secure ISS 802.1ad S-Tagging
ISS PAC
LAN MAC
Figure 22 – MACsec Interface Stack with C-Tagging (Optional), MACsec, and S-Tagging.
When the CE is a Provider Backbone edge bridge (IEEE Std. 802.1ah-2008), the NSS EDE device shall leave exposed the B-DA, B-SA, and the B-Tag, encrypting all other tags with the payload as depicted in Figure 23. (NOTE: The B-Tag and S-Tag share the same EtherType; see IEEE Std. 802.1 ah-2008, sub-clause 9.7, Table 9-1.) For this transformation the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3.
45 of 100
Ver. 0.5 Standard Ethernet Frame with I/B Tag – 802.1ah-2008
MAC Addresses MSDU
6 6 4 6 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets Octets Octets
B-DA B-SA B-Tag I-Tag Type/ Payload FCS Length TPID/TCI C-DA C-SA /SID ------
B-DA B-SA B-Tag SecTAG Secure Data ICV FCS (including, I-Tag, Type/Length, Payload)
MPDU
I/B-Tagged Ethernet Frame with MACsec Security Tag
Figure 23 – I/B Tagged Ethernet Frame – IEEE Std. 802.1ah-2008 Followed by the ESS Transformation For a Single Virtual Hop Topology Traversing MEF VLAN-Based or Bundling Service UNIs.
This scenario is recommended for NSS users as it meets the additional ESS security goal of interoperability where an NSS EDE device between a CE and its UNI will interoperate with a remote CE implementing IEEE Std. 802.1AE-2006. The scenario provides customer source and destination MAC address anonymity.
Figure 24 depicts the Ethernet encryption device peers for an MEN EVP-LAN service type. A CE can be any of the VLAN-aware Ethernet Bridges as defined in IEEE Std. 802.1Q-2005, IEEE Std. 802.1ad-2005, and IEEE Std. 802.1ah-2008. For a definition of an Ethernet Virtual Private LAN Service see MEF 6.1 Section 7.4.
46 of 100
Ver. 0.5 Figure 24 – MEN Topology of an EVP-LAN.
4.2.2. Single Virtual Hop in the Provider Bridged Network
IEEE Std. 802.1AE-2006 Clause 11.7 defines MACsec in Provider Bridged Networks. In a single virtual hop Provider Bridged Network (PBN) the scope of encryption is between peer Provider Edge Bridges. The ESS handling shall vary depending on where encryption is performed. This can be defined as encryption in the bridge, encryption on the customer side of the Provider Edge Bridge, or encryption on the network side of the Provider Edge Bridge. Details are provided in the following subsections.
4.2.2.1. Encryption in the Provider Bridge
Encryption in the Provider Bridge is fully defined in IEEE Std. 802.1AE-2006 Clause 11.7 and IEEE Std. 802.1X-2010 Clause 7. An NSS EDE device needs to implement the Ethernet Frame transformation as depicted in Figure 25. In this case a C-Tag (if present) is encrypted and the S- Tag is left exposed. For this transformation the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3, where the S-Tag is not part of the data included for the ICV calculation. In this case, for MACsec, the S-VLAN is a sub-layer of the insecure MAC service supporting the SecY common port, and hence not visible to the SecY. The SecTAG field is the same as that portrayed in Figure 9, and the tag fields are described in IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
An NSS EDE device peer can interoperate with a MACsec peer implementation where the ESS internal stack is implemented as depicted in Figure 22.
Standard Ethernet Frame with optional C-Tag, 802.1Q-2005 and PB S-Tag, 802.1ad-2005 MAC Addresses MSDU
6 6 4 4 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets
DA SA S-Tag C-Tag Type/ Payload FCS Prefix Prefix (opt) Length ------
DA SA S-Tag SecTAG Secure Data ICV FCS Prefix (including C-Tag Prefix (opt), Type/ Length and Payload)
MPDU C-Tagged and S-Tagged Ethernet Frame with MACsec Transformation 802.1AE-2006
Figure 25 - Standard Ethernet Frame with C-Tag (Optional) And S-Tag Transformation Followed by MACsec Transformation.
47 of 100
Ver. 0.5
4.2.2.2. Encryption on the Customer Side of a Provider Edge Bridge for a Single Virtual Hop
As stated in IEEE Std. 802.1ad-2005, a service provider can offer different types of customer service interfaces (Clause 15.2 through Clause 15.5). The service types are Port-based service interface and service-multiplexed interface. The ESS handling on a customer side of the Provider Edge Bridge is affected by the service type interface selected, as defined in the following subsections.
NOTE: Both scenarios in this section are impossible for MKA to support. EAPoL (including MKA) frames are addressed to the bridge group address. The Edge bridges that are on the black side of the MACsec device will filter those frames, making MKA impossible to operate between the peers in Figure 27 and Figure 29. If these are an expected use cases then ESS will need to resolve in a future revision.
4.2.2.2.1. Port-based Interface Encryption on the Customer Side of a Provider Edge Bridge for a Single Virtual Hop
Port-based interface is described in IEEE Std. 802.1ad-2005. This interface type associates all customer frames with a single service instance that is specified by reference to a Customer Network Port provided by the S-VLAN component of a Provider Bridge. As stated in Clause 15.3, ―Frames transmitted to a Customer Network Port by a C-VLAN aware customer system do not include an S-VID, but can be priority-tagged with an S-Tag‖. In this case, the S-Tag is optional. An NSS EDE device developer would need to implement the Ethernet Tagged Frame transformation as depicted in Figure 26. For the frame with an optional C-Tag, the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3. For a frame with an S-Tag the ICV computation in the NSS EDE device would need to be unique for this scenario where the S-Tag would not be included in the data used to compute the ICV (see Figure 22 and accompanying figure explanation).
The SecTAG field is the same as that portrayed in Figure 9, and the tag fields are described in IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
48 of 100
Ver. 0.5 Standard Ethernet Frame with optional C-Tag, 802.1Q-2005 and optional S-Tag, 802.1ad-2005
MAC Addresses MSDU
6 6 4 4 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets
DA SA S-Tag C-Tag Type/ Payload FCS Prefix (opt) Prefix (opt) Length ------
DA SA S-Tag SecTAG Secure Data ICV FCS Prefix (including C-Tag Prefix (opt), Type/ Length and Payload) (opt)
MPDU
C-Tagged and S-Tagged Ethernet Frame with MACsec Transformation 802.1AE-2006
Figure 26 – Standard Ethernet Frame with C-Tag (Optional) and S-Tag (Optional) Transformation Followed by MACsec Transformation. Figure 27 portrays the location of the NSS EDE device peers, in relation to the Customer Network Port, the Customer Edge and the Provider Edge Bridge, securing Ethernet traffic in a single virtual hop.
Customer Customer System System LLC S-VLAN Bridge LLC LLC S-VLAN Bridge LLC Bridge, Bridge, MAC Relay MAC Relay Router or Router or Entity EISS EISS Entity End End Station Station 802.1ad 802.1ad
NSS EDE ISS ISS ISS ISS NSS EDE Device Device 802.1D 802.1D 802.1D 802.1D
MAC MAC MAC MAC MAC MAC
Customer Network Port Network Port Customer Network Port Network Port
LAN LAN LAN LAN PBN and/or MEN
Figure 27 – NSS EDE Device Peers at the Customer Edge and a Port-based Service Interface to a Provider Bridge Network – IEEE Std. 802.1ad-2005, Single Virtual Hop.
An NSS EDE device peer can interoperate with a MACsec peer instantiation at the Network Port Stack of the remote S-VLAN bridge if a solution is found that enables MKA to support the scenario (see NOTE in subsection 4.2.2.2). The following figure provides a graphical 49 of 100
Ver. 0.5 representation of the interoperability scenario.
Customer Customer System System LLC S-VLAN Bridge LLC LLC S-VLAN Bridge LLC Bridge, Bridge, MAC Relay MAC Relay Router or Router or Entity EISS EISS Entity End End Station Station 802.1ad
NSS EDE ISS ISS 802.1ad ISS Device ISS 802.1D 802.1D 802.1D 802.1D
MAC MAC MAC MAC MAC MAC
Customer Network Port Network Port Customer Network Port Network Port
LAN LAN LAN PBN and/or MEN
Figure 28 – NSS EDE Device at the Customer Edge and a Provider Bridge Network Port-based Service Interface MACsec peer instantiation, IEEE Std. 802.1ad-2005, Single Virtual Hop.
4.2.2.2.2. Service-Multiplexed Interface Encryption on the Customer Side of a Provider Edge Bridge for a Single Virtual Hop
Service-Multiplexed Interface is the collective name for Provider Bridge tagged customer service interfaces. The tagged services are divided into C-tagged and S-tagged service interfaces. IEEE Std. 802.1ad-2005 provides definitions for each in Clause 15.4 and Clause 15.5, respectively. The C-tagged service interface allows the attached customer to select between and identify service instances using the C-VID associated with transmitted and received frames. The S- tagged service interface allows the customer the same capability using the S-VID associated with the transmitted and received frames.
In the case of a Provider Bridge C-tagged Service Interface with the NSS EDE device placed at the Customer Edge, the NSS EDE device shall bypass the C-Tag in the Ethernet frame. Handling of the ICV would be different from IEEE Std. 802.1AE-2006. The transformation is the same as that depicted for MEN VLAN-Based Service and Bundling Service, Figure 19. The C-tagged Service Interface scenario is not recommended for NSS users as it does not meet the ESS Security goal of interoperability with existing standards.
In the case of a Provider Bridge S-tagged Service Interface with the ESS placed at the Customer Edge, the NSS EDE device shall transform the S-tagged Ethernet frame the same way as for Port-based Interface, subsection 4.2.2.2.1. The ICV computation in the NSS EDE device would need to be unique for this scenario where the S-Tag would not be included in the data used to
50 of 100
Ver. 0.5 compute the ICV (see Figure 22 and accompanying figure explanation).
An NSS EDE device peer will interoperate together with a MACsec peer implementation.
Figure 29 portrays the location of the NSS EDE device peers, in relation to the Customer Bridge, and the Provider Edge Bridge, securing Ethernet traffic in a single virtual hop.
Customer Bridge Customer Bridge
Provider Edge Bridge Provider Edge Bridge LLC LLC C-VLAN Comp S-VLAN Comp S-VLAN Comp C-VLAN Comp LLC LLC S-VLAN Bridge LLC LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS MAC Relay MAC Relay MAC Relay Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS
Customer Provider Customer Provider Provider Provider Customer Provider Customer Edge Edge Network Network Network Network Network Edge Edge Port Port Port Port Ports Port Port Port Port
LAN LAN Internal LAN LAN LAN Internal LAN LAN LAN
Figure 29 - C-tagged Service Interface of a PBN with NSS EDE Device Peers at Customer Side of Provider Edge Bridge.
4.2.2.3. Encryption on the network side of a Provider Edge Bridge for a Single Virtual Hop
In the case of a Provider Bridge S-tagged Service Interface with the NSS EDE device peers placed at the Provider Edge Bridge, the NSS EDE device shall transform the S-tagged Ethernet frame the same way as for Port-based Interface, subsection 4.2.2.2.1. The ICV computation in the NSS EDE device would need to be unique for this scenario where although the S-Tag is present in the red-side frames and visible to the SecY, it is not included in the data used to compute the ICV (see Figure 22 and the accompanying figure explanation). Figure 30 provides a topological depiction of the NSS EDE Device Peers on the network side of a Provider Edge Bridge. For this placement of the NSS EDE Device Peers there are no differences in frame transformation regardless of the customer service interface type (Port-Based, C-Tagged, or S- Tagged).
It should be noted that red-side frames having a bridge group destination address are encrypted and relayed by MACsec just like user frames. However, black-side frames having a bridge group destination address must be distinguished case by case: EAPoL (including MKA) frames are delivered to the local PAE; encrypted frames are delivered to the SecY for decryption and relay; other frames shall be handled according to subsection 5.3.4.
51 of 100
Ver. 0.5 An NSS EDE device peer will interoperate with a MACsec peer implementation where the peer MACsec bridge would be the provider network port stack of the S-VLAN component of the remote Provider Edge Bridge (see Figure 22 and the accompanying figure explanation for a description of the internal stack).
Customer Bridge Customer Bridge
Provider Edge Bridge Provider Edge Bridge LLC LLC C-VLAN Comp S-VLAN Comp S-VLAN Comp C-VLAN Comp LLC LLC S-VLAN Bridge LLC LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS MAC Relay MAC Relay MAC Relay Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS
Customer Provider Customer Provider Provider Provider Customer Provider Customer Edge Edge Network Network Network Network Network Edge Edge Port Port Port Port Ports Port Port Port Port
LAN Internal LAN LAN LAN LAN LAN Internal LAN LAN
Figure 30- Single Virtual Hop Topology for NSS EDE Device Peers at Provider Side of Provider Edge Bridge.
4.2.3. Single Virtual Hop for a PBBN
IEEE Std. 802.1X-2010 Clauses 7.7, 7.7.2 and 11.1.1, address MACsec in PBBN Systems. In a single virtual hop Provider Backbone Bridged Network (PBBN) the scope of encryption is between peer Provider Backbone Edge Bridges. The ESS handling will vary dependent on where encryption is performed. This can be defined as encryption in the bridge, encryption on the customer side of the Provider Backbone Edge Bridge, encryption between the I- and B- components, or encryption on the network side of the Provider Backbone Edge Bridge. Details are provided in the following subsections.
NOTE: Encryption on the customer side of a PBB Edge Bridge may not be possible, because the group addresses used in EAPoL (including MKA) may be filtered by the edge bridge. See Note in subsection 4.2.2.2 for details.
4.2.3.1. Single Virtual Hop Encryption in the Provider Backbone Bridge
Encryption in the Provider Backbone Bridge is defined in IEEE Std. 802.1X-2010 Clause 7.7.2. The NSS EDE device shall transform the Ethernet Frame as depicted in Figure 31. In this case all tag information, such as a C-Tag and/or S-Tag (if present) is/are encrypted and the Backbone 52 of 100
Ver. 0.5 addresses, Backbone tag and instance tag are left exposed. For this transformation the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3 where the exposed tags are included as part of the data used to compute the ICV. The B and I-Tag are exposed because the PBBN is a sub-layer of the insecure MAC service supporting the SecY common port, and hence not visible to the SecY.
The SecTAG field is the same as that portrayed in Figure 9, and the tag fields are described in IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
Standard Ethernet Frame with I/B Tag – 802.1ah-2008
MAC Addresses MSDU
6 6 4 6 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets Octets Octets
B-DA B-SA B-Tag I-Tag Type/ Payload FCS Length TPID/TCI C-DA C-SA /SID ------
B-DA B-SA B-Tag I-Tag SecTAG Secure Data ICV FCS (including Type/Length, Payload)
MPDU
I/B-Tagged Ethernet Frame with ESS Encryption
Figure 31 – I/B Tagged Ethernet Frame Transformation with Ethernet Encryption within a PBBN Bridge.
An NSS EDE device peer will interoperate with a MACsec peer implementation.
4.2.3.2. Encryption for a Single Virtual Hop on Customer Side of Provider Backbone Edge Bridge
Provider Backbone Edge Bridge Service is available as a Port-Based Interface and a Service- Multiplexed Interface as described in the following subsections.
4.2.3.2.1. Port-based Interface Encryption on the Customer Side of a Provider Backbone Edge Bridge for a Single Virtual Hop
53 of 100
Ver. 0.5 Port-based interface is described in IEEE Std. 802.1ah-2008, Clause 25.3. This interface type associates all customer frames with a single service instance that is specified by reference to a Customer Network Port provided by a BEB. A Port-based interface can attach to a C-VLAN Bridge, VLAN-unaware Bridge, router, or end-station. In this case, an NSS EDE device would be required to encrypt the customer tag with the payload as depicted in Figure 32. As the frame then traverses out of the Backbone Edge Bridge, the frame is encapsulated.
It is unclear if interoperability between an NSS EDE device peer with a standardized MACsec peer implementation would be feasible. IEEE Std. 802.1AE-2010 and IEEE Std. 802.1X-2010 are not specific about where the SecY would be instantiated in a Provider Backbone Edge Bridge. More than likely, the MACsec is embedded in the I-component above the entity that creates the I-Tag which would cause interoperability to be impossible. Thus rendering this scenario inoperable.
The SecTAG field is the same as that portrayed in Figure 9, and the tag fields are described in IEEE Std. 802.1AE-2006, Figure 9-1 and Clause 9.
Standard Ethernet Frame with optional C-Tag as seen at Customer Edge of PBBN
MAC Addresses MSDU
6 6 4 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets
DA SA C-Tag Prefix Type/ Payload FCS (optional) Length ------
DA SA SecTAG Secure Data ICV FCS (including opt C-Tag Prefix, Type/ Length and Payload)
MPDU C-Tagged Ethernet Frame with MACsec Security Tag ------B-DA B-SA B-Tag I-Tag SecTag Secure Data ICV FCS (including opt C-Tag Prefix, TPID/T C-DA C-SA Type/ Length and Payload) CI/SID
PBB encapsulation Original MPDU Source and Destination Addresses Ethernet Frame Secured at Customer Side as seen after PBB transformation
Figure 32 – Frame Transformation at Customer Side of PBBN Followed by PBB Encapsulation. Figure 33 depicts the topology of the NSS EDE device peers at the Customer Side in a PBBN Scenario.
54 of 100
Ver. 0.5 Customer System: VLAN Bridge, Customer System: VLAN Bridge, VLAN-unaware Bridge, Router, VLAN-unaware Bridge, Router, end-station end-station Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge LLC LLC
LLC I-Comp LLC B-Comp B-VLAN Bridge B-Comp LLC I-Comp LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS (If PBB) MAC Relay MAC Relay MAC Relay (If PBB) Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS (If PB) ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS (If PB)
Customer Provider Customer Provider Provider Provider Customer Provider Customer Network Instance Backbone Network Network Network Backbone Instance Network Port Port Port Port Ports Port Port Port Port
LAN LAN Internal LAN LAN LAN Internal LAN LAN LAN
Figure 33 – Port-Based Service Interface of a PBBN with NSS EDE Device Peers at Customer Side in a Single Virtual Hop Scenario.
NOTE: The Port-Based Interface scenario requires further analysis to determine the impact of group address filtering. Voluntary reviewer feedback is requested.
4.2.3.2.2. Service-Multiplexed Interface Encryption on the Customer Side of a Provider Backbone Edge Bridge for a Single Virtual Hop
Service-Multiplexed Interface is the collective name for Provider Backbone Bridge tagged customer service interfaces. The tagged services are divided into S-tagged and I-tagged service interfaces. IEEE Std. 802.1ah-2008 provides definitions for each in Clause 25.4 and Clause 25.5, respectively.
For an S-tagged service interface scenario, IEEE Std. 802.1AE-2010 and IEEE Std. 802.1X-2010 are not specific about where the SecY would be instantiated in a Provider Backbone Edge Bridge. More than likely, MACsec is embedded in the I-component above the entity that creates the I-Tag. If this is the case, there is no NSS EDE device implementation that could be developed to interoperate with a MACsec implementation.
The I-Tag Service Interface is a special case where a BEB B- or I- Component are controlled by the Customer System. As described in IEEE Std. 802.1ah-2008 Clause 25.5, the customer system includes the I-Tag, B-DA, and B-SA frame encapsulation; see Figure 34. Figure 35 depicts the topology of the Ethernet encryption device peers at the Customer BEB Side in a PBBN Scenario. For the ICV calculation, the I-tag is present in the red-side frame, but must be bypassed by the SecY and left out of the data used to calculate the ICV.
The I-Tagged service case can be defined as a special case of encryption between I- and B-
55 of 100
Ver. 0.5 components of a Provider Backbone Edge Bridge – subsection 4.2.3.3. In both cases, the NSS EDE device is inserted in an I-tagged service interface rather than a general-purpose MAC service interface. Here, it is an example of customer-side encryption from the standpoint of provider versus customer control/ownership of devices. However, with respect to the originating and terminating I-components, the encryption is on the backbone side, just as in subsection 4.2.3.3.
Use of an NSS EDE device in this scenario is the only customer side encryption PBBN scenario that meets the ESS objective of peer interoperability with a MACsec standard implementation as demonstrated/illustrated in Figure 36 - Internal Organization / Service Interface diagram, and Figure 37.
Standard Ethernet Frame with I-Tagged Service Interface Transformation – 802.1ah-2008 Customer BEB Customer MAC Addresses MAC Addresses MSDU
6 6 6 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets Octets
B-DA B-SA I-Tag Type/ Payload FCS Length TPID/TCI C-DA C-SA /SID ------
B-DA B-SA I-Tag SecTAG Secure Data ICV FCS (including Type/Length, Payload)
MPDU
I-Tagged Service Interface Ethernet Frame with ESS Encryption
Figure 34 – I-Tagged Service Interface Ethernet Frame Security Transformation at the Customer Side of the Customer BEB.
56 of 100
Ver. 0.5
Customer System: Customer Customer System: Customer Controlled BEB B-Comp or I- Controlled BEB B-Comp or I- Comp Comp Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge LLC LLC
B-Comp B-VLAN Bridge B-Comp
LLC LLC LLC LLC LLC LLC
MAC Relay MAC Relay MAC Relay Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS ISS ISS ISS ISS
Customer Backbone Customer Provider Provider Provider Customer Customer Backbone Port (BEB B-Comp) or Backbone Network Network Network Backbone Port (BEB B-Comp) or Provider Instance Port Port Port Ports Port Port Provider Instance Port (BEB I-Comp) (BEB I-Comp)
Figure 35 – I-Tagged Service Interface of a PBBN with NSS EDE Device Peers at Customer Controlled BEB Side Topology.
Customer System: Customer Customer System: Customer Controlled BEB B-Comp or I- Controlled BEB B-Comp or I- Comp w/MACsec Comp Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge LLC LLC
B-Comp B-VLAN Bridge B-Comp *1 See following LLC LLC LLC LLC LLC LLC Diagram for Interface Stack MAC Relay MAC Relay MAC Relay *1 Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS ISS ISS ISS ISS
Customer Backbone Customer Provider Provider Provider Customer Customer Backbone Port (BEB B-Comp) or Backbone Network Network Network Backbone Port (BEB B-Comp) or Provider Instance Port Port Port Ports Port Port Provider Instance Port (BEB I-Comp) (BEB I-Comp)
Figure 36 – I-Tagged Service Interface of a PBBN with MACsec and the NSS EDE Device Peers at Customer Controlled BEB Side.
57 of 100
Ver. 0.5
Higher Layer MKA to other Customer Bridges attached to PBN Entities PAE MAC Relay Entity LLC MKA to Provider’s S-VLAN aware Bridge PAE EISS 802.1Q C-Tagging LLC (opt) ISS ISS
LLC 802.1Q Bridge Port connectivity ISS Secure ISS MACsec across provider’s network MACsec – SecY & KaY
Secure ISS 802.1ad S-Tagging Secure ISS
802.1ah I-Tagging
ISS PAC
LAN MAC
Figure 37- Interface Stack with C-Tagging (Optional), MACsec, S-Tagging, and I-Tagging.
4.2.3.3. Encryption between I and B components of Provider Backbone Edge Bridge
IEEE Std. 802.1ah-2008 Clause 25 defines the Provider Backbone Edge Bridge (BEB) as comprised of two VLAN-aware bridge components, an I-component and a B-component connected together (as shown in Figure 33), or as comprised of two single VLAN-aware bridge components of different types .
The scenario addressed in this section is where the Provider BEB is comprised of two single VLAN-aware bridge components and the encryption device peers are placed between the I- and B-components. The NSS EDE device receives the Ethernet Frame with the PBBN I-Component MAC address encapsulation (backbone destination address and source address) and an I-Tag. It will encrypt the payload and leave the PBBN address information in plain text as shown in Figure 38. The figure also includes the continued frame manipulation after the frame exits the B-component. At the NSS EDE device, the I-Tag is present in the red-side frame, but must be bypassed by the SecY and is not part of the data included in the ICV computation. The I-Tag bypass will allow for interoperability with an IEEE Std. 802.1AE-2006 implementation.
58 of 100
Ver. 0.5
Ethernet Frame with I-component Transformation – 802.1ah-2008
BEB I-component Customer MAC Addresses MAC Addresses MSDU
6 6 6 6 6 2 46 to 1500 4 Octets Octets Octets Octets Octets Octets Octets Octets
B-DA B-SA I-Tag Type/ Payload FCS Length TPID/TCI C-DA C-SA /SID ------
B-DA B-SA I-Tag SecTAG Secure Data ICV FCS (including Type/Length, Payload)
MPDU Ethernet Frame with I-component Transformation with ESS Encryption ------
B-DA B-SA B-Tag I-Tag SecTAG Secure Data ICV FCS (including Type/Length, Payload)
Ethernet Frame with I-component Transformation with ESS Encryption after traversing B-component
Figure 38 – EDE Between I and B Components of Provider Edge Bridge. Figure Ethernet39 depicts the Encryptor topology of Peersthe NSS between EDE device I peersand betweenB components I- and B-components of the of a Provider Edge Bridge.Provider Backbone Edge Bridge in a PBBN
Customer Customer System System Backbone Edge Bridge Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge Backbone Edge Bridge LLC LLC
LLC I-Comp LLC B-Comp B-VLAN Bridge B-Comp LLC I-Comp LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS (If PBB) MAC Relay MAC Relay MAC Relay (If PBB) Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS (If PB) ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS (If PB)
Customer Provider Customer Provider Provider Provider Customer Provider Customer Network Instance Backbone Network Network Network Backbone Instance Network Port Port Port Port Ports Port Port Port Port
Figure 39 – NSS EDE Device Peers Between I and B Components of the Provider Backbone Edge Bridge in a PBBN. 59 of 100
Ver. 0.5 The interface stack in the I-Component by the Provider Instance Port is as depicted in Figure 37. This scenario meets the ESS objective of interoperability of a MACsec implementation peer and an NSS EDE device peer as shown in Figure 40.
Customer Customer System System Backbone Edge Bridge Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge Backbone Edge Bridge LLC LLC
LLC I-Comp LLC B-Comp B-VLAN Bridge B-Comp LLC I-Comp LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS (If PBB) MAC Relay MAC Relay MAC Relay (If PBB) Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS (If PB) ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS (If PB) SecY / KaY
Customer Provider Customer Provider Provider Provider Customer Provider Customer Network Instance Backbone Network Network Network Backbone Instance Network Port Port Port Port Ports Port Port Port Port
Figure 40 – MACsec and NSS EDE Device Peer Interoperability Between I- and B-Components of the Provider Backbone Edge Bridge in a PBBN.
4.2.3.4. Encryption on Provider side of B-component for a Single Virtual Hop in a PBBN
It is feasible that the encryption peers could be placed on the backbone side of an I-/B-BEB. In this case the received frame contains all customer address and tagging information as well as the MAC-in-MAC encapsulation.
Figure 41 depicts the topology where the encryption device peers are located on the Provider side of an I-/B-BEB. In the case of an NSS EDE device having a MACsec peer, the SecY and KaY instantiation would be built into the stack of the I-Component located before the Provider Interface Port (PIP). The interface stack would be the same as shown in Figure 37. The described topologies apply to the next two subsections.
60 of 100
Ver. 0.5 Customer System Customer System / Bridge / Bridge Backbone Edge Bridge Backbone Core Bridge Backbone Edge Bridge LLC LLC
LLC I-Comp LLC B-Comp B-VLAN Bridge B-Comp LLC I-Comp LLC
MAC Relay MAC Relay Entity LLC LLC LLC LLC LLC LLC Entity EISS EISS EISS EISS EISS EISS (If PBB) MAC Relay MAC Relay MAC Relay (If PBB) Entity Entity Entity EISS EISS EISS EISS EISS EISS
ISS ISS (If PB) ISS ISS ISS ISS ISS ISS ISS ISS ISS ISS (If PB)
Customer Provider Customer Provider Provider Provider Customer Provider Customer Network Instance Backbone Network Network Network Backbone Instance Network Port Port Port Port Ports Port Port Port Port
LAN Internal LAN LAN LAN LAN LAN Internal LAN LAN
Figure 41 – NSS EDE Peers at Provider Side of Provider Backbone Edge Bridge.
4.2.3.4.1. Bypass MAC-in-MAC encapsulation
In the case where the NSS EDE device is located at the provider side of the Backbone Edge Bridge and the expected provider topology is a PBBN, the NSS EDE device shall leave in plain text the MAC-in-MAC encapsulation (I-Tag). Figure 31 depicts the security frame transformation. At the NSS EDE device, the I-Tag is present in the red-side frame, but must be bypassed by the SecY and is not part of the data included in the ICV computation. The I-Tag bypass will allow for interoperability with an IEEE Std. 802.1AE-2006 implementation.
Combining an NSS EDE device peer with a MACsec peer implementation is interoperable as described in subsection 4.2.3.4.
4.2.3.4.2. I-Tag Encryption
The ESS frame handling at the provider side of a I/B BEB, where the I-Tag of the MAC-in-MAC encapsulation is encrypted with the Customer data, is practical for a single PBBN where no PBBN concatenation is required and when the PBBN interfaces with MEN – the NSS EDE device developer should refer to subsection 4.2.1.2 and Figure 23 for details on the frame transformation. For this transformation the ICV computation would follow that defined in IEEE Std. 802.1AE-2006 Clause 8.3.
Combining an NSS EDE device peer with a MACsec peer implementation is interoperable (see subsection 4.2.3.4 for a description); as well as providing customer source and destination MAC address anonymity.
61 of 100
Ver. 0.5 4.3. End Station to End Station across a Cloud
End station to end station across a cloud (bridged network) is outside the scope of the ESS as well as IEEE Std. 802.1AE-2006 and IEEE Std. 802.1X-2010. A major drawback is in key management. For example, the MACsec Key Agreement protocol (MKA) stipulates that the destination address for MACsec Key Agreement Protocol Data Units (MKPDUs) shall be certain group addresses that are only valid for one hop – ref IEEE Std. 802.1X-2010 Clauses 11.1.1 and 11.4.
4.4. Summary – Network Scenarios and Ethernet Security
The ESS Security goals are established to provide the CNSS a way to make use of public standards and the devices that conform to the public standards, and at the same time minimize risk. A device that implements MACsec, MACsec Key Exchange/Key Management in concert with the ESS goals can be incorporated into a multitude of scenarios each with varying levels of risk to the goal of interoperability.
Table 1 provides a summary of the network scenarios identified in the previous sections together with their compliance with the ESS goals and their operability status. There are many factors that will govern where the encryption peers are placed and the level of security that will be provided outside of that covered by MACsec (user data security). Some of these factors are:
The kind of network that is being architected. What equipment, such as routers, switches, etc, makes up the network, who owns the equipment, who manages the equipment, what is the customer edge vs. the provider edge, etc. What other security measures are provided.
In addition, Table 1 provides information on which network scenarios require a non-conformant ICV calculation for interoperability between a standalone device implementation and a conformant MACsec implementation.
ility ICV ICV MACsec MACsec Conformance Subsection Network Scenarios Interoperab 4.1 Single Physical Hop 4.1.1 Between End-Stations or VLAN- Y Y unaware Bridges 4.1.2 Between Provider Bridges Y Y 4.1.3 Between Provider Backbone Bridges Y Y 4.2.1 Single Virtual Hop – through MEN
62 of 100
Ver. 0.5
ility ICV ICV MACsec MACsec Conformance Subsection Network Scenarios Interoperab 4.2.1.1 Port-Based Ethernet Service UNI Y Y between End-Stations or VLAN- unaware Bridges. 4.2.1.1 Port-Based Ethernet Service UNI Y Y between Provider Bridges 4.2.1.1 Port-Based Ethernet Service UNI Y Y between Provider Backbone Bridges 4.2.1.2 Service-multiplexed UNI or Bundled N N EVCs – VLAN-aware Bridges (C-Tag) 4.2.1.2 Service-multiplexed UNI or Bundled Y N EVCs – PBN 4.2.1.2 Service-multiplexed UNI or Bundled Y Y EVCs – PBBN 4.2.2 Single Virtual Hop – in the PBN 4.2.2.1 Encryption in the Provider Bridge Y Y 4.2.2.2.1 Encryption on the customer side of the Y N Provider Edge Bridge – Port-based interface 4.2.2.2.2 Encryption on the customer side of the N N Provider Edge Bridge – Service- multiplexed interface encryption – C- Tagged service 4.2.2.2.2 Encryption on the customer side of the Y N Provider Edge Bridge – Service- multiplexed interface encryption – S- Tagged service 4.2.2.3 Encryption on the network side of a Y N Provider Edge Bridge 4.2.3 Single Virtual Hop – in the PBBN 4.2.3.1 Encryption in the Provider Backbone Y Y Bridge 4.2.3.2.1 Encryption on the customer side of N N Provider Backbone Edge Bridge – Port-based interface 4.2.3.2.2 Encryption on the customer side of N N Provider Backbone Edge Bridge – service-multiplexed S-Tagged Service 4.2.3.2.2 Encryption on the customer side of Y N provider backbone edge bridge – service-multiplexed I-Tagged Service 63 of 100
Ver. 0.5
ility ICV ICV MACsec MACsec Conformance Subsection Network Scenarios Interoperab 4.2.3.3 Encryption between I- and B- Y N components of Provider Backbone Edge Bridge 4.2.3.4.1 Encryption on the provider side of B- Y N Component in a PBBN – Bypass MAC-in-MAC encapsulation including I-Tag 4.2.3.4.2 Encryption on the provider side of B- Y Y Component in a PBBN – encrypt I-Tag and all customer information 4.3 End-Station to End-Station across a Cloud 4.3 End-Station to End-Station across a N N Cloud Table 1 – Summary of Network Scenarios and the ESS Security Goals and Recommendations.
64 of 100
Ver. 0.5
5. Security Specification
The ESS security objectives are to provide connectionless user data authenticity, confidentiality, and integrity, frame data integrity, replay protection, bounded receive delay, data origin authenticity, user authentication and user authorization; and can limit the nature and extent of denial of service attacks. MACsec does not support non-repudiation or protect against traffic analysis.
Ethernet Security requirements have been researched and documented by several working groups of the IEEE Standards body. To date the major publications are IEEE Std. 802.1AE-2006, IEEE Std. 802.1X-2010 and IEEE Std. 802.1AR-2009. IEEE Std. 802.1AE-2006 defines the MAC security (MACsec) standard. It allows authorized systems that attach to and interconnect LANs in a network to maintain confidentiality of transmitted data and mitigates against frames transmitted or modified by unauthorized devices. However, IEEE Std. 802.1AE-2006 does not specify how MACsec keys are managed, although it specifies criteria for what a key management strategy must address. The IEEE Std. 802.1X-2010 standard specifies port-based Network Access Control. This standard defines protocols and interfaces required to authenticate and authorize devices attached to a LAN to establish communication connections between each other. It also specifies a key management solution for IEEE Std. 802.1AE-2006 as part of integrating MACsec into the access control architecture to enforce access decisions. The IEEE Std. 802.1AR-2009 specifies Secure Device Identifiers (DevIDs) used by various protocols including IEEE Std. 802.1X-2010 to associate a device with an authentication credential. These publications are complemented by an array of other IEEE Standards and IETF RFCs that will be referenced in the text as needed.
Securing Ethernet can be broken down into several functions as follows: Ethernet Security – this function includes methods to protect the data with no impact to the delivery of the protected data, security services such as data integrity and replay protection, etc. Keying Architecture and Management – this function defines methods for peer discovery, keying, key derivation, re-keying. Ethernet Implementations – this function deals with various Ethernet issues such as flow control, ECMP, BFD, etc, not covered above. Ethernet Management – this function deals with multiple issues related to Ethernet Management including initialization, configuration management, Ethernet Operations, administration and Maintenance (OAM), Management Information Bases (MIBs), etc.
The following subsections address each function separately. 5.1. Ethernet Security
The Ethernet Security subsection is intended to complement, update, and complete IEEE Std. 802.1AE-2006 and IEEE Std. 802.1X-2010 – it is not a replacement. Several areas requiring attention have been identified and will be addressed in the following subsections: 65 of 100
Ver. 0.5
Cipher Suites Supported Logical SA Topologies Supported Encrypted Data Flow Topologies Additional Security Services
5.1.1. Cipher Suites
As stated in IEEE Std. 802.1AE-2006 ―A Cipher Suite is an interoperable specification of cryptographic algorithms together with the values of parameters (for example, key size) to be used by those algorithms‖. The ESS relies on several Cipher Suites to achieve its goals. The following subsections describe the Cipher Suites utilized by the MACsec protocol, the MACsec Key Agreement Protocol, the Extensible Authentication Protocol (EAP) and by the Internet Key Exchange version 2 (IKEv2).
NOTE: When using AES-256 for MACsec, all other cipher suites will require 256 as well.
5.1.1.1. MACsec Protocol Cipher Suites
The IEEE Standards body defines the use of two cipher suites in IEEE Std. 802.1AE-2006 Clause 14, IEEE Std. 802.1X-2010 Clauses 5.11, 6.2.1, 9.3.2 and 9.8.1, and P802.1AEbn/D08. MACsec Cipher Suites implementation is within the MAC Security Entity (SecY). IEEE specifies GCM-AES-128 as mandatory and GCM-AES-256 as optional. If the NSS EDE device is intended to be used to protect a NSS that contains TOP SECRET information, then it shall support GCM-AES-256. Cipher Suites are identified as defined in Table 2.
Cipher Cipher Cipher Suite Identifier Cipher Suite Key Length Type Suite Name MACsec AES-128 00-80-C2-00-01-00-00-01 GCM-AES-128 128 default MACsec AES-256 00-80-C2-00-01-00-00-02 GCM-AES-256 256 option Table 2- Cipher Suites.
NOTE: Cipher Suite Identifier for AES-128 has been corrected since IEEE Std. 802.1AE-2006 publication. In the chosen cipher suite, the AES block cipher in conjunction with the Galois/Counter Mode (GCM) provides assurance of both confidentiality of data and integrity of the confidential data and also for additional data that is not encrypted. Confidentiality is a service used to keep the content of information secret from all but those authorized to have it. Integrity is a service which provides strong assurance that data has not been altered, intentionally or unintentionally, by unauthorized or unknown means.
66 of 100
Ver. 0.5 In IEEE Std. 802.1AE-2006, the additional authenticated data (denoted as A – see Clause 14.5) comprises the fields of the plaintext (red) frame that must remain in plaintext in the encrypted (black) frame, and which have no reason to be modified in the intervening black network. For a SecY integrated into a bridge, the only fields meeting this criteria are the source and destination MAC addresses and the SecTag. Priority S-Tags can originate on the red side and must be bypassed by the SecY, but they may also be legitimately modified by the black network, so they are not included in the additional authenticated data. By the time a frame that has been encrypted to transit a virtual LAN segment (MEN, PBN, or PBBN) exits the MACsec bridge that encrypted it, there will be one or more additional plaintext VLAN tags in the frame. These are added by the Insecure MAC Service (i.e. after the SecY has encrypted the frame) and so cannot be included in the additional authenticated data.
For a SecY in a standalone device, conformance with IEEE Std. 802.1AE-2006 and interoperability with a SecY integrated into a bridge requires that the additional authenticated data comprises exactly the same fields. However, what the standalone SecY actually does sometimes has to be different from what the integrated SecY does, because the plaintext frames are not necessarily the same. When MACsec is applied to a virtual LAN segment, and a standalone SecY is positioned on the network side of the bridge that would otherwise have hosted the integrated SecY, then the VLAN tag identifying the Insecure MAC Service is already in the plaintext frame when relayed to the SecY controlled port. This is in contrast to the operation of an integrated MACsec bridge, in which the VLAN tag is inserted by the Insecure MAC Service after the frame has been encrypted by the SecY. Therefore, the standalone SecY has to recognize which VLAN tag in a plaintext frame corresponds to the CA to which the SecY belongs (i.e. which VLAN it is encrypting over), leave that and preceding VLAN tags, if present, (i.e. closer to the MAC addresses) in plaintext, and exclude those tags from the additional authenticated data.
NOTE: Some Government NSS EDE devices may not implement GCM-AES-128. NSS users will need to be aware of potential interoperability issues with commercial NSS EDE devices.
5.1.1.2. MACsec Key Agreement (MKA) Cipher Suites
IEEE Std. 802.1X-2010 defines the MACsec Key Agreement (MKA) as one of three functions that a Port Access Entity (PAE) must support for conformance with the standard – see Clause 5.3 and Clause 9 for details. Clause 6.2 provides a description of the key hierarchy supported by the MKA. MKA implements two cipher suites to generate the various keys:
Derivation of the ICV Key (ICK), computation of the ICV, and derivation of the CAK, also referred to collectively as the MKA Algorithm Agility Parameter, is defined in IEEE Std. 802.1X-2010 Clauses 6.2.4, 9.3.3, 11, and 11.2. It defines how the ICK, used to verify the integrity of MPDUs, is derived from the CAK and how the CAK is derived by the participants in an EAP exchange.
Key Wrap and Key Encryption Key (KEK) derivation are identified in Clauses 6.2, 9.3.3, 9.8.2, 9.12.1 and H.4. The KEK together with the AES Key Wrap are used by the Key
67 of 100
Ver. 0.5 Server to transport the Secure Association Keys (SAKs), used by MACsec, to the other members of the CA. The AES Key Wrap is dependent on the cipher suite implemented by MACsec (Figures 11-11, 11-12, and 11-13).
NOTE: If the NSS EDE device is intended to be used to protect a NSS that contains TOP SECRET information, then MKA must support 256-bit keys. (See note in subsection 5.1.1.1).
5.1.1.3. EAP Method
EAP is an authentication framework that supports various types of authentication methods. IEEE Std. 802.1X-2010 requires all EAP methods used by a PAE to support mutual authentication. IEEE Std. 802.1X-2010 Clause 8.11 and associated sub-clauses provide a description of EAP Methods and the association between EAP Methods, MKA, and the Secure Device Identifier (SecID) used in IEEE Std. 802.1ar-2009. The use of EAP in IEEE Std. 802.1X-2010 requires the use of an EAP method that can derive keys that can be used to generate the Master Session Key (MSK) that in turn can be used to generate a CAK. The EAP method is executed between the Supplicant and the Authentication Server.
One method that satisfies the requirements of IEEE Std. 802.1X-2010 is EAP-TLS that is mandated when opting to support the use of SecIDs - see IEEE Std. 802.1ar-2009. EAP-TLS supports key derivation, generation of an MSK (if required), and generation of a Session-Id and integration with SecID.
The EAP method in the Authentication Server shall be implemented with the same level of assurance as the Supplicant and Authenticator SecY and KaY (including MKA) implementations. If using EAP-TLS, the ESS shall require the use of TLS 1.2, and Suite B at the 128-bit security level and, if needed, at the 192-bit security level as defined in RFC 5430 (bis in process). The supported Suite B cipher suites shall be consistent with the cipher suite(s) supported in subsection 5.1.1.1.
5.1.1.4. IKE Cryptographic Algorithms
Pre-Shared Key (PSK) is defined in IEEE Std. 802.1X-2010 as a key that has been put in place by means outside the scope of the standard – see subsection 5.2.2.2 for a more detailed description. In order to obtain a PSK, the NSS EDE device developers shall implement the IKEv2 protocol.
The IKEv2 initial exchange is the IKE_SA_INIT exchange that negotiates cryptographic algorithms, exchanges nonces, and performs a Diffie-Hellman (DH) exchange. This initial exchange of information provides cryptographic protection, integrity protection, and authentication for the remainder of the exchanges involved in the IKEv2 protocol – see RFC 5996 Section 1.2 for details.
The IKE SA negotiates four cryptographic algorithms: 68 of 100
Ver. 0.5 Encryption algorithm – used to provide protection services. Integrity protection algorithm – used to provide assurance that the payload included in each message part of the IKEv2 exchange has not been altered, intentionally or unintentionally, by unauthorized or unknown means. A Diffie-Hellman group – key agreement protocol. A pseudorandom function (PRF) – used for the construction of keying material. For details on generation of keying material refer to RFC 5996 Section 2.13.
After the initial IKEv2 exchange, each party can generate a SKEYSEED from which all keys are derived for the IKE SA. All IKEv2 messages that follow are encrypted and integrity protected using the keys derived from SKEYSEED.
In ESS, IKEv2 shall support SUITE_B_GCM_128 and, if needed, SUITE_B_GCM_256 as defined in RFC 4869 (bis) Section 3. The supported Suite B cipher suites shall be consistent with the cipher suite(s) supported in subsection 5.1.1.1.
5.1.2. Supported Logical Secure Association (SA) Topologies
This section describes the different keying topologies that can be established and supported between NSS EDE devices. These conform to IEEE Std. 802.1X-2010, which specializes the concept of Connectivity Association (CA) defined in IEEE Std. 802.1AE-2006 clause 7.1 in some respects and extends it in others.
For each keying topology, there will be a brief discussion of how the keys may be established and maintained. There is also a brief discussion of how the keying topology relates to possible choices for underlying insecure MAC service connectivity topologies.
In IEEE Std. 802.1AE-2006 Clause 7, a Connectivity Association (CA) comprises a set of secure connections (SCs), one per CA participant. Each SC is instantiated by a sequence of security associations (SAs), and each security association is the manifestation of a security association key (SAK). In IEEE Std. 802.1X-2010 Clause 9, the MACsec Key Agreement (MKA) protocol is defined to manage generation and distribution of SAKs. However, MKA only provides one SAK at a time for a CA—all members of a CA are to use the same SAK for both transmit and receive. So while there continues to be a distinct SC per CA participant (as evidenced by the Secure Channel Identifier (SCI)), and each SC is supported by a distinct sequence of SAs (as evidenced by the Secure Association Identifier (SAI), which is an extension of the SCI), all of the SAs in a CA manifest the same SAK, and use the same association number (a field in the SAI). The difference between this and the implication in IEEE Std. 802.1AE-2006 that SAs would be separately keyed is slight, since IEEE Std. 802.1AE-2006 expects all CA participants to have SAKs for all SCs in the CA.
MKA also turns the CA into a cryptographic association in its own right—for the support of MKA. The CA is the manifestation of a Connectivity Association Key (CAK)—a symmetric key that determines how MKA protocol messages are authenticated and integrity protected, and determines how MKA wraps SAKs for distribution. IEEE Std. 802.1X-2010 Clause 5.10.a requires that a device support at least 2 simultaneous CAs. It says this by requiring that the Port 69 of 100
Ver. 0.5 Access Entity (PAE) maintain at least 2 simultaneous MKA instances; each MKA instance is dedicated to a single CA. For each CA that a PAE maintains, it must be able to support a ―latest‖ and ―old‖ SAK.
When all CA participants use the same SAK, the SAK lifetime is determined by the first participant whose packet number (PN) reaches 0xC0000000, or the crypto-period, whichever is first – IEEE Std. 802.1X-2010 Clause 9.8.
For keys that are dynamically generated by participating peers rather than pre-shared, IEEE Std. 802.1X-2010 Clause 6 uses the Extensible Authentication Protocol (EAP) together with IEEE Std. 802.1AR-2009 for certificates and EAP-TLS as the designated EAP method for key agreement. EAP has two protocol roles—supplicant and authenticator. In the use cases addressed by the ESS, the PAEs are as likely to be true peers as to have an obvious supplicant versus authenticator relationship. Thus it can be reasonable for a pair of PAEs to both support both roles, and for a pair of EAP authentication exchanges to complete. EAP lacks the capability to recognize this, so MKA has the added responsibility to ensure that communicating peers agree on the use of authentication results (IEEE Std. 802.1X-2010 Clause 6.3.1).
5.1.2.1. Single pair-wise SA
A pair-wise secure association is achieved with a CA comprising just two members who share a unique CAK (IEEE Std. 802.1X-2010 prohibits multiple CAs from sharing the same key). The CA contains two SCs, one for each member of the CA. The SCs are instantiated via a single sequence of SAKs—the SCs always share the same SAK.
The CAK must be derived from EAP-TLS, or using some other technique (which IEEE Std. 802.1X-2010 will regard as ―pre-shared‖ by virtue of happening outside the scope of the standard). When EAP is used to produce a CAK between two NSS EDE devices, it may happen that two CAKs are produced, if both devices support both EAP roles. MKA is responsible for telling that two potential CAs are equivalent and coordinating which one to instantiate with an SAK.
The insecure MAC service that connects the ―common ports‖ (black side interfaces) of the pair of NSS EDE devices may be point-to-point, but is not required to be. It can also be point-to– multipoint, or full shared media. In the latter cases, the CA creates a secure MAC service connecting a subset of the stations that participate in the insecure MAC service.
5.1.2.2. Multiple pair-wise SA
Multiple pair-wise secure associations are achieved via multiple pair-wise CAs. When a single NSS EDE device belongs to more than one CA at a time for traffic purposes (as opposed to the multiple CAs that may exist in a key hierarchy for a single group CA as is discussed in 5.2), it maintains a separate SecY and Controlled Port for each CA.
Each CA is managed separately, as described in subsection 5.1.2.1. When a PAE is active in 70 of 100
Ver. 0.5 multiple pair-wise associations because it is the hub of a hub-and-spoke topology, the hub PAE should act as the authenticator in EAP for each of the associations.
The underlying insecure MAC service must logically comprise a set of point-to-point connections corresponding to the pair-wise CAs. See subsection 5.1.3.2 below.
5.1.2.3. One to Many SA ―One to Many‖ means that each object encrypted by the ―one‖ can be decrypted by any of the ―many‖. This is achieved in MACsec by establishing a single group CA to which the ―one‖ and all of the ―many‖ must belong. In that CA, each SC is a one-to-many security relationship. Note that there is automatically an SC for each member of a CA, whether needed or not. Also note that MKA does not allow multiple CAs to share keys, whether CAKs or SAKs; so it is not permissible to mimic a group CA by identically keying multiple pairwise CAs.
A group CA is created by an individual PAE that can perform EAP authenticator and MKA key server functions. The PAE establishes a pairwise CA with each other intended member of the group, using those CAs to distribute group CAKs instead of SAKs. Once established, the group CA is not dependent on the PAE that created it.
The underlying insecure MAC service can comprise a set of point-to-point connections, or be point-to-multipoint or full shared media. Just because the CA contains all possible SCs by definition does not mean that the MAC service is required to support them all. In a broadcast setting, a hub and spoke, or tree-like service may be suitable.
5.1.3. Supported Encrypted Data Flow Topologies
This section discusses how MACsec can be deployed to support different objectives concerning cryptographic separation or interoperability for the secure MAC service. This is presented in terms of the cryptographic separation intended for a data flow using the secure MAC service.
5.1.3.1. Single Point-to-Point
To cryptographically separate a point-to-point connection from all others, the supporting secure MAC service must be a pair-wise CA. See subsection 5.1.2.1.
5.1.3.2. Multiple Point-to-Point
This addresses the situation in which communication needs to have a hub-and-spoke topology, such that the spokes can interact with the hub but not each other. It may be in the context of insecure point-to-point connections that match the desired secure topology, or in the context of an insecure multi-access MAC Service. The objective in the latter case would be to cryptographically prevent misdirection of traffic. However, it is important to note that IEEE Std. 71 of 100
Ver. 0.5 802.1AE-2006 Clause 7.3.2 requires that bridge-to-bridge interactions, including configuration protocols for frame relay and filtering, operate over a topology that is not itself dependent on the secure MAC Service. In order to comply with that restriction, the insecure network topology must itself distinguish the desired point-to-point data flows in such a way that an NSS EDE device supporting them will have a distinct insecure MAC Service port for each, corresponding to distinct SecYs and CAs. This may be accomplished by VLANs over a shared media LAN as well as by physically distinct point-to-point connections. Where VLANs are used, it may be possible for more than one point-to-point CA to operate simultaneously in a single VLAN, but only if there is no overlap in members.
The use of VLANs in this context is different from the scenarios in Section 4. In Section 4, PBN or PBBN VLANs create the necessary condition of a single-hop connection between desired MACsec endpoints. Here, the VLANs satisfy the criterion that frame relay and filtering is not altered by the addition of MACsec.
5.1.3.3. Point-to-multipoint Service
This topology differs from multiple point-to-point services in that the multipoint endpoints of the secure MAC service are not cryptographically segregated from each other. That can be useful for broadcast or multicast communication, but also simplifies spanning tree considerations in the general case. All parties belong to a single CA as described in subsection 5.1.2.3. Then the SC corresponding to the originating ―point‖ supports the desired service. Conceptually, no one SC in the CA has priority or stature above the others. As a practical matter it will likely make sense for the PAE serving the data flow originating point to act as the authenticator for creating the pair-wise CAs that lead to the group CA, and then to carry on as the group CA key server. Note that the restriction identified in 5.1.2.2 that only one CA (with its successors) may be resident to physical or virtual LAN segment applies here as well. For example, if more than point-to- multipoint service (not sharing exactly the same members) were required over a single provider backbone, multiple CAs would be needed, and each would be required to reside in a distinct VLAN.
5.1.3.4. Multi-Access Service
Again, this topology differs from multiple point-to-point services in that cryptographic separation is not needed on a pair-wise basis—it is enough to segregate the set of authorized devices from everything else. This is achieved by including all of the devices in a single group CA. Note that the restriction identified in subsection 5.1.3.2, that frame relay and filtering operate over a topology that is not itself dependent on the secure MAC Service, applies here as well. More than one secure data flow topology can coexist on a single insecure MAC Service, but only if they are entirely disjoint or if they are already segregated in different VLANs.
5.1.4. Additional Security Services
72 of 100
Ver. 0.5 5.1.4.1. Replay Protection
Replay Protection is defined by IEEE as follows:
IEEE Std. 802.1AE-2006 Clause 10.2 bullet h, 10.4, 10.6 and sub-clauses, and 10.7, handle replay for MAC Security Entity (SecY) and regular PDUs (payload frames). IEEE Std. 802.1X-2010 – MACsec Key exchange / key Management Ref – Clauses 9, 9.4 and 9.4.2. For more detail, 12.1, 12.2, 12.4 and 12.9.3 describe replay protection as handled by the MACsec Key Agreement Protocol (MKA) for MKPDU frames.
The determination of the replay window is left to the local network policy defined by the NSS user.
73 of 100
Ver. 0.5 5.2. Keying Architecture and Management
Key management for MACsec is about how to obtain and control not only the desired SAKs (see subsection 5.1.2), but also all of the keys necessary for MKA and EAP that emerge as part of the solution for managing the SAKs.
This section is divided in several subsections. The first subsection is a summary of MKA as specified in IEEE Std. 802.1X-2010. The second subsection describes the different methods for obtaining the initial keys needed by MKA and recommended for NSS use. The third subsection describes how key lifespan is managed/defined for keys and certificates used by the NSS EDE device. The fourth subsection provides a definition of certificate. The last subsection provides a description of the various Connectivity Association (CA) scenarios that can be supported by the NSS EDE device.
5.2.1. MACsec Key Agreement Protocol (MKA)
IEEE Std. 802.1X-2010 defines the MACsec Key Agreement Protocol (MKA) for distributing and replacing SAKs. This section provides a brief overview and highlights a few important concepts and issues. A full reading of IEEE Std. 802.1X-2010 clauses 6.2, 6.3, 9, 11.11, and 12 are necessary to understand MKA.
MKA uses and manages a hierarchy of symmetric keys. The root key of the hierarchy is the secure Connectivity Association Key (CAK). The CAK is shared by all members of a given CA, and is in fact what defines a CA in practice—a functioning CA is the consequence of devices that discover that they share a CAK and use it to sustain an MKA protocol sequence. The main point is that an existing CAK is a prerequisite for two or more parties to successfully engage in an MKA protocol session.
MKA protects all of its own protocol frames (MKPDUs) with a cryptographic Integrity Check Value (ICV). The ICV Key (ICK) is derived from the CAK. The derivation function and integrity check algorithm are specified in subsection 5.1.1.2. All members of a CA transmit and receive MKPDUs.
MKA negotiates election of one member of each CA to perform the role of Key Server. This is specified in IEEE Std. 802.1X-2010 clause 9.5. The Key Server generates SAKs and CAKs, wraps them, and distributes them in MKPDUs. For the ESS, SAKs should be generated using the KDF-based method specified in IEEE Std. 802.1X-2010 Clause 9.8.1. The KDF shall use AES-CMAC-128 or AES-CMAC-256 as appropriate to provide security consistent with the choice of cipher suite(s) in subsection 5.1.1.1. SAKs are wrapped for distribution in an MKPDU. The Key Encryption Key (KEK) is derived from the CAK. The choice of key wrap algorithm and KEK derivation algorithm is governed by the MACsec Cipher Suite in which the SAK will be used – see subsection 5.1.1.2.
An SAK must be rekeyed before any device exhausts the packet number field values in the MACsec tag. Because the packet number field is only 32 bits, the values can be exhausted 74 of 100
Ver. 0.5 relatively quickly at high data rates as shown in Table 3 below. In addition, the table shows how a change in the PN size affects the rekey rate.
PN Size Re-key Intervals – Worst Case 1G Line 10G Line 40G Line 100G Line 400G Line 1T Line Rate Rate Rate Rate Rate Rate 32-bit 1.11 Hrs. 6.64 Mins. 99.64 Secs. 39.86 Secs. 9.96 Secs. 3.99 Secs 40-bit 283.43 Hrs. 28.34 Hrs. 7.09 Hrs. 2.83 Hrs. 42.54 Mins. 16 Mins. 44-bit 4534.87 453.49 Hrs. 113.37 Hrs. 45.35 Hrs. 11.33 Hrs. 4.54 Hrs. Hrs. 48-bit 72557.99 7255.80 1813.95 725.58 Hrs. 181.40 Hrs. 72.56 Hrs Hrs. Hrs. Hrs. Table 3 – Re-key Intervals.
NOTE: Worst Case is defined as an uninterrupted stream of minimum-sized 64 byte standard Ethernet frames.
MKA is designed to automatically change an SAK before the packet number value will roll over. Every CA member (whether key server or not) sends periodic ―heartbeat‖ MKPDUs as defined in IEEE Std. 802.1X-2010 Clauses 9 and 11. In the MACsec SAK Use parameter set (set type 3; IEEE Std. 802.1X-2010 Clause 11.11.1), each CA member announces the Latest Key Lowest Acceptable PN (LLPN) for its own transmit SA. The LLPN value ordinarily depends on whether data delay protection is selected (see IEEE Std. 802.1X-2010 Clause 9.10.1). However, when the LLPN reaches the constant PendingPNExhaustion (0xC000…000), the member must transmit an MKPDU with an LLPN that equals or exceeds PendingPNExhaustion, regardless of whether data delay protection is selected or not. The CA Key Server member monitors LLPN from all of the live peers (and itself). An LLPN that equals or exceeds PendingPNExhaustion triggers the Key Server to generate and distribute a new SAK to all of the CA, as specified in IEEE Std. 802.1X- 2010 Clause 9.8. All members reset their transmit packet number to one when they begin to use the new SAK. MKA can supply fresh SAKs quickly enough to support MACsec data rates in excess of 100 Gbps even with worst case frame sizes and group dynamics (a new live peer can delay a rekey by MKA Life Time). Thus, it will not be particularly noticeable to human administrators whether the packet number value rolls over in 24 hours, 24 minutes, or 24 seconds. However, the MKA Life Time timer limit can impose a time delay of as much as 6 to 8 seconds for SAK distribution in certain circumstances. Since SAK distribution must be complete before MACsec exhausts the remaining quarter of the pack number space after PendingPNExhaustion is reached, there is an effective upper bound to the Ethernet Line Rate that MKA can support without danger of interruption. Based on the values in Table 3, it appears that MKA can support use of the 32-bit PN field for line rates up to 100Gbps; at 100Gbps, just under 10 seconds are available for SAK distribution after PendingPNExhaustion is reached, which is more than the maximum time delay that MKA can suffer. At 400Gbps, less than 2.5 seconds are available for SAK distribution in the worst case, so a maximum MKA time delay would cause a network interruption.
When a CA already exists (and hence a CAK is already shared by the CA members), the CA Key Server can create further CAs, as long as all members of the existing CA are qualified to belong to the new CA. MKA cannot selectively exclude a member of an existing CA from any 75 of 100
Ver. 0.5 subsequent CA.
As noted in subsection 5.1.2, a CA may be pair-wise, or shared by a group. When a single device is Key Server for several CAs, pair-wise or group, it can construct a new group CA by generating a new CA key and distributing it within each of the existing CAs for which it is the designated key server. This does not replace the previously existing CAs, unless the members choose to let them lapse.
There are circumstances in which multiple CAs, and hence MKA exchanges, may arise involving exactly the same parties. MKA Key Server election is supposed to select the same device in all cases. The PAE hosting the elected Key Server participants is expected to recognize the situation and designate one of those participants as ―principal‖. The non-principal Key Servers are supposed to withhold distributing keys and parameters. This, together with rules for MKA participant deletion (see in particular IEEE Std. 802.1X-2010 clause 9.14.j), is supposed to result in a single, unambiguous CA and SAK. However, there is one notable contradiction concerning how this works in relation to EAP. That case is identified and resolved below with the discussion of EAP.
For the ESS, a single CAK shall not be used for more than one CA (i.e. using the same key with more than one Connectivity Association Key Name (CKN)), or for a single CA whose members are not all connected via the insecure MAC Service and reachable using the Bridge Group address. This restriction also ensures conformance to the requirement in IEEE Std. 802.1X-2010 Clause 6.2 that ―a pairwise CAK derived using EAP shall not be distributed for use as a group CAK.‖
5.2.2. Secure Connectivity Association (CA) Creation
In order to create CAKs, the creation of a CA is necessary. MKA can create a new CA to replace an existing CA, or as a collection of existing CAs. However, MKA cannot establish a CA from scratch. IEEE Std. 802.1X-2010 provides two different approaches for independently creating a CA:
Extensible Authentication Protocol (EAP). Pre-Shared Key (PSK).
Note that PSK means only that key origination is out of scope for the standard, not that it originates in any particular way. This is discussed below.
For use of MACsec to support infrastructure LANs and virtual shared media infrastructure LANS, IEEE Std. 802.1X-2010, Table 5-1, recommends:
1. PSKs as the minimum functionality. 2. EAP with CAK cache, and PSKs as the recommended functionality.
The ESS requirements are specified in the following subsections. However the summary is the following: 76 of 100
Ver. 0.5 NSS EDE devices shall support a method for key exchange to create CAs. This may be fulfilled by using EAP, or by using IKEv2 to create a shared key that will be treated as a PSK. Both EAP (with the required EAP method) and IKEv2 require certificates for public keys. Solutions for obtaining certificates are discussed in 5.2.3. NSS EDE devices may support distribution of PSK from an external source (such as NSA). In ESS, the special case of PSKs that are provisioned via a management interface (Layer Management Interface in IEEE Std. 802.1AE-2006 or Local Management Interface in IEEE Std.802.1X-2010) will be called Pre-Placed Key (PPK), see subsection 5.2.2.2.2 below. PPK distribution shall be cryptographically protected. PPK distribution shall not be the sole means to create CAs. PPK distribution shall provide distinct keys for distinct CAs.
5.2.2.1. Extensible Authentication Protocol (EAP)
EAP is defined as follows:
IEEE Std. 802.1X-2010 defines EAP over LAN (EAPoL) PDUs, so that EAP, and EAP methods, can run natively at Layer 2. This can be important in order for the outcome of EAP to have authenticated the Layer 2 entities rather than higher-level entities that must then be associated in some way to the Layer 2 entities. EAP requires use of an EAP method for obtaining a Master Session Key (MSK) that can be used to generate a CAK. The ESS and IEEE Std. 802.1X-2010 requirements for the choice of EAP method are specified in subsection 5.1.1.3. Derivation of a CAK from an MSK is specified in subsection 5.1.1.4. EAP has three roles: Supplicant, Authenticator, and Authentication Server. The resulting CA will be between the Supplicant and Authenticator. However, EAP and particularly the EAP method key exchange is conducted between the Supplicant and the Authentication Server, passing through the Authenticator. Ordinarily the Authentication Server services many Authenticators. The MSK produced by the Authentication Server has to be transported to the Authenticator. For the ESS, the EAP method implementation in the Authentication Server shall be at least as assured as the Supplicant and Authenticator SecY and KaY (including MKA) implementations. IEEE Std. 802.1X-2010 Clause 6.3.1 allows that ―the Authenticator and an Authentication Server can be co-located within the same system, allowing that system to perform the authentication function without the need for communication with an external server.‖ It also states that ―a system may implement and enable both Authenticator and Supplicant state machines‖. Both of these can be practical and necessary when using MACsec to protect connection of enterprise enclaves over an external provider network. An external server of sufficient assurance may be problematic, and the connection between two bridges in the core of a network lacks the natural asymmetry that corresponds to the Supplicant and Authenticator roles. When an Authentication Server is co-located with an Authenticator, the Authentication Server only needs to support authentication for the parties that legitimately belong on the same (virtual) LAN segment as the Authenticator. In the context of MACsec support for LAN infrastructure, those parties normally form a closed and static set. Authentication can be 77 of 100
Ver. 0.5 achieved by relatively simple means such as an ACL, and this can be combined with certificate solutions as discussed in 5.2.3. EAP and Key Server election: o IEEE Std. 802.1X-2010 clause 9.5 states that in a pairwise CA ―derived directly from EAP, the MKA participant for the PAE that was the EAP Authenticator will be the Key Server.‖ This contradicts clause 6.3.1 and the last paragraph of 9.5 with respect to recognizing and resolving duplicate CAs between a pair of devices that both support Authenticator and Supplicant roles simultaneously. o Until IEEE resolves the contradiction otherwise, the ESS specifies the following: A PAE that simultaneously supports Authenticator and Supplicant roles for the same port shall configure that port‘s MKA participants to select a Key Server based on Key Server Priority values, without regard to whether EAP was used or not. EAP and group CA formation: o When more than two devices are intended to form a CA, but that CA will bootstrap via EAP according to the key hierarchy in IEEE Std. 802.1X-2010 clause 6.2, EAP is responsible for determining group membership as well as entity authentication. In some cases it may be possible to depend on a simplistic policy that whenever more than one distinct pairwise CA has been formed at a port, a group CA should be created comprising all the known peers of all the pairwise CAs. In general, this policy is not safe to assume, and shall not be implemented as a default. Authenticators (hence the PAE) shall be informed by the Authentication Server when a port, and specific entities authenticated via that port, are intended to become part of a group CA. o There are operational reasons for explicitly distinguishing between pairwise CAs that are used directly to protect traffic, versus pairwise CAs that are needed only to form a group CA. In the latter case, the pairwise CAs have nothing to do with the SecY and there is no reason for them to distribute an SAK. The ESS specifies just one SecY per common port. A CAK and MKA participant created for a port is presumed to obtain the SAKs for the SecY for that port. Therefore it is important for the PAE to learn from EAP when a CAK is not intended to serve the SecY, but rather to build the foundation for a group CAK for that SecY. CAKs derived from EAP shall be cached as specified in IEEE Std. 802.1X-2010 clauses 12.6 and 5.11.3 in order to support rapid reauthentication after a loss of connection. Once the CA is established, for every EAPoL announcement transmitted there must be an equivalent MKA announcement. For the ESS, the MKA parameter MACsec Capability (see IEEE Std. 802.1X-2010 Table 11-6) shall be encoded either to a value of 2 or 3. A value of 0 or 1 shall not be allowed. For the ESS, the Access Information TLV Access Capabilities field (see IEEE Std. 802.1X- 2010 Table 11-9) shall have bit 3 (EAP + MKA + MACsec) or bit 5 (MKA + MACsec) set unless implementing IKE where bit 6 (Higher Layer – WebAuth) or 8 (Vendor specific) is set. All other bits shall not be set.
5.2.2.2. Pre-Shared Key (PSK)
78 of 100
Ver. 0.5 PSK means that the key has been put in place by means that are outside of the scope of IEEE Std. 802.1X-2010. That is, in the context of IEEE Std. 802.1X-2010 functions and protocols, the key already exists and is shared by the relevant parties. Depending on the manner of distribution, PSK can be pairwise or group. The ESS specifies two alternatives for obtaining PSKs: IKEv2 and Pre-Placed Key.
5.2.2.2.1. Internet Key Exchange (IKE)
For purposes of the ESS, IKE is used as follows.
ESS recommends that NSS EDE devices use IKEv2 as a way to form a PSK between two peers. IKEv2 shall run over IPv6, where the source and destination addresses are the link-local addresses derived from the Ethernet MAC addresses as specified by RFC 4291 sections 2.5.1 and 2.5.6. This is to ensure that the Layer 2 entities are authenticated or bound to the resulting PSK, rather than just Layer 3 entities. The IKE_SA_INIT messages shall follow the RFC 5996 specification. The cipher suites to be used for the ESS are identified in subsection 5.1.1.4 above. The IKE_AUTH messages shall also follow RFC 5996. SKEYSEED is used to generate 7 keys for the IKE SA as usual. Of those keys, SK_d shall become the PSK for the ESS. At that point, IKE terminates. Rekey is accomplished by initiating a new IKE exchange. PSKs derived from IKE shall be cached as specified in IEEE Std. 802.1X-2010 clauses 12.6 and 5.11.3 in order to support rapid reauthentication after a loss of connection. Caching of PSKs derived from IKE shall follow the same rules as for EAP-derived CAKs.
5.2.2.2.2. Pre-Placed Key (PPK)
For purposes of the ESS, PPK is defined as follows:
PPK is a term that is used in a wide variety of contexts, but not in IEEE Std. 802.1X-2010. In the ESS, PPK means a secret symmetric key obtained from an external key management infrastructure, such as the NSA. Traditionally, PPK has been distributed via manual fill. PPK could be a pairwise or group CAK. Commercial best practice for the minimum functional use of PSK to support infrastructure LANs is expected to be analogous to PPK. For the ESS, PPK shall not be the sole means for CA Creation. However, PPK can be essential in certain situations to enable interoperability. PPK distribution, when supported, shall be cryptographically protected. For devices intended to receive PPK from the NSA, the required Key Management Plan shall address how distribution is protected, and determine how distinct CAs obtain distinct CAKs. PPKs are effectively cached by definition, though IEEE Std. 802.1X-2010 is somewhat ambiguous about whether it is carried out in the CAK cache as defined in Clause 12.6. The functional requirements with respect to MKA are the same either way.
79 of 100
Ver. 0.5 5.2.3. Key Lifespan
CAs in the infrastructure setting are expected to be long-lived. However, CAK lifespan shall conform to existing policies as identified by the NSS user. For PPKs, this could be daily, weekly, or monthly, as approved in a Key Management Plan. When CAKs are derived from EAP or IKE, there really should not be any impediment to daily authentication, and this should be preferred. IEEE Std. 802.1X-2010 clause 9.3.2 discusses some issues relating to CA rollover.
SAK lifespan is governed by PN rollover, CAK rollover, or the connection status of the Controlled Port (as defined by the Controlled Port state machine – IEEE Std.802.1X-2010 clause 12.4 paragraph, Figure 12-2 when newSAK and chgdConnect are set), whichever happens first.
ICK and KEK lifespan correspond to the CAK from which they are derived.
The lifespan of certificates and associated private keys is governed by a PKI Certificate Policy, when a PKI is used. Otherwise, see subsection 5.2.4 below.
The lifespan for self-signed certificates will be addressed by NSS user policy and doctrine for the management of the access control list.
5.2.4. Certificates
Certificates for NSS use are defined as follows:
The NSS EDE device certificates shall conform to IEEE Std. 802.1AR-2009 Secure Device Identifier, and to the Suite B certificate profile. The exact specification of ―subject‖ is TBD. ―subjectAltName‖ shall use the hardwareModuleName construct as specified in RFC 4108. Certificates should be obtained from an authorized PKI when one is available supporting assurance commensurate to the application of the NSS EDE device. Where support from an authorized PKI is problematic, the ESS allows use of self-signed certificates in the context of MACsec support for LAN infrastructure, where the set of connected devices is closed, few in number, and relatively static. This is true even for Government-developed devices. However, authentication using self-signed certificates shall not be based solely on validation of the certificate signature. Authentication shall be out-of- band. Secure configuration procedures shall be used to give an NSS EDE device knowledge of the certificates or public keys for the devices it is authorized to interact with. Where EAP is used for CA creation, Supplicant role devices need only be configured to know the certificate(s) for the Authentication Server(s). An Authentication Server role device needs to know the certificate for each Supplicant that it can serve. Revocation of self-signed certificates shall be addressed by configuration procedure as well. Since self-signed certificates essentially form the content for Access Control Lists (ACL), their lifespan should be consistent with policy for ACL management. It is more important to have periodic review and verification of ACL content than to generate new certificates and have to rebuild the lists.
80 of 100
Ver. 0.5 The list of certificates or public keys that a device is configured to recognize shall be readable in the MIB and readable with SNMPv3. If the security for SNMPv3 is implemented in both the NSS EDE device and a manager device at a level of assurance commensurate with the key exchange protocol in which the self-signed certificate will be used, then SNMPv3 may be used as part of the procedure for configuring or revoking knowledge of a certificate. An Authentication Server store of self-signed certificates shall be augmented with information about authorized group membership for group CAs.
5.2.5. Scenarios
This subsection describes the various Connectivity Association (CA) scenarios that ESS supports for use to protect NSSs. These include Pairwise and Group CAs.
5.2.5.1. Pairwise CA
Pairwise CA can be PSK or EAP based as described in the following subsections.
5.2.5.1.1. PSK-based Pairwise CA
In this scenario, two devices already share a CAK. It may have been cached from a previous session, or have been established by IKEv2, or have been distributed as a PPK.
This scenario is described in IEEE Std. 802.1X-2010 Clause 9.17.1, using notation described at the beginning of Clause 9.17.
5.2.5.1.2. EAP-based Pairwise CA
In this scenario, two NSS EDE devices first discover and then authenticate each other using EAP as follows:
Discovery can begin using EAPoL announcements (IEEE Std. 802.1X-2010 Clauses 10 and 11.12). Announcement frames are addressed to a group address that reaches the edge points of the (virtual) LAN segment where peer NSS EDE devices would reside. Announcement frames can advertise the NSS EDE device Access Information, MACsec Suite, Key Management Domain, and Network Identifier. Announcement frames carry no protection for either confidentiality or integrity. If they are the basis for any decision, the relevant information must be confirmed later by protected MKPDUs using the Announcement TLVs (IEEE Std. 802.1X-2010 Clause 11.12). The NSS EDE devices initiate EAP (IEEE Std. 802.1X-2010 Clause 8). If one of the NSS EDE devices implements only one EAP role (Supplicant or Authenticator), then one EAP
81 of 100
Ver. 0.5 protocol exchange will occur, producing one MSK. Either NSS EDE device may initiate EAP (send the first frame), and EAPoL will recognize and resolve collisions. If both NSS EDE devices implement both EAP roles, then two protocol exchanges may occur, one for each role pair. This will produce two MSKs. Creation of an MSK causes the PAE KaY to create an MKA participant, derive a CAK, and initiate MKA as in subsection 5.2.5.1.1. Creation of two MSKs can result in two CAKs and two MKA participants in each NSS EDE device. Both MKA protocol exchanges progress as far as constructing the Live Peers List. Both will choose the same NSS EDE device for Key Server as defined in IEEE Std. 802.1X- 2010 Clauses 6.3.1 and 7.2.2. IEEE Std. 802.1X-2010 Clause 9.5 is restricted for Group CA only. The KaY in the Key Server device is now expected to recognize the redundancy and pick one of the local MKA participants to be ―principal‖. The principal participant will carry on with distributing an SAK. The other Key Server participant will refuse to distribute an SAK. The redundant MKA participants will expire after MKA Life Time (IEEE Std. 802.1X- 2010 Clause 9.15). IEEE Std. 802.1X-2010 is emphatic that EAP does not have the capability to recognize symmetric (i.e. reversed) exchanges between a given pair of parties, and that MKA is needed to recognize and resolve the condition.
5.2.5.2. Group CA
Group CA can be PSK-based or built from pairwise CAs. See the following subsections for a description.
5.2.5.2.1. PSK-based Group CA In this scenario, more than two NSS EDE devices already share a CAK. It may have been cached from a previous session, or distributed as a PPK. Since MKPDUs are addressed to a group address, initiating MKA will automatically reach all possible participants. This scenario is described in IEEE Std. 802.1X-2010 Clause 9.17.2 as an extension of the basic pairwise CA. In essence, there will be asynchrony in how NSS EDE devices join in the MKA protocol exchange, so the group may begin as a pair and add members as they become active. The elected Key Server may change as the group grows.
5.2.5.2.2. Building a Group CA from pairwise CAs
To build a Group CA from pairwise CAs use the following steps.
A single NSS EDE device must belong to a set of pairwise CAs, one for each of the other intended members of the group, and must be the elected Key Server for each as defined in IEEE Std. 802.1X-2010 Clause 9.5. The pairwise CAKs may be cached, or may have to be dynamically created using either EAP or IKEv2. The Key Server for all of the pairwise CAs must have some configuration information that authorizes a group CA and establishes which NSS EDE devices are to be members.
82 of 100
Ver. 0.5 The Key Server has to initiate MKA for each pairwise CA to the point of establishing the Live Peers List, and being re-elected as the Key Server, but need not distribute an SAK. The Key Server generates a fresh CAK. Then for each pairwise CA, the Key Server wraps the new CAK using the pairwise CA KEK, and distributes it in an MKPDU. The pairwise MKA sessions can be allowed to expire once the Group CAK is in operation. Whether or not the pairwise CAKs are discarded depends on local management settings. Once the group is established, the original Key Server is not essential. The role of Key Server for supplying SAKs within the group CA can change dynamically with changes to the Live Peers List.
5.3. Ethernet Implementations – Miscellaneous Issues
This section addresses Ethernet functions used in present day networking systems that are not related specifically to security, but whose interoperability with security standards must be taken into consideration.
5.3.1. Quality of Service
IEEE Std. 802.1AE-2006 Clause 6.10 provides a description of the impacts of the security protocol over Quality of Service (QoS). As of this revision of the ESS there are no additional goals or impacts.
5.3.2. VLAN Tags
VLAN tagging and its implementations in an Ethernet network system is of great concern to the development of the ESS and has been addressed in several sections of this document, subsection 3.3 and 4. References have been provided to IEEE Standards and MEF specifications for implementation conformance.
5.3.3. Encryption Bypass of Data
The encryption bypass of data within an Ethernet frame is not recommended for NSS use unless needed to interoperate with existing standards. As defined in IEEE Std. 802.1AE-2006 and IEEE Std. 802.1X-2010, where the SecY and KaY processes are instantiated in the interface stack of the defined standard will determine what information is already in the Ethernet frame and so determine what is encrypted into the MPDU. Any further frame transformation past the SecY/KaY will not be part of the MPDU. Existing standards have been leveraged to define the ESS and at the same time meet the security goal of interoperability as defined in the ESS. Section 4 describes the various scenarios and the manipulation of the Ethernet frame as required by the ESS.
83 of 100
Ver. 0.5 IEEE Std. 802.1AE-2006 Clause 10.7.24 provides the option for a confidentiality offset that if enabled a selectable number (0, 30, or 50) of the initial octets of the MSDU are only integrity protected while the remaining data is both integrity and confidentiality protected. This option is very specific to facilitate deployment on IP version 4 and version 6 hosts that perform load balancing (see NOTE on Page 62 of IEEE Std. 802.1AE-2006). This has no impact other than what is stated in IEEE Std. 802.1AE-2006 Clause 10.7.25 and Clause 14.5. The user should be aware that if enabled, the offset would apply to all frames transmitted and received with confidentiality protection.
NOTE: the confidentiality offset as defined in IEEE Std. 802.1AE-2006 seems not to allow for VLAN tags to appear in the MSDU. This needs to be taken into account when considering whether to use the confidentiality offset, since many of the topologies presented in Section 4 contain encrypted VLAN tags.
5.3.4. Encryption Bypass of Frames
To define what Ethernet frame types (EtherTypes) can or shall be bypassed in the ESS, first we need to differentiate between PDUs that are within scope of the ESS and those PDUs outside of the ESS.
An NSS EDE device is a combination of various entities such as PAE that in turn contains KaY and MKA, that implements EAP, and that communicates with SecY via LMI, etc. As described previously and in IEEE Std. 802.1AE-2006 and IEEE Std. 802.1X-2010, SecY is the main driver for data encryption, whereas MKA and KaY, using EAP, are responsible for peer discovery, peer authentication and authorization, and Key Exchange and Key Management. MKA and KaY generate various PDUs for transmission out of the common port (black side). These frames are generated by the ESS, are not handled by SecY, and do not go through the encryption process; in other words they bypass encryption.
IEEE Std. 802.1AE-2006 Clause 10.1 and Figure 10-1 provide an overview of SecY and how communication traverses the entity to/from a common port from/to an uncontrolled and controlled port. These are frames generated outside of an NSS EDE device. The encryption bypass of these Ethernet frames is not recommended by the ESS unless needed to interoperate with existing standards and as defined in IEEE Std. 802.1AE-2006 and IEEE Std. 802.1X-2010. An implementation of the ESS shall provide the option to bypass frame types as defined in this document.
5.3.5. Flow Control
The IEEE Standards group has several working groups addressing different aspects of Traffic Flow control as follows:
IEEE Std. 802.1Qay-2009 – Provider Backbone Bridge Traffic Engineering. IEEE Std. 802.1Qau/D2.4-2009 – Congestion Notification (Draft). IEEE Std. 802.1Qaz/D2.0-2010 – Enhanced Transmission Selection for 84 of 100
Ver. 0.5 Bandwidth Sharing Between Traffic Classes (Draft). IEEE Std. 802.1Qbb/D2.4-2010 – Priority-based Flow Control (Draft).
The specifics defined in IEEE Std. 802.1Qay-2009 all relate to PBBNs. As specified in subsections 4.2.1.2 and 4.2.3, MACsec and the ESS goals do not interfere with PBBN tagging (including Priority and DEI settings) and addressing, and neither does security play a role in the traffic flow inside the PBBN – security peerage is delegated at the PBB edge, between the PBB edges. As of this writing, path engineering is not a function (optional or mandatory) of MACsec or of the ESS.
There has been considerable discussion from CNSS networking architects about EDE becoming a bottleneck and introducing congestion. Therefore, it would be advantageous for NSS EDE devices to participate in flow control solutions. However, the general ―Pause‖ frame is clumsy, and the alternatives are still maturing. As the Flow Control and Traffic Engineering standards and protocols evolve the ESS shall take into consideration in future revisions of the ESS any new impacts to the ESS security goals.
5.3.6. Equal Cost Multi-Path (ECMP)
ECMP is a routing technique defined in IETF RFC 2991 for routing packets along multiple paths of equal cost. ECMP is a Layer 3 implementation and is outside the scope of the ESS. Future development of a similar Layer 2 implementation will be addressed by the ESS when released.
5.3.7. Bidirectional Forwarding Detection (BFD)
BFD is a network protocol used to detect faults between two forwarding engines connected by a link (port-based or multiplexed). It works independent of media, data protocol, or routing protocol. Supporting documentation is as follows:
RFC 5880 – defines the BFD protocol. RFC 5881 – defines the BFD protocol over IPv4 and IPv6 for single IP hops. RFC 5882 – defines the generic application of the BFD protocol. RFC 5883 – defines the BFD protocol for Multihop Paths. RFC 5884 – defines BFD for MPLS LSP data plane failure. draft-bhatia-bfd-crypto-auth-03 – BFD Generic Cryptographic Authentication.
BFD session establishment inside the black network is outside the scope of the ESS. BFD session establishment inside a red network is outside the scope of the ESS. BFD sessions between red networks shall be restricted by the ESS to the same hop-to-hop constraints as the security associations – see subsection 4.2.
5.3.8. Nesting
85 of 100
Ver. 0.5 Encryption device nesting refers to the use case where the output of an encryption device is the input of another encryption device. This is a scenario often used to tunnel higher classification data across a lower classification network. MACsec makes no provisions for encryption nesting other than as defined in IEEE Std. 802.1AE-2006 Clause 11.7 and Figure 11-13; and IEEE Std. 802.1X-2010 Clause 7.7.2 and Figure 7-17, where two instantiations of SecY are implemented.
When using nesting, there is a danger of the frame size surpassing maximum sizes allowed in intervening networks.
The use of commercial devices to protect an NSS that contains classified information will require a composed solution. It would likely be more effective to pair MACsec with a higher-layer security protocol (e.g. IPSEC or TLS) rather than to nest two layers of MACsec within Ethernet.
5.3.9. Tunneling Across a Trusted Network
Tunneling across a trusted network is better known in the IC as Reverse Tunneling, unlike Reverse Tunneling in the IP world (IETF RFC 3024), that is a method used in Mobile IP for mobile nodes to communicate.
The Reverse Tunneling IC use case is where a less trusted network is connected to the ―red‖ side of an encryption device and where the data is to be tunneled over a classified network. This is a case where isolation is the desired goal and not confidentiality. Several scenarios can be architected including nesting. Nested architectures have the same restrictions as specified in subsection 5.3.8.
ESS recommends that reverse tunneling be used in conjunction with port-based services only – no VLANs. The recommendation is specific to use of a standalone NSS EDE device where VLAN assignment comes from the red-side, and is used by the NSS EDE device to map frames to secure connectivity associations. In the reverse tunneling case, the red side lacks assurance, and assertions about VLAN membership should not be trusted. Rather, the VLAN assignment for reverse tunnels should be port-based in the NSS EDE device and controlled by configuration.
In addition, this would be a case for disallowing all management access from the untrusted network.
5.3.10. Multi-access LANs
IEEE Std. 802.1AE-2006 Clause 11.8 defines support for a multi-access LAN. Each instantiation of the MACsec entity (SecY) is identified by the SCI which is the combination of the MAC address allocated to that station and the Port Identifier unique to each SecY. As specified in Clause 11.8, this implementation is recommended only for attaching end stations or hosts at the periphery of the network. The network architect will need to be aware of the port capacities and flow control as only minimal flow control will be provided in the NSS EDE device, see subsection 5.3.5.
86 of 100
Ver. 0.5 IEEE Std. 802.1X-2010 Clause 6.3.6 defines the PAE and MKA standards to support a multi- access LAN. Part of this is PAE support of virtual ports described in Clause 5.12.
A MACsec implementation in a multi-access LAN relies on the implementation of other standards such as IEEE Std. 802.1Q-2005 and IEEE Std. 802.1ad-2005 to provide support for Spanning Tree Protocol and other such functions associated with a bridge. The ESS definition for a standalone encryption device supporting a multi-access LAN is limited unless the NSS EDE device conforms to bridging standards – functions not within scope of this revision of the ESS. In order for the ESS to support Multi-access LANs, the network architect shall rely on an external device to perform bridging functions. The number of virtual ports and associated SecY / MKA instantiations an NSS EDE device implementation can support is defined by NSS user needs and NSS EDE device capabilities. Subsection 5.1.3.4 provides additional information.
In principle each SecY encrypts with a single key with no regard of destination. So data encrypted by one bridge can be decrypted by all other bridges in the same CA. If not appropriate, MACsec can support the instantiation of multiple SecYs hosted on one MAC service common port. With a standalone encryption device it is not trivial to determine what SecY to use to decrypt a frame if there are more than one SecY per common port. IEEE Std. 802.1X-2010 Clause 5.12 and referenced sub-clauses specify the standards for a PAE to support virtual ports in real ports that do not support Supplicant functionality.
5.3.11. Link Aggregation (LAG – Link Aggregate Group)
As of this writing an NSS EDE device does not support Link Aggregation, management of a Link Aggregation Group, or an implementation of the Link Aggregation Control Protocol (LACP). This functionality, just as any bridging functionality, is considered out of scope for a standalone encryption device for this revision.
The recommendation in IEEE Std. 802.1AE-2006 is that independent SecYs be employed on each link, and that the link aggregation protocol operates above the SecYs. Since the point of LAG is to harness multiple physical links to obtain greater bandwidth, there are two natural ways in which ESS could integrate with LAG. The simplest solution is that the NSS EDE devices are allocated to the individual links—one NSS EDE device per physical link being aggregated. This has the unfortunate side effect that multiple NSS EDE devices are required, one per physical link. If an NSS EDE device is capable of supporting the combined bandwidth of the aggregated links, then LAG could be supported by one NSS EDE device if the bridge responsible for LAG is configured to assign a different S-VLAN to each link. The NSS EDE device can then map the different S-VLAN frames to the appropriate black-side ports.
Any bypassing of LACP frames shall be considered on a frame by frame case as defined in subsection 5.3.4.
Initially Multi-access LAN was considered as a viable alternative to Link Aggregation. However, Multi-Access LANs are problematic in the network core as specified in subsection 5.3.10.
87 of 100
Ver. 0.5 5.4. Ethernet Management
5.4.1. Initialization
Initialization of a device implementing the ESS is out of scope for this specification except for aspects of key management as addressed in subsection 5.2.
5.4.2. Configuration Management
Configuration management of a device implementing the ESS is out of scope for this specification except for the standardization of the MIB content.
5.4.3. Ethernet Operations, Administration and Maintenance
Ethernet OAM is out of scope for the ESS unless it creates a need for frame bypass. For details refer to the following.
IEEE Std. 802.1ag-2007 – Connectivity Fault Management per Service/VLAN (Ethernet Virtual Connection – EVC) OAM. 3 protocols – Continuity Check, Link Trace and Loopback. IEEE Std. 802.3ah-2004 – Link Layer OAM. MEF 16 – E-LMI (Ethernet Local Management Interface). IETF – VPLS OAM Requirements and Framework draft-ietf-l2vpn-oam-req-frmk-01.txt.
5.4.4. Community of Interest (COI)
Community of Interest is a means of segregating users, limiting access to network assets, protecting network infrastructure, and protecting specific users, etc. Several mechanisms can be employed for COI, including VLAN architectures, use of routers, and firewalls, as well as various Access Control Methodologies.
MACsec and the ESS by definition provide a method of Access Control where authentication and authorization are provided by the defined keying exchange and the selected key exchange. Once authentication and authorization is granted all parties have the same COI level.
A secure connectivity association (CA) is in effect a COI. The ESS can support pairwise and group CAs. Where multiple CAs co-exist over a common insecure MAC Service, CAs should be also separated by different VLANs. See subsection 5.1.2 for a description of CAs.
Other methods of COI are the responsibility of the network administrator and can be
88 of 100
Ver. 0.5 implemented either by architectural design or policy.
5.4.5. Management Information Base (MIB)
IEEE Std. 802.1AE-2006 defines the MACsec MIB (Clause 13) plus any additional information collected for other MIBs, such as port statistics for the interface MIB Counters (Clauses 10.7.3, 10.7.6 and 13) (RFC 2863) and the System Group MIB (Clause 13) (RFC 3418). IEEE Std. 802.1X-2010 defines the PAE MIB (Clause 13) and the PAC management provides various port and session statistics for the interface MIB Counters (Clauses 6.4.3 and 12.5.1) and the System Group MIB (Clause 13). The ESS goals advocate the use of these MIBs and do not require any additional information. Data shall be made available on the red-side of the network. Exposure of data on the black-side will be considered on a case by case basis.
Access to MIBs shall be performed using SNMPv3 with TLS Rev 1.2 - see RFC 5953. The ESS is expected to control access to MIB information restricted to the red-side.
NOTE: Implementation assurance for RFC 5953 with Suite B and SNMPv3 may be permitted to be less than the assurance for the SecY when traffic is restricted to the red-side.
5.5. IEEE / ESS Conformance
The following table provides a summary of the NSS EDE device conformance requirements as defined by IEEE Std. 802.1AE-2006 Clause 5 and IEEE Std. 802.1X-2010 Clause 5 as compared to the ESS Conformance.
Conformance IEEE ESS
FROM: IEEE Std. 802.1AE-2006 Clauses 5.3 An implementation of a MAC Security Entity (SecY) for which conformance to this standard is claimed shall: a) Support the Controlled and Uncontrolled Ports, and use a M P *1 Common Port as specified in Clause 10. b) Support the MAC status and point-to-point parameters for the M M Controlled and Uncontrolled Ports as specified in Clauses 6.4, 6.5 and 10.7. c) Process Transmit requests from the Controlled Port as required M M by the specification of Secure Frame Generation (Clause 10.5). d) Process Receive indications from the Common Port as M M required by the specification of Secure Frame Verification (Clause 10.6) prior to causing receive indications at the Controlled Port. e) Encode and decode MACsec PDUs as specified in Clause 9. M M f) Use a globally unique 48-bit MAC Address and a 16-bit Port M M Identifier unique within the scope of that address assignment 89 of 100
Ver. 0.5 Conformance IEEE ESS to identify the transmit SCI as specified in Clause 8.2.1.
g) Satisfy the performance requirements specified in Table 10-1 M M and Clause 8.2.2. h) Support the Layer Management Interface (LMI) operations M M required by the Key Agreement Entity (KAY) as specified in Clause 10. i) Provide the management functionality specified in Clause M M 10.7. j) Protect and validate MACsec PDUs by using Cipher Suites as M P*2 specified in Clause 14.1. k) Support Integrity Protection using the Default Cipher Suite M P*2 specified in Clause 14. l) For each Cipher Suite implemented, support a minimum of:
1) One receive SC. M M
2) Two receive SAKs. M M
3) One of the two Receive SAKs at a time for M M transmission, with the ability to change from one to the other within the time specified in Table 10-1. m) Specify the following parameters for each Cipher Suite implemented: 1) The maximum number of receive SCs supported. M M
2) The maximum number of receive SAKs. M M
An implementation of a MAC Security Entity (SecY) for which conformance to this standard is claimed shall not: n) Introduce an undetected frame error rate greater than that M M achievable by preserving the original FCS as required by Clause 10.4. o) Implement any Cipher Suite that is additional to those M M specified in Clause 14 and does not meet all the criteria specified in Clauses 14.2, 14.3 and 14.4.1. p) Support access to MACsec parameters using any version of M N SNMP prior to v3. An implementation of a MAC Security Entity (SecY) for which full conformance to this standard is claimed shall not: q) Implement Cipher Suites other than those specified in Clause M M 14. FROM: IEEE Std. 802.1AE-2006 Clauses 5.4 An implementation of a SecY for which conformance to this standard is claimed may a) Support network management using the MIB specified in O M Clause 13. b) Support access to the MIB specified in Clause 13 using SNMP O O version V3 or higher. c) Support more than one receive SC. O O
90 of 100
Ver. 0.5 Conformance IEEE ESS d) Support more than two receive SAKs. O O
e) Support Confidentiality Protection using the Default Cipher O Conditional Suite without a confidentiality offset as specified in Clause 14. M*4 f) Support Confidentiality Protection using the Default Cipher O Conditional Suite with a confidentiality offset as specified in Clause 14. M*4 g) Include Cipher Suites that are specified in Clause 14 in O O addition to the Default Cipher Suite. An implementation of a MAC Security Entity (SecY) for which conformance with Cipher Suite variance is claimed may h) Use Cipher Suites not specified in Clause 14, but meeting the O O*2 criteria specified in Clauses 14.2, 14.3 and 14.4.1. FROM: P802.1AEbn/D0.7 An implementation of a MAC Security Entity (SecY) for which O O*3 conformance with Cipher Suite is claimed may support GCM-AES- 256. FROM: IEEE Std. 802.1X-2010 Clauses 5.3-5.20 A port for which conformance to this standard is claimed shall M M*5 implement the mandatory functions of the Port Access Entity (PAE) and the mandatory functionality for at least one of the following PAE functions: Supplicant. Authenticator. MACsec Key Agreement (MKA). That port may also implement the mandatory functionality for all or O M any of the following PAE functions: Announcement transmission. Announcement reception. SNMP access to the PAE MIB. A port that implements Authenticator of MKA functionality may also O N*6 implement the mandatory functionality for the following PAE function: Virtual ports. A port may implement the optional functionality for any function for O O which the mandatory functionality has been implemented. The operation of one or more MAC Security Entities can be required M M*7 to secure communication for each port. A port that does not implement a SecY shall implement the PAC. Any implementation that is claimed to conform to this standard shall M M not violate the provisions of Clause 5.22. A PAE shall:
a) Encode, decode, address, and validate EAPOL PDUs as M P*8 specified in Clause 11. b) Transmit group addressed EAPOL PDUs using one, and only M M one, of the destination addresses specified in Table 11-1. c) Implement the Logon Process functionality specified in Clause M M 12.5. 91 of 100
Ver. 0.5 Conformance IEEE ESS d) Implement the CP state machine as specified in Clause 12.4. M M
e) Maintain and allow retrieval of the EAPOL frame reception M M statistics specified in Clause 12.8.1. f) Maintain and allow retrieval of the EAPOL frame reception M M diagnostics specified in Clause 12.8.2. g) Maintain and allow retrieval of the EAPOL frame transmission M M statistics specified in Clause 12.8.3. h) Support the system configuration functions specified in Clause M M 12.9. A PAE that supports both EAP (Supplicant or Authenticator) and MKA functionality shall: i) Derive a CAK from each EAP MSK, and a corresponding Conditional Conditional CKN for the corresponding EAP session ID as specified in M M 6.2.2. A claim that an implementation conforms to this standard shall specify
j) The group address used to transmit group addressed PDUs. If M M the implementation can be configured in a way that changes the address used, that configuration shall be specified. A PAE shall not
k) Use a MACsec protected Controlled Port to transmit EAPOL M M Packet Types other than EAPOL-Announcement (Clause 10.2). If PAE is implemented with Supplicant functionality, port shall
a) Use EAP as an authentication protocol, exhibiting external Conditional Conditional behavior consistent with an implementation of the Supplicant M M PACP state machine, state machine variables, procedures, and interfaces specified in Clause 8. b) Not use any EAP method that fails to meet the requirements Conditional Conditional specified in Clause 8.11. M M If PAE Supplicant functionality is implemented and integrated with IEEE Std. 802.1AR-2009, port shall a) Implement the EAP method EAP-TLS as specified in 8.11.2. Conditional Conditional M M If PAE is implemented with Authenticator functionality, port shall
a) Use EAP as an authentication protocol, exhibiting external Conditional Conditional behavior consistent with an implementation of the M M Authenticator PACP state machine, state machine variables, procedures, and interfaces specified in Clause 8. b) Not use any EAP method that fails to meet the requirements Conditional Conditional specified in Clause 8.11. M M c) Allow remote configuration of the reAuthEnabled and Conditional Conditional reAuthPeriod parameters specified in 8.6 and 8.9. M M An Authenticator port may: a) Maintain and allow retrieval of the Authenticator PAE Conditional Conditional diagnostic counters specified in 8.10. O O 92 of 100
Ver. 0.5 Conformance IEEE ESS If PAE Authenticator functionality is implemented and integrated with IEEE Std. 802.1AR-2009, port shall a) Implement the EAP method EAP-TLS as specified in 8.11.2. Conditional Conditional M M If PAE that supports MKA shall
a) Be capable of maintaining 2 or more simultaneous MKA Conditional M instances as specified in Clause 9. M b) Specify the maximum number of simultaneous MKA instances Conditional M it supports. M c) Create, delete, and activate MKA participants as specified in Conditional M Clauses 9.13 and 9.16. M d) Be capable of receiving and using Group CAKs distributed by Conditional O a Key Server. M e) Meet the requirements for MKA parameter encoding and for Conditional M MKPDU validation, encoding and decoding, specified in M Clause 11.11. f) Be capable of using 128 bit CAKs and derived keys as Conditional O specified in Clauses 6.2 and 9.3. M g) Observe the restrictions on the use and disclosure of each CAK Conditional M and derived keys specified in Clauses 6.2 and 9.16. M h) Protect each distributed CAK and SAK by AES Key Wrap, as Conditional M specified in Clauses 9.8.2 and 9.12.1. M i) Include the parameters of EAPOL-Announcements in Conditional M MKPDUs, as specified in Clause 9.13. M A PAE that supports MKA may
a) Be capable of using a 256 CAK and derived keys as specified O O*3 in Clauses 6.2 and 9.3. A PAE that supports Pre-Shared Keys (PSKs) shall:
a) Support the configuration of PSKs in the CAK cache as Conditional Conditional specified in Clauses 6.3.3 and 12.6. M M A PAE that supports Group CAs as an MKA Key Server
a) Shall be capable of operating as an MKA Key server. Conditional Conditional M M b) If support for EAP Authenticator functionality is claimed, it Conditional Conditional shall be capable of distributing a group CAK using MKA with M M EAP derived pairwise CAKs (Clauses 6.2, 9.12). c) If support for PSKs is claimed, it shall be capable of Conditional Conditional distributing a group CAK using an MKA instance with a PSK M M (Clauses 6.2, 6.3.3, 9.12). A PAE that implements a CAK Cache shall
a) Associate a lifetime with each cached CAK, deleting the CAK Conditional Conditional when that lifetime has expired as specified in Clause 12.6. M M b) Associate a CKN, KMD, NID, and other relevant authorization Conditional Conditional information with each cached CAK, as specified in Clause M M 12.6.
93 of 100
Ver. 0.5 Conformance IEEE ESS c) Cache group CAKs distributed by an MKA Key Server as Conditional Conditional specified in Clause 12.6. M M d) If support for EAP Authenticator or EAP Supplicant Conditional Conditional functionality is claimed, shall be capable of caching pairwise M M CAKs derived from EAP exchanges. A PAE that implements a CAK Cache shall not
e) Cache a CAK derived from an EAP exchange if that is Conditional Conditional prohibited by Clause 12.6. M M f) Distribute a KMD for a Group CAK unless the PAE Conditional Conditional distributed the CAK when acting as a Key Server as specified M M in 12.6. A PAE that supports the use of virtual ports shall
a) Specify the number of virtual ports that can be supported for Conditional N*6 each real port, or for the system as a whole. M b) Implement MKA functionality, and be capable of operating 2 Conditional N*6 or more simultaneous MKA instances for each of the specified M number of virtual ports. c) Support each virtual port with a SecY. Conditional N*6 M d) Create and manage virtual ports as specified in Clauses 6.3.6, Conditional N*6 9.14, 12.7. M e) Shall not create or maintain virtual ports if Supplicant Conditional N*6 functionality is enabled for the real port. M A PAE that supports both virtual ports and Authenticator functionality shall
f) Be capable of supporting at least the same number of Conditional Conditional simultaneous EAP Exchanges as the number of virtual ports M M supported. A PAE implementation that creates virtual ports in a system that bridges frames to and from those ports as specified by IEEE Std. 802.1D-2004 or IEEE Std. 802.1Q-2005 shall g) Support each of those virtual ports as specified by that Conditional N standard (IEEE Std. 802.1D-2004 or IEEE Std. 802.1Q-2005, M as applicable) for each Bridge Port, including support for Spanning Tree Protocol (Clause 7.6). A PAE implementation that transmits EAPOL-Announcements shall
a) Support the use of the null NID and zero or more additional Conditional Conditional NIDs as specified in Clause 10. M M b) Be capable of using the Uncontrolled Port to transmit generic Conditional Conditional EAPOL-Announcements containing the information for each M M supported NID, as specified in Clauses 10.1 and 10.2. c) Encode EAPOL-Announcements as specified in Clause 11.12. Conditional Conditional M M d) Rate limit the transmission of announcements as specified in Conditional Conditional Clause 10.2 M M A PAE implementation that transmits EAPOL-Announcements shall not
94 of 100
Ver. 0.5 Conformance IEEE ESS e) Transmit EAPOL-Announcements through an unsecured Conditional Conditional Controlled Port (Clause 10.2). M M A PAE implementation that listens to EAPOL-Announcements shall a) Interpret each received EAPOL-Announcement as specified in Conditional Conditional Clause 11 and Clause 10. M M b) Be capable of using a received EAPOL-Announcement to Conditional Conditional select one of more NIDs, each representing a network of M M network service, and using the authentication procedure or procedures advertised for that NID subject to the applicable Logon Process controls as specified in Clauses 10 and 12.5. c) Be capable of soliciting an EAPOL-Announcement by Conditional Conditional transmitting an EAPOL-Announcement-Req as specified in M M Clause 11.13. d) Be capable of encoding a Packet Body in an EAPOL- Conditional Conditional Announcement-Req, including TLVs to select a NID, as M M specified in Clause 11.13. e) Be capable of selecting an appropriate credential, for Conditional Conditional authentication for access to a desired NID, for use by the M M PAE‘s Supplicant (if implemented). f) Be capable of being configured so as to ignore a received Conditional Conditional EAPOL-Announcement for all NIDs. M M A Supplicant implementation that listens to EAPOL-Announcements shall
g) Be capable of encoding a Packet Body in an EAPOL-Start, Conditional Conditional including TLVs to select a NID, as specified in Clause 11.6. M M An implementation that is claimed to conform to the provisions of this standard for access to the PAE MIB using SNMP shall a) Support access to the MIB module specified in Clause 13 Conditional M using SNMP version v3 or higher. M A PAC implementation shall
a) Provide an Uncontrolled Port, for use by the PAE, and a Conditional N/A Controlled Port as specified in Clause 6.4. M An ESS implementation shall
a) Support Suite B algorithms. N/A M
b) Support SNMPv3 in TLS mode. O M
c) Require TLS 1.2. O M
d) Use 256-bit Suite B cipher suite with EAP-TLS. N/A O*3
e) For every EAPoL announcement there must be an equivalent N/A M MKA announcement once the CA is established. f) Provide for address hiding. N/A F
g) Support Data Center bridging. N/A F
h) MKA parameter MACsec Capability (see IEEE Std. 802.1X- N/A M 2010 Table 1-6) shall be encoded either to a value of 2 or 3. 95 of 100
Ver. 0.5 Conformance IEEE ESS i) Access Information TLV Access Capabilities field (see IEEE N/A M Std. 802.1X-2010 Table 11-9) shall have bit 3 (EAP + MKA + MACsec) or bit 5 (MKA + MACsec) set unless implementing IKE where bit 6 (Higher Layer – WebAuth) or 8 (Vendor specific) is set. An ESS implementation shall not
l) MKA parameter MACsec Capability (see IEEE Std. 802.1X- N/A M 2010 Table 1-6) shall not be encoded either to a value of 0 or 1. m) Access Information TLV Access Capabilities field (see IEEE N/A M Std. 802.1X-2010 Table 11-9) shall not have bit 1 (EAP), bit 2 (EAP + MKA), bit 4 (MKA) or bit 7 (Higher Layer Fallback – WebAuth) set. Network Considerations for the ESS
n) MENs shall be configured to tunnel layer 2 control protocol to N/A M qualify as a virtual LAN for ESS purposes. M – Mandatory O – Optional N – Not Implemented N/A – Not applicable P – Partial implementation F – Future implementation Conditional M – Overall feature is optional, but if implemented the requirements are Mandatory NOTES: *1 – Except where superseded by IEEE Std. 802.1X-2010 or by the ESS: Figure 10-2 – superseded by IEEE Std. 802.1X-2010 Clause 6.1 NOTE on page 61. *2 – Some Government NSS EDE devices may not implement AES-128. *3 - GCM-AES-256 is mandatory for EDE devices that are intended to protect NSSs that contain TOP SECRET information. *4 – one of the two items needs to be Mandatory. *5 – MKA is mandatory for ESS. Supplicant and Authenticator are additional optional. *6 – Virtual Ports in ESS are not supported since Multi-Access LAN functionality does not work in the network core. *7 – All ports are required to implement SecY and are not allowed to implement a PAC entity in place of a SecY. *8 – only the MKA EAPOL PDUs are mandatory. Other EAPOL PDUs are optional. Table 4 - IEEE vs. ESS Conformance Requirements. For a future revision of this specification, a correlation of Protocol Implementation Conformance Statements (PICS) to the ESS shall be provided by the authors.
96 of 100
Ver. 0.5
6. Abbreviations and Acronyms AES Advanced Encryption Standard AN Association Number B-BEB Backbone Edge Bridge containing a B-Comp B-Comp B-Component B-DA Backbone Destination MAC Address B-SA Backbone Source MAC Address B-Tag Backbone VLAN Tag BEB Backbone Edge Bridge BER Bit Error Rate BFD Bidirectional Forwarding Detection C Changed Text Bit C-DA Customer Destination MAC Address C-SA Customer Source MAC Address C-Tag Customer VLAN Tag C-VID Customer VLAN Identifier C-VLAN Customer VLAN CE-Tag Customer Edge VLAN Tag CA secure Connectivity Association CAK secure Connectivity Association Key CBP Customer Backbone Port CE Customer Edge CFI Canonical Format Indicator CIS Cryptographic Interoperability Strategy CNSS Committee on National Security Systems CNP Customer Network Port COI Community of Interest CoS Class of Service CRC Cyclic Redundancy Check CRL Certificate Revocation List CSMA/CD Carrier Sense Multiple Access with Collision Detection DA Destination MAC Address DCB Data Center Bridging DCBx Data Center Bridging Exchange DEI Drop Eligible Indicator DevID Secure Device Identifier E Encryption Bit E-Line Ethernet Line E-LAN Ethernet LAN E-LMI Ethernet Local Management Interface E-Tree Ethernet Tree EAP Extensible Authentication Protocol ECC Elliptic Curve Cryptography ECDH Elliptic Curve Diffie-Hellman 97 of 100
Ver. 0.5 ECMP Equal Cost Multi-Path ECU End Cryptographic Units EDE Ethernet Data Encryption EEP Ethernet Encryption Program EISS Enhanced Internal Sub-layer Service EK Electronic Key EP-LAN Ethernet Private LAN EP-Tree Ethernet Private Tree EPL Ethernet Private Line EPON Ethernet Passive Optical Network ES End Station ESP Encapsulating Security Payload ESS Ethernet Security Specification ETS Enhanced Transmission Selection EVP-LAN Ethernet Virtual Private LAN EVC Ethernet Virtual Connection FCS Frame Check Sequence FIPS Federal Information Processing Standards FIPS PUB FIPS Publication GCKDF Generalized Concatenation Key Derivation Function GCM Galois/Counter Mode Gb/s Gigabit per second Gbps Gigabit per second GMT Greenwich Mean Time HMI Human Machine Interface HTTP Hypertext Transfer Protocol I-BEB Backbone Edge Bridge containing an I-Comp I-Comp I- Component I-SID Backbone Service Instance Identifier I-Tag Backbone Service Instance VLAN Tag IASRD Information Assurance Security Requirement Document IC Intelligence Community ICV Integrity Check Value IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IFG Inter Frame Gap IKE Internet Key Exchange IKEv2 IKE version 2 IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISO International Organization of Standardization ISS Internal Sublayer Service IV Initialization Vector KaY MAC Security Key Agreement Entity KEK Key Encryption Key KMI Key Management Interface L2TPv3 Layer Two Tunneling Protocol – Version 3 98 of 100
Ver. 0.5 LACP Link Aggregation Control Protocol LAG Link Aggregation Group LAN Local Area Network LLC Logical Link Control LSb Least Significant bit MAC Media Access Control MAC/PLS Media Access Control/Physical Layer Specification MACsec Media Access Control Security MAN Metropolitan Area Network MEF Metro Ethernet Forum MEN Metro Ethernet Network MIB Management Information Base MKA MACsec Key Agreement Protocol MKPDU MACsec Key Agreement Protocol Data Unit MPDU MACsec Protocol Data Unit MPLS Multiprotocol Label Switching MPLS LSP MPLS Lable Switched Paths MSDU MAC Service Data Unit MSb Most Significant bit MSK Master Session Key NSA National Security Agency NSS National Security System NIST National Institute of Standards and Technology OAM Ethernet Operations, Administration and Maintenance OCSP Online Certificate Status Protocol OLT Optical Line Terminator OM3 Optical Multimode 3 fiber ONU Optical Network Unit OTAR Over The Air Rekey OTN Optical Transport Network OTNK Over-the-Network-Keying P2P Point to Point PAC Port Access Controller PAE Port Access Entity PBB Provider Backbone Bridge PBBN Provider Backbone Bridge Network PBC Per Block Counter PBN Provider Bridge Network PCP Priority Code Point PDU Protocol Data Unit PFC Priority-based Flow Control PHY Physical Layer PICS Protocol Implementation Conformance Statement PIP Provider Instance Port PLS Physical Layer Signaling PN Packet Number PNP Provider Network Port PPK Pre-Placed Key 99 of 100
Ver. 0.5 PSK Pre-Shared Key QoS Quality of Service RFC Request for Comments S-I-R Sender-Intermediary-Receiver S-Tag Service VLAN Tag S-VID Service VLAN Identifier S-VLAN Service VLAN SA Secure Association SA Source MAC Address SAI Secure Association Identifier SAK Secure Association Key SC Secure Channel SCB Secure Channel Broadcast SCI Secure Channel Identifier SecTAG MAC Security TAG SecY MAC Security Entity SHA Secure Hash Algorithm SID Service Identifier SMI Structure of Management Information SMIv2 SMI version 2 SNMP Simple Network Management Protocol SNMPv3 SNMP version 3 SP Special Publication Tb/s Terabits per second Tbps Terabits per second TCI Tag Control Information TEK Traffic Encryption Key TLS Transport Layer Security TPID Tag Protocol Identifier TRILL Transparent Interconnection of Lots of Links TSRD Tailored Information Assurance Security Requirement Document UCA Use Customer Addresses UNI User-Network Interface USM User-based Security Model VACM View-based Access Control Model VID VLAN Identification VLAN Virtual Local Area Network WADL Web Application Description Language WAN Wide Area Network
100 of 100