Ports

The following table lists the supported port speeds on 7705 SAR-Hx and 7705 SAR-Mx MDAs.

The following table lists the supported port speeds in each speed mode.

T1/E1 port configuration is available on the 8-port T1/E1 ASAP Adapter card supported on the 7705 SAR-Hx and 7705 SAR-Mx.

On T1/E1 ports, channelization is supported down to the DS0 level. To change port types, all ports must first be administratively disabled. The ports can be configured for T1 and E1 operations. When the first port on a card is configured, all other ports on the card must be set to the same type.

T1/E1 ports support only cem encapsulation.

This MDA is supported on the 7705 SAR-Hx and 7705 SAR-Mx.

On the 8-port RS-232 and C37.94 combination MDA, channelization is supported down to the DS0 level on the four RS-232 serial ports and four IEEE C37.94 teleprotection interface (TPIF) ports.

The RS-232 and C37.94 ports are used in critical networks for applications like SCADA and teleprotection.

The IEEE 802.1x standard defines three participants in an authentication conversation (see 802.1x architecture that shows an example with the 7705 SAR Gen 2).

the supplicant

the end-user device that requests access to the network

the authenticator

controls access to the network. Both the supplicant and the authenticator are referred to as Port Authentication Entities (PAEs).

the authentication server

performs the actual processing of the user information

The authentication exchange is carried out between the supplicant and the authentication server, the authenticator acts only as a bridge. The communication between the supplicant and the authenticator is done through the Extended Authentication Protocol (EAP) over LANs (EAPOL). On the back end, the communication between the authenticator and the authentication server is done with the RADIUS protocol. The authenticator is therefore a RADIUS client, and the authentication server a RADIUS server.

The messages involved in the authentication procedure are shown in 802.1x authentication scenario. The router initiates the procedure when the Ethernet port becomes operationally up, by sending a special PDU called EAP-Request/ID to the client. The client can also initiate the exchange by sending an EAPOL-start PDU, if it does not receive the EAP-Request/ID frame during bootup. The client responds on the EAP-Request/ID with a EAP-Response/ID frame, containing its identity (typically username + password).

After receiving the EAP-Response/ID frame, the router encapsulates the identity information into a RADIUS AccessRequest packet, and sends it off to the configured RADIUS server.

The RADIUS server checks the supplied credentials, and if approved returns an Access Accept message to the router. The router notifies the client with an EAP-Success PDU and puts the port in authorized state.

Nokia routers support port-based network access control for Ethernet ports only. Every Ethernet port can be configured to operate in one of three different operation modes, controlled by the port-control command:

• force authorized

  This mode disables 802.1x authentication and causes the port to transition to the authorized state without requiring any authentication exchange. The port transmits and receives normal traffic without requiring 802.1x-based host authentication. This is the default setting.

• force unauthorized

  This mode causes the port to remain in the unauthorized state, ignoring all attempts by the hosts to authenticate. The switch cannot provide authentication services to the host through the interface.

• auto

  This mode enables 802.1x authentication. The port starts in the unauthorized state, allowing only EAPOL frames to be sent and received through the port. Both the router and the host can initiate an authentication procedure as described below. The port remains in unauthorized state (no traffic except EAPOL frames is allowed) until the first client is authenticated successfully. After this, traffic is allowed on the port for all connected hosts.

The 802.1x authentication procedure is controlled by a number of configurable timers and scalars. There are two separate sets, one for the EAPOL message exchange and one for the RADIUS message exchange. See 802.1x EAPOL timers (left) and RADIUS timers (right) for an example of the timers on the 7750 SR.

EAPOL timers:

• transmit-period

  This timer indicates how many seconds the Authenticator listens for an EAP-Response/ID frame. If the timer expires, a new EAP-Request/ID frame is sent and the timer restarted. The default value is 60. The range is 1 to 3600 seconds.

• supplicant-timeout

  This timer is started at the beginning of a new authentication procedure (transmission of first EAP-Request/ID frame). If the timer expires before an EAP-Response/ID frame is received, the 802.1x authentication session is considered as having failed. The default value is 30. The range is 1 to 300.

• quiet-period

  This timer indicates number of seconds between authentication sessions. It is started after logout, after sending an EAP-Failure message or after expiry of the supplicant-timeout timer. The default value is 60. The range is 1 to 3600.

RADIUS timer and scalar:

• maximum authentication requests

  This scalar indicates the maximum number of times that the router sends an authentication request to the RADIUS server before the procedure is considered as having failed. The default value is value 2. The range is 1 to 10.

• server timeout

  This timer indicates how many seconds the authenticator waits for a RADIUS response message. If the timer expires, the access request message is sent again, up to maximum authentication request times. The default value is 60. The range is 1 to 3600 seconds.

The router can also be configured to periodically trigger the authentication procedure automatically. This is controlled by enabling re-authentication and re-authentication period. Re-authentication period indicates the period in seconds (since the last time that the authorization state was confirmed) before a new authentication procedure is started. The range of reauth-period is 1 to 9000 seconds (the default is 3600 seconds, one hour). Note that the port stays in an authorized state during the re-authentication procedure.

Tunneling of untagged 802.1x frames received on a port is supported for both Epipe and VPLS service using either null or default SAPs (for example 1/1/1:*) when the following command is configured:

• MD-CLI

  configure port ethernet dot1x port-control force-authorized

• classic CLI

  configure port ethernet dot1x port-control force-auth

When tunneling is enabled on a port, untagged 802.1x frames are treated like user frames and are switched into Epipe or VPLS services which have a corresponding null SAP or default SAP on that port. In the case of a default SAP, it is possible that other non-default SAPs are also present on the port. Untagged 802.1x frames received on other service types, or on network ports, are dropped. Use the following command to enable tunneling on a port.

configure port port-id ethernet dot1x tunneling

When tunneling is required, it is expected that it is enabled on all ports into which 802.1x frames are to be received. The configuration of dot1x must be configured consistently across all ports in LAG as this is not enforced by the system.

Note that 802.1x frames are treated like user frames, that is, tunneled, by default when received on a spoke or mesh SDP.

Per-host authentication enables SR OS to authenticate each host individually and allows or disallows the PDUs from this host through the port. Per-host authentication is configurable using the CLI.

When dot1x tunneling is disabled, the port does not allow any PDUs to pass through, with the exception of dot1x packets, which are extracted.

When per-host-authentication is configured on the port for dot1x, each host is authenticated individually according to the RADIUS policy and host traffic is allowed or disallowed through the port. After the first successful host authentication, the behavior is the following:

• On downstream (that is, traffic from the network to the host), the port is authorized and allows all traffic to go through.

• On upstream (that is, traffic from the host to the network), the port is authorized, but allows through traffic from the authenticated hosts only. When the host is allowed through the port, all PDUs for that host are allowed to pass through the port, including untagged or tagged packets. The traffic from any unauthenticated host is disallowed.

For per-host authentication, EAPOL packets are sent to the RADIUS server using the RADIUS protocol. The calling station identifier is the source MAC address of the host and is usually present in the packet. The identifier is used to allow or disallow the host source MAC address based on the RADIUS success or failure answer.

The hosts are authenticated periodically. If a host is authenticated and placed on the allow list and a subsequent authentication fails, that host is removed from the allow list.

If a host authenticates unsuccessfully multiple times, that host is put on a disallow list for a specific amount of time. That is, enabling per-host authentication provides per-host (source MAC) DoS mitigation.

Duplicate MAC addresses are not allowed on the port.

All logs display per-host authentication.

Configuration of 802.1x network access control on the router consists of two parts:

• generic command options, which are configured under configure system security dot1x

• port-specific command options, which are configured under configure port ethernet dot1x

The following considerations apply:

• If per-host authentication is not configured, the authentication of any host on the port provides access to the port for any device, even if only a single client has been authenticated.
• 802.1x authentication can only be used to gain access to a pre-defined Service Access Point (SAP). It is not possible to dynamically select a service (such as a VPLS service) depending on the 802.1x authentication information.
• If 802.1x access control is enabled and a high rate of 802.1x frames are received on a port, that port is blocked for a period of 5 minutes as a DoS protection mechanism.

The MACsec 802.1AE header includes a security TAG (SecTAG) field that contains the following information:

• association number within the channel

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

• optional LAN-wide secure channel identifier

The SecTAG field, which is identified by the MACsec EtherType, conveys the following information:

• 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 field.

The main modes of encryption in MACsec are:

• VLAN in cleartext (WAN Mode)

• VLAN encrypted

802.1AE dictates that the 802.1Q VLAN must be encrypted. Some vendors provide the option of configuring the MACsec on a port with VLAN in cleartext.

SR OS supports both modes.

The following figure shows the encrypted VLAN and the VLAN in cleartext.

The following table describes the main key management modes in MACsec.

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

The following table describes MACsec terminology.

MACsec uses SAs to encrypt packets. SA is a security relationship that provides security guarantees for frames transmitted from one member of a CA to the others. Each SA contains a single secret key (SAK) used to perform the cryptographic operations that encrypt the datapath PDUs.

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

When enabled, MACsec uses a static CAK security mode. Two security keys, a connectivity association key (CAK) that secures control plane traffic, and a randomly generated secure association key (SAK) that secures data plane traffic, are used to secure the point-to-point or point-to-multipoint Ethernet link. Both keys are regularly exchanged between both devices on each end of the Ethernet link to ensure link security.

The following figure shows MACsec generating the CAK.

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

The CAK is used to secure the control plane. The following main methods are used to generate the CAK:

• EAPoL (SR OS does not support EAPoL)

• pre-shared key (CAK and CKN values are configured manually using the CLI). The following CAK and CKN rules apply:

  • CAK has 32 hexadecimal characters for a 128-bit key and 64 hexadecimal characters for a 256-bit key, depending on which algorithm is used for control plane encryption (for example, aes-128-cmac or aes-256-cmac).

  • CKN has 32 octets char (64 hex) and is the connectivity association key name, which identifies the CAK. This allows each MKA participant to select which CAK to use to process a received MKPDU. MKA places no restriction on the format of the CKN, except that it must comprise an integral number of octets, between 1 and 32 (inclusive), and that all potential members of the CA use the same CKN.

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

The following figure shows the MACsec control plane authentication and encryption.

A generated CAK can obtain the following additional keys:

• Key Encryption Key (KEK) – key used to wrap and encrypt the SAKs

• Integrity Connection Value (ICV) Key (ICK) – key used for an integrity check of each MKPDU sent between two CAs

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

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

SR OS regenerates the SAK 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 preshared key (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 the node belongs to. Each MKA instance is protected by a distinct secure CAK, which allows each PAE to ensure that information for an MKA instance is accepted only from other peers that also possess that CAK, which identifies the peers as members or potential members of the same CA. See MACsec static CAK for information about the CAK identification process performed via CKN.

MKA protects the integrity of MKPDUs and secures the SAK using keys that are derived from the CAK. The CAK and CKN are configured as part of a PSK entry under the static CAK configuration.

SR OS supports the following methods for configuring a static CAK:

• active PSK index

  Two PSK entries identified by indexes 1 and 2. The active PSK selects the PSK entry that is used for the MKA session. This method uses a single MKA session. Each time the active PSK is rotated, the CKN and the derived keys are replaced for the same MKA session. A new PSK does not instantiate a new MKA session.

• a keychain where the SR OS keychain infrastructure is used

  A keychain contains multiple key entries, where each key entry corresponds to a PSK that is active from its configured begin time up to the next key entry's begin time plus a configurable tolerance. With this method, every key entry rotation (PSK rotation) instantiates a new MKA session that is named by the CKN and secured by keys derived from the CAK configured in the key entry (PSK). The previous MKA session bound to the old key entry is deleted when its key entry tolerance expires. See Keychain interaction with MACsec for more information about MACsec usage with keychains.

MKA uses a member identifier (MI) for each node in the CA domain.

A participant proves liveness to each of its peers by including its MI, together with an acceptably recent message number (MN), in an MKPDU.

To avoid a new participant having to respond to each MKPDU from each partner as it is received, or trying to delay its reply until it is likely that MI MN tuples have been received from all potential partners, each participant maintains and advertises both of the following:

• live peers list

  This list includes all the peers that have included the participant MI and a recent MN in a recent MKPDU.

• potential peers list

  This list includes all the other peers that have transmitted an MKPDU that was directly received by the participant or that were included in the live peers list of an MKPDU transmitted by a peer that has proved liveness.

Peers are removed from each list when an interval of between MKA Life Time and MKA Life Time plus MKA Hello Time has elapsed since the participant's recent MN was transmitted. This time is sufficient to ensure that two or more MKPDUs have been lost or delayed prior to the incorrect removal of a live peer.

The following table describes the MKA participant timer values used on SR OS.

802.1x-2010 had identified the following fields in the MKA PDU:

• MACsec Capability

• Desire

MACsec Capability signals whether MACsec is capable of integrity and confidentiality. The following table describes the basic settings for MACsec Capability.

An 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 agree on a Key Server and 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 the 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 the 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 are afforded the highest priority.

Each MACsec device supports 64 TX-SAs and 64 RX-SAs. An SA is the key to encrypt or decrypt the data.

In accordance with the IEEE 802.1AE standard, each SecY contains an SC, which 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. For extra security, each SC should be able to roll over the SA. The system allocates resources for two SAs on each SC for rollover purposes, as defined in the standard.

Each MACsec phy, referred to as a MACsec security zone, supports 64Tx-SAs and 64 RX-SAs. Assuming two SAs per SC for SA rollover, each security zone supports 32 RX-SC and 32 TX-SC.

The following table describes the port mapping to security zones.

In a point-to-point (P2P) topology, each router needs a single security zone and a single Tx-SC for encryption, and a single Rx-SC for decryption. Each SC has two SAs. In total, for P2P topology, four SAs are needed: two RxSAs for RxSC1 and two TXSAs for TxSC1. The following figure shows the P2P topology.

In a multipoint topology with N nodes, each node needs a single TxSC and N RxSC, one for each of the peers. For example, 64 maximum RX-SAs per security zone translates to 32 Rx-SCs, which breaks down to only 32 peers (only 33 nodes in the multipoint topology per security zone, where each node has one TxSC and 32 RxSC).

In the preceding figure, when the 34th node joins the multipoint topology, the other 33 nodes that are already part of this domain do not have SAs to create an RxSC for the 34th node. However, the 34th node has a TxSC and accepts 32 peers. The 34th node starts transmitting and encrypting the PDUs based on its TxSC. However, because the other nodes do not have an SC for this SAI, they drop all Rx PDUs.

SA limits and network design describes that a security zone has 64 RxSAs and 64 TxSAs. Two RxSAs are used for each RxSC for rollover purposes, and two TxSAs are used for TxSC for rollover purposes. This translates to 32 peers per security zone.

Under each port, users can configure the maximum number of peers allowed on that port.

In most Layer 2 networks, MAC forwarding is performed via the destination MAC address. The 802.1AE standard dictates that any field after the 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 necessary to leave the 802.1Q tag in cleartext.

SR OS supports configuring 802.1Q tags in cleartext by placing the 802.1Q tag before the SecTAG, or in encrypted text by placing it after the SecTAG.

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

MACsec is an Ethernet packet and, as with any other Ethernet packet, can be forwarded through multiple switches via Layer 2 forwarding. Packet encryption and decryption is performed via 802.1x (MKA) capable ports.

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

The following example shows how to check if tunneling is enabled.

[ex:/configure port 1/1/12 ethernet dot1x]
A:admin@node-2# info
    tunneling true

A:node-2>config>port>ethernet>dot1x# info 
----------------------------------------------
      tunneling

The MKA packets are transported over EAPoL with a multicast destination MAC address. If it is required for the MKA have a point-to-point connection to a peer node over a Layer 2 multihop cloud, the EAPoL destination MAC address can be set 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 the MACsec encryption engine. Therefore, if a port is MACsec-enabled and mirrored, all mirrored packets are in cleartext.

Each T1/E1 port can be independently configured for loop-timing (recovered from an Rx line) or node-timing (recovered from the system synchronization unit (SSU) in the active control processing module (CPM)).

A T1/E1 port can be configured to be a timing source for the node.