Ports

On 7210 SAS devices, a port must be configured as one of the following: access, access uplink, network, or hybrid. The following list describes the significance of the different port modes and the support available on different platforms:

• access ports

  Access ports are configured for customer-facing traffic on which services are configured. If a Service Access Port (SAP) is to be configured on the port, it must be configured as an access port. When a port is configured for access mode, the appropriate encapsulation type must be configured to distinguish the services on the port. When a port has been configured for access mode, one or more services can be configured on the port depending on the encapsulation value.

• access-uplink ports

  Access-uplink ports are used to provide native Ethernet connectivity in service provider transport or infrastructure network. This can be achieved by configuring port mode as access uplink. With this option, the encap-type can be configured to QinQ only. Access-uplink SAPs, which are QinQ SAPs, can only be configured on an access uplink port to allow the operator to differentiate multiple services being carried over a single access uplink port.

• network ports (applicable only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

  Network ports are configured for network-facing traffic. These ports participate in the service provider transport or infrastructure network. Dot1q is supported on network ports.

• hybrid ports (applicable only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

  Hybrid ports are configured for access and network-facing traffic. The default mode of an Ethernet port is ‟network”. The mode of a port cannot be changed unless the port is shut down and the configured SAPs and interfaces are deleted. Hybrid ports allow a single port to operate in both access and network modes. The MTU of a port in hybrid mode is the same as in network mode. The default encapsulation for ports in hybrid mode is dot1q; QinQ encapsulation is also supported at the port level.

  When the port is changed to hybrid, the default MTU of the port is changed to match the value of 9212 bytes, which is used in network mode (higher than in access mode); this ensures that both SAP and network VLANs can be accommodated.

  The only exception is when the port is a 10/100 fast Ethernet port. In this case, the MTU in hybrid mode is set to 1522 bytes, which corresponds to the default access MTU with QinQ, which is larger than the network dot1q MTU or access dot1q MTU for this type of Ethernet port. All parameters in access and network contexts are configured within the port using the same CLI hierarchy as in the existing implementation. A hybrid port allows both ingress and egress contexts to be configured concurrently.

  An Ethernet port configured in hybrid mode can have the following encapsulation type values: dot1q and QinQ. The NULL value is not supported because only a single SAP or network IP interface is allowed, achieved by configuring the port as either access or network, respectively. Hybrid mode can be enabled on a LAG port when the port is part of a single chassis LAG configuration. When the port is part of a multi-chassis LAG (MC-LAG) configuration, only access mode can be configured. MC-LAG is not supported on network ports and consequently cannot be supported on hybrid ports.

The following table describes supported port modes on the 7210 SAS platforms.

The 7210 SAS supports an option to allow the user to use a different dot1q VLAN Ethernet Type (Etype). It allows for interoperability with third-party switches that use some non-standard (other than 0x8100) dot1q VLAN Etype.

The following are the configuration guidelines for Dot1q-Etype configured for dot1q encap port on 7210 SAS-D and 7210 SAS-Dxp:

• Dot1q-Etype configuration is supported for all ports - Access and Access-uplink ports.

• Dot1q-preserve SAPs cannot be configured on dot1q encap ports configured to use ether type other than 0x8100.

• Priority tagged packet received with Etype 0x8100 on a dot1q port configured with Etype 0x9100 are classified as priority tagged packet and mapped to a dot1q :0 SAP (if configured) and the priority tag is removed.

• Priority tagged packets received with Etype 0x6666 (any value other than 0x8100) on a dot1q port configured with Etype 0x9100 is classified as null-tagged packet and mapped to a dot1q :0 SAP (if configured) and the priority tag is retained and forwarded.

• The dot1q-Etype is modified only for the dot1q encap access port.

The following configuration notes apply for PoE:

• On the 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p, all ports are available to connect PoE and PoE+ devices, and up to four fixed copper ports are available to connect PoE++ and HPoE devices.

• The 7210 SAS-Dxp 16p and 7210 SAS-Dxp 24p can be equipped with the following external power module types to support required PoE devices:

  • 100 W AC

  • 290 W DC

  • 480 W AC

  • 960 W AC

• The user can configure the maximum power budget for PoE devices using the config>system>poe>max-poe-power-budget command. See the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Basic System Configuration Guide for more information about this command.

The 802.1AE header has a security tag (SecTAG) which includes:

• the association number within the channel

• the packet number to provide a unique initialization vector for encryption and authentication algorithms, as well as protection against replay attack

• an optional LAN-wide secure channel identifier

The SecTAG is identified by the MACsec Ethertype and includes the following fields:

• TAG Control Information (TCI)

• Association Number (AN)

• Short Length (SL)

• Packet Number (PN)

• Optionally-encoded Secure Channel Identifier (SCI)

The following figure shows the format of the SecTAG.

MACsec uses the following main modes of encryption:

• VLAN in cleartext (WAN Mode)

• VLAN encrypted

The 802.1AE standard requires that the 802.1Q VLAN is encrypted. Some vendors provide the option of configuring MACsec on a port with VLAN in cleartext form. The 7210 SAS-K 2F6C4T, 7210 SAS-K 3SFP+ 8C, and 7210 SAS-Dxp 24p support both modes on both 1GE and 10GE ports.

The following figure shows VLAN in encrypted and cleartext form.

The following table describes MACsec terminology.

The following table describes the key management modes in MACsec.

The following figure shows the main MACsec concepts used in the static CAK scenario.

MACsec uses SAs to encrypt packets. Each SA has a single SAK that contains the cryptographic operations used to encrypt the datapath PDUs.

The SAK is the secret key used by an SA to encrypt the channel.

When enabled, MACsec uses a static CAK security mode, which has two security keys: a CAK that secures control plane traffic and a randomly generated SAK that secures data plane traffic. Both keys are used to secure the point-to-point or point-to-multipoint Ethernet link and are regularly exchanged between devices on each end of the Ethernet link.

The following figure shows MACsec generating the CAK.

The node initially needs to secure the control plane communication to distribute the SAKs between two or more members of a CA domain.

The control plane is secured using a CAK, which is generated using one of the following methods:

• EAPoL

• preshared key

  (CAK and CKN values are configured using the CLI). The following CAK and CKN rules apply.

  • CAK uses 32 hexadecimal characters for a 128-bit key, and 64 hexadecimal characters for a 256-bit key, depending on the algorithm used for control plane encryption; for example, aes-128-cmac or aes-256-cmac.

  • CKN is a 32-octet character (64 hex) and is the name that identifies the CAK. This allows each of the MKA participants to select which CAK to use to process a received MKPDU. MKA places the following restrictions on the format of the CKN:

    • it must comprise an integral number of octets, between 1 and 32 (inclusive)

    • all potential members of the CA must use the same CKN

  • CAK and CKN must match on peers to create a MACsec-secure CA.

The following figure shows MACsec control plane authentication and encryption.

After the CAK is generated, it can obtain the following additional keys:

• KEK (Key Encryption Key)

  The KEK is used to wrap and encrypt the SAKs.

• ICK (Integrity Connection Value (ICV) Key)

  The ICK is used for an integrity check of each MKPDU send between two CAs.

The key server then creates a SAK and shares it with the CAs of the security domain, and that SAK secures all data traffic traversing the link. The key server periodically creates and shares a randomly created SAK over the point-to-point link for as long as MACsec is enabled.

The SAK is encrypted using the AES-CMAC, the KEK as the encryption key, and ICK as the integration key.

The SAK is regenerated after the following events:

• when a new host has joined the CA domain and MKA hellos are received from this host

• when the sliding window is reaching the end of its 32-bit or 64-bit length

• when a new PSK is configured and a rollover of PSK is executed

Each MACsec peer operates the MKA. Each node can operate multiple MKAs based on the number of CAs that it belongs to. Each instance of MKA is protected by a distinct secure CAK, that allows each Port Access Entity (PAE), or port, to ensure that information for a specific MKA instance is accepted only from other peers that also possess that CAK, therefore identifying themselves as members or potential members of the same CA. For a description of how the CAK identification is performed using CKN, see MACsec static CAK.

The IEEE 802.1x-2010 standard identifies the following fields in the MKA PDU:

• MACsec Capability

• Desire

MACsec capability signals whether MACsec is capable of integrity and confidentiality. For information about the basic settings for MACsec capability, see the encryption-offset command description.

Encryption offset of 0, 30, or 50 starts from the byte after the SecTAG (802.1AE header). Ideally, the encryption offset should be configured for IPv4 (offset 30) and IPv6 (offset 50) to leave the IP header in cleartext. This allows routers and switches to use the IP header for LAG or ECMP hashing.

The participants in an MKA instance that agree on a key server are responsible for the following:

• deciding on the use of MACsec

• cipher suite selection

• SAK generation and distribution

• SA assignment

• identifying the CA when two or more CAs merge

Each participant in an MKA instance uses the key server priority (an 8-bit integer) encoded in each MKPDU to agree on the key server. Each participant selects the live participant advertising the highest priority as its key server whenever the live peers list changes, provided that highest priority participant has not selected another as its key server or is unwilling to act as the key server.

If a key server cannot be selected, SAKs are not distributed. In the event of a tie for highest priority key server, the member with the highest priority SCI is chosen. For consistency with other uses of the SCI MAC address component as a priority, numerically lower values of the key server priority and SCI receive the highest priority.

Each MACsec device supports 64 Tx-SAs and 64 Rx-SAs. An SA (Security Association) is the key to encrypt or decrypt the data.

As defined in IEEE 802.1AE, each SecY contains an SC. An SC is a unidirectional concept; for example, Rx-SC or Tx-SC. Each SC contains at least one SA for encryption on Tx-SC and decryption on Rx-SC. Also, for extra security, each SC should be able to roll over the SA, therefore, Nokia recommends for each SC to have two SAs for rollover purposes.

MACsec PHY is known as a MACsec security zone. Each MACsec security zone supports 64 Tx-SAs and 64 Rx-SAs. Assuming two SAs for each SC for SA rollover, each zone supports 32 Rx-SCs and 32 Tx-SCs.

The following table describes the port mapping to security zones.

In a point-to-point topology, each router needs a single security zone, a single Tx-SC for encryption, and a single Rx-SC for decryption. Each SC has two SAs. In total, for point-to-point topology, four SAs are needed: two Rx-SAs for Rx-SC1 and two Tx-SAs for Tx-SC1.

The following figure shows the P2P topology.

In a multi-point topology with N nodes, each node needs a single Tx-SC and N Rx-SC, one for each one of the peers. As such, 64 maximum Rx-SAs for each security zone translates to 32 Rx-SCs, which breaks down to only 32 peers; for example, only 33 nodes in the multipoint topology for each security zone. So from the perspective of each node, there is one Tx-SC and 32 Rx-SCs.

As shown in the following figure, when the 34th node joins the multi-point topology, the other 33 nodes that are already part of this domain do not have SAs to create an Rx-SC for this 34th node; however, the 34th node has a Tx-SC and can accept 32 peers. The 34th node starts to transmit and encrypt the PDUs based on its Tx-SC. However, because all other nodes do not have as SC for this SAI, all Rx PDUs are dropped.

Nokia recommends that a multicast domain, for a single security zone, should not exceed 32 peers, or the summation of all the nodes in a security zone CA domain should not exceed 33. This is the same as if a security zone has four CAs; the summation of all nodes in the four CAs should be 33 or less.

A security zone has 64 Rx-SAs and 64 Tx-SAs, as described in SA limits and network design. Two Rx-SAs are used for each Rx-SC for rollover purposes, and two Tx-SAs are used for Tx-SC for rollover purposes. This translates to 32 peers for each security zone.

Under each port, you can configure a max-peer command to assign the number of peers allowed on that port.

If the maximum peer is exceeded, the peer connectivity becomes random. In the case of a node failure or packet loss, peers join the CA randomly, on a first-come-first-served basis.

In most Layer 2 networks, MAC forwarding is done using a destination MAC address. The 802.1AE standard requires that any field after source and destination MAC address and after the SecTAG must be encrypted. This includes the 802.1Q tags. In some VLAN switching networks, it may be needed to leave the 802.1Q tag in cleartext form.

7210 SAS allows the configuration of 802.1Q tag in cleartext form by placing the 802.1Q tag before the SecTAG, or encrypts it by placing it after the SecTAG.

The following table lists the MACsec encryption of 802.1Q tags when the clear-tag is configured.

MACsec is an Ethernet packet and, as with any Ethernet packet, can be forwarded through multiple switches using Layer 2 forwarding. The encryption and decryption of the packets is done using the 802.1x (MKA) capable ports.

To ensure that the MKA is not terminated on an intermediate switch or router, enable 802.1x tunneling on the corresponding port.

Verify if tunneling is enabled using the following command.

*A:SwSim28>config>port>ethernet>dot1x# info 
----------------------------------------------
      tunneling

By enabling tunneling, the 802.1x MKA packets transit that port without being terminated, because such MKA negotiation does not occur on a port that has 802.1x tunneling enabled.

The MKA packets are transported over EAPoL with a multicast destination MAC address.

In cases where a point-to-point connection from the MKA to a peer node over a Layer 2 multihop cloud is required, you can set the EAPoL destination MAC address to the peer MAC address. This forces the MKA to traverse multiple nodes and establish an MKA session with the specific peer.

Mirroring is performed before MACsec encryption. Therefore, if a port is MACsec-enabled and is also mirrored, all the mirror packets are in cleartext form.