ANYsec

ANYsec overview

Nokia ANYsec uses IEEE802.1AE (MACsec) as its datapath encryption engine and IEEE802.1x (dot1x/MKA) as its control plane signaling protocol. ANYsec uses the user-configured MACsec connectivity-association (CA) with a set of pre-shared keys (PSKs), the same way MACsec does, to negotiate datapath keys between two or more peers.

The following is the basic high-level overview of the SR OS ANYsec encryption process.

The user configures the ANYsec-specific CA, which supports the exclusive use of the CA with ANYsec encryption.
```
configure macsec connectivity-association anysec true
```
The MACsec key agreement (MKA) key server generates the datapath security association keys (SAKs) locally on the SR OS. The user configures the key-server selection priority using the following command.
```
configure macsec connectivity-association static-cak mka-key-server-priority
```
The MKA uses CMAC-AES-128/256 to encrypt the SAKs using PSK and distributes the SAKs.
ANYsec modifies the MKA for transport over IP/UDP (described in more detail in later topics). MKA distributes the SAKs between peers, and ANYsec uses the SAKs to encrypt the MPLS payload via the IEEE802.1AE encryption engine.

The following figure shows the ANYsec high-level implementation.

Figure 2. ANYsec high-level implementation

ANYsec packet format

ANYsec MPLS provides packet encryption formats that are different from the MACsec packet formats.

As shown in the following figure, MACsec leaves the MAC (802.1 AE) header in clear while authenticating the entire packet in the LAN.

The following figure shows that the MACsec WAN mode leaves the dot1q VLANs in clear and unauthenticated, so the packets can be manipulated by the VLAN switched network.

Figure 4. MACsec packet authentication for dot1q packets

With ANYsec, the entire MPLS label stack is in clear and unauthenticated. This allows the LSR routers to manipulate the MPLS label stack while the system encrypts and authenticates the payload. The following figure shows ANYsec MPLS packet authentication.

Figure 5. ANYsec MPLS packet authentication

ANYsec encryption

Nokia FP5 ANYsec uses the IEEE802.1AE (MACsec) encryption engine to encrypt multiple layers of OSI. For example, the same encryption engine can encrypt at Layer 2, MACsec, or Layer 2.5 MPLS ANYsec.

ANYsec encryption supports MACsec encryption algorithms, MPLS protocols, and per-flow encryption.

Encryption algorithms

ANYsec uses the MACsec encryption engine and therefore supports all the MACsec encryption algorithms, including the following:

CMAC-AES-128/AES-256 for pre-shared key encryption used by the MKA protocol
GCM-AES 128/256 for datapath encryption, using extended packet number (XPN)

MPLS protocol support

ANYsec currently encrypts LSPs that are signaled by the following Segment Routing (SR) protocols:

SR-ISIS
SR-OSPF
SR-OSPF3

Currently ANYsec encrypts the service label, entropy label, and entropy-indication label.

per-flow encryption

ANYsec uses a different encryption key for each encrypted LSP, thereby ensuring that all LSPs are encrypted with a unique SAK. The ANYsec MKA key server distributes the SAK to the peer. The user configures the key server selection identically to the MACsec key server selection, using the following command.

configure macsec connectivity-association static-cak mka-key-server-priority

ANYsec uses the Layer 3 content addressable memory (CAM) build in the Nokia FP5 chipset to match the MPLS label stack to the appropriate SAK. When a SAK for an LSP is distributed via MKA, ANYsec downloads the LSP's label stack to the Layer 3 CAM and associates it with the corresponding SAK, which it downloads to the SA lookup table.

ANYsec and MACsec interaction

If ANYsec is enabled on the network ports, SR OS only supports enabling MACsec on the access ports. If MACsec and ANYsec are on the same IOM and FP5 chipset, MACsec uses scaling resources from ANYsec. For example, if a single MACsec port is configured on the same IOM as ANYsec, the ANYsec scale drops by 1 on that IOM. This is because both MACsec and ANYsec use the same SA lookup table, which has a defined number of entries.

The following figure shows the supported interaction between ANYsec and MACsec.

ANYsec and LAG and ECMP interaction

When LSPs are enabled with ANYsec on ILER, the LSPs do not hash their internal flows over multiple ECMP interfaces or over LAG members. Instead, each LSP on ILER maps to a dedicated ECMP interface or LAG member. If an ANYsec LSP is transporting multiple services or IP flows, all the services and IP flows map to a single interface in an ECMP group, or to a single member in a LAG bundle on the ILER. However, if there are multiple ANYsec LSPs on the ILER, each ANYsec LSP and all the flows within the LSP can also hash to a different interface in an ECMP group or a different LAG member in a LAG bundle.

The LSR routers can hash the ANYsec LSPs over an ECMP group interface or a LAG member freely without any restrictions.

Note: ANYsec does not support entropy label in clear; ANYsec encrypts EL and ELI.

Inter AS and Inter Area solutions

ANYsec LSPs support a single-area solution only. ANYsec does not support inter-AS or inter-AREA option B or option C (for example, seamless MPLS).

ANYsec supports inter-AS or inter-AREA option A with the following conditions:

The termination of the ANYsec LSP is at the ABR or ASBR router.
Another ANYsec LSP originates toward the other inter-AS or inter-AREA option A.

In addition, ANYsec does not support tunnels within tunnels. For example, an ANYsec LSP that is encrypted cannot be encapsulated in a second MPLS tunnel such as BGP LU, RSVP-TE, or LDP.

ANYsec implementation design

ANYsec supports the following implementation design:

At the MKA signaling layer, ANYsec supports assigning the PSKs and the CAs to a group of Segment Routing (SR) tunnels. This assignment is known as Encryption Groups (EG) in ANYsec. EGs support easy management of PSKs for ANYsec tunnels, because multiple tunnels can use the same PSK.
MKA is established per pair of peers, thereby allowing encryption of each tunnel with its own dedicated SAK. The use of a dedicated SAK per tunnel ensures a high level of security. For ease of management, ANYsec supports using PSKs per group of tunnels. However, for maximum security, the SAK is only supported per pair of peers.
ANYsec supports tunnel slicing using Flex Algo or multi-instance IGP. Each slice is uniquely identified and a SAK is assigned per slice (per set of peers). ANYsec can also uniquely identify each LSP on each slice, and assign an EG to the LSPs through user configuration.
ANYsec uses the MKA Layer 2 protocol for signaling, which uses IEEE 802.1x for encapsulation. To transport MKA over IP in a Layer 3 network, ANYsec encapsulates MKA over IP/UDP. The UDP port uniquely identifies the MKA packets to the ANYsec peers. The IP header transports the MKA packet from one ANYsec PE to another ANYsec PE.

The following figure shows the ANYsec design implementation and related requirements.

Figure 8. ANYsec encryption implementation design and requirements

ANYsec configuration guidelines

These topics describe the basic configuration requirements to implement Nokia ANYsec MPLS encryption.

Configuring ANYsec connectivity association and PSK

ANYsec uses MKA for its control plane and for signaling of SAKs, and therefore ANYsec reuses the MACsec connectivity association (CA) and the PSKs. SR OS supports creation of the CA uniquely for ANYsec. When the anysec command is enabled under the CA, SR OS supports the exclusive use of the CA with ANYsec encyrption; this CA cannot be reused for MACsec any longer.

Use the following command to enable ANYsec CA.

configure macsec connectivity-association anysec

ANYsec supports the static-cak and the cipher-suite commands for the CA configuration. When a CA is configured for ANYsec, it does not support the following CA configurations:

clear-tag mode
delay protection
encryption offset
MACsec encryption
replay-window size
MAC policy

ANYsec also does not support configuration of a MACsec MAC policy.

The following example displays an ANYsec CA configuration.

Note: ANYsec supports a minimum mka-hello-interval of 5 seconds. This is because MKA hellos could transit over multiple routers from one ANYsec PE to another.

MD-CLI

[ex:/configure macsec]
A:admin@node-2# info
    connectivity-association "CA-1" {
        admin-state enable
        cipher-suite gcm-aes-xpn-256
        anysec true
        static-cak {
            mka-hello-interval 5
            pre-shared-key 1 {
                encryption-type aes-256-cmac
                cak "2yzrsjg5sp7MYAnWpod+Nkn4SwXf7OPMEfAMRpNh9Gu/badNTWOoYEG9Qi1NDOBW hash2"
                cak-name "11"
            }
        }
    }

classic CLI

A:node-2>config>macsec# info 
----------------------------------------------
        connectivity-association "CA-1" create.
            anysec
            cipher-suite gcm-aes-xpn-256
            static-cak
                pre-shared-key 1 encryption-type aes-256-cmac create
                    cak "2yzrsjg5sp7MYAnWpod+Nkn4SwXf7OPMEfAMRpNh9Gu/badNTWOoYEG9Qi1NDOBW" hash2
                    ckn "11"
                exit
                mka-hello-interval 5
            exit
            no shutdown
        exit

Identifying and configuring ANYsec LSP

After configuring the CA as described in Configuring ANYsec connectivity association and PSK, the next step is to identify the LSP to encrypt. The benefit of ANYsec is the ability to easily enable encryption on an LSP at any time, without changing the LSP's service lease agreement (SLA). ANYsec achieves this by doing the following:

ANYsec uses the MACsec engine to achieve low latency, line rate encryption, with less than 1us and with in 100s of ns of introduced encryption and decryption latency.
ANYsec identifies an LSP to encrypt using a disjoint configuration, and encrypts it independently, allowing creation of MPLS networks with appropriate design and SLA that can be expanded to include encryption on LSPs in the future.
ANYsec uses bidirectional configuration, even for LSPs that are unidirectional, and therefore the ANYsec configuration has to identify an outgoing LSP to encrypt and an incoming LSP to decrypt, under the same encryption group.

The following example displays a configuration to enable encryption on the egress LSP with the node SID 1.1.216.136, and decryption for the local node SID bound to 1.1.216.100. Both LSPs are on IGP instance ID 11.

MD-CLI

[ex:/configure anysec]
A:admin@node-2# info
    reserved-label-block "rlb-1"
    mka-over-ip {
        mka-udp-port 12345
    }
    tunnel-encryption {
        security-termination-policy "STP-1" {
            admin-state enable
            local-address 1.1.216.100
            igp-instance-id 11
        }
        security-termination-policy "Sec-Term-Policy" {
        }
        security-termination-policy "test-policy" {
        }
        encryption-group "EG-1" {
            security-termination-policy "STP-1"
            ca-name "CA-1"
            peer-tunnel-attributes {
                igp-instance-id 11
            }
            peer 1.1.216.136 {
                admin-state enable
            }
        }
    }

classic CLI

A:node-2>config>anysec# info 
----------------------------------------------
     reserved-label-block "rlb-1"
     mka-over-ip
         mka-udp-port 12345
     exit
     tunnel-encryption
         security-termination-policy "STP-1" create
             igp-instance-id 11
             local-address 1.1.216.100 //decrypt the incoming LSP for local node sid
             no shutdown
         exit
     encryption-group "EG-1" create
         ca-name "CA-1"
         security-termination-policy "STP-1"
         peer-tunnel-attributes
             igp-instance-id 11
         exit
         peer 1.1.216.136 create //encrypt the outgoing LSP for remote node sid
             no shutdown
         exit
         no shutdown
     exit
 exit

The security-termination policy identifies the decrypting LSP and the node SID on the local router. The decrypting LSPs node SID can arrive from multiple peers, and the SAKs used to decrypt these incoming LSPs are different for each peer.

The encryption group is a group of peers that use the same CA and PSK to secure the SAK over MKA. Each peer node SID and its local node SID use a different SAK to encrypt the datapath, but all these SAKs under the same encryption group are secured and signaled via the same CA and PSK.

A security-termination policy can be part of multiple encryption groups, however, a peer can only be part of a single encryption group. This allows a set of bidirectional LSPs in an encryption group to use the same CA and PSK to secure and signal SAKs between them.

The following figure shows the implementation of ANYsec tunnel encryption using two encryption groups with the same security termination policy, and different CAs and peers.

Figure 9. ANYsec tunnel encryption implementation

Configuring ANYsec MKA

ANYsec uses MKA to distribute SAKs. MKA is part of IEEE802.1x standard and is a Layer 2 protocol without an IP header. As an MPLS Layer 2.5 encryption protocol, ANYsec reuses MKA by encapsulating MKA in IP/UDP to distribute the SAK from one PE to the other.

The user-configurable UDP port identifies the MKA packets on the router. The following configuration guidelines apply:

Reserve the UDP port for MKA for the entire network.
Ensure that the UDP port is not in use by any other application.

Use the following command to configure the MKA UDP port.

configure anysec mka-over-ip mka-udp-port

The following figure shows the ANYsec implementation using the MKA UDP port configuration.

Figure 10. ANYsec using MKA UDP port configuration

Configuring ANYsec encryption SIDs

With ANYsec, the encryption engine locks on a unique label stack and encrypts it with a unique SAK. This label stack needs to be programmed by SR OS in the encryption engine. This creates a problem with double encryption in segment routing technology. In segment routing, all peers wanting to send a packet to a local router, send the packet to the node SID of the local router. As such, the label stack that is pushed on the packet by different routers to switch the packet to the local router may be identical. This means if an encrypting node is also an LSR node for an upstream router, it would encrypt its own local packets to the downstream ANYsec router and would double encrypt the upstream ANYsec router packets that are going through it to the same downstream ANYsec router. For example, in the following figure PE2 would encrypt its own packet destined for PE3 and double encrypt the PE1 packets with same MPLS label stack destined for PE3. This double encryption would mean that PE1 packets are not decrypted correctly at PE3.

Figure 11. ANYsec double-encryption scenario

To solve this problem, SR OS introduced the encryption SID concept. The encryption SID uniquely identifies the encrypting router within the network. The encryption SID is pushed by the encrypting router at the bottom of the label stack with S bit set.

In the following figure, the encryption SID 2000 is assigned to PE1 encrypting node and encryption SID 2001 is assigned to PE2 encrypting node. Both sending packets to PE3.

The encryption SID pushed at the bottom of the label stack ensures that each encrypting node has a unique label stack so double encryption does not occur on the PE2. The PE2 ANYsec CAM is only programmed to encrypt the label stack of <2001(S=1),1002> and does not match the label stack of <2000(S=1),1002> from PE1.

Ensure the following conditions are met for the encryption SID used in the ANYsec configuration:

The encryption SID for the ANYsec configuration must be uniquely assigned to each encrypting router.
The encryption SID for the ANYsec configuration must be assigned from a reserved block of labels on SR OS.

The following example displays a configuration of an encryption SID on a encrypting node.

MD-CLI

[ex:/configure router "Base" mpls-labels]
A:admin@node-2# info
    sr-labels {
        start 60000
        end 120000
    }
    reserved-label-block "r1b-1" {
        start-label 50000
        end-label 59999
    }

[ex:/configure anysec]
A:admin@node-2# info
    reserved-label-block "r1b-1"
    mka-over-ip {
        mka-udp-port 12345
    }
    tunnel-encryption {
        security-termination-policy "STP-1" {
            admin-state enable
            local-address 1.1.216.100
            igp-instance-id 11
        }
        security-termination-policy "Sec-Term-Policy" {
        }
        security-termination-policy "test-policy" {
        }
        encryption-group "EG-1" {
            admin-state enable
            security-termination-policy "STP-1"
            encryption-label 50012
            ca-name "CA-1"
            peer-tunnel-attributes {
                igp-instance-id 11
            }
            peer 1.1.216.136 {
                admin-state enable
            }
        }
    }

classic CLI

A:node-2>config>router>mpls-labels# info 
----------------------------------------------
            sr-labels start 60000 end 120000
            reserved-label-block "rlb-1" //reserved block for encryption sid
                start-label 50000 end-label 59999
            exit
----------------------------------------------

A:node-2>config>anysec# info 
----------------------------------------------
        reserved-label-block "rlb-1" //reserve blocked assigned to ANYsec
        mka-over-ip
            mka-udp-port 12345
        exit
        tunnel-encryption
            security-termination-policy "STP-1" create
                igp-instance-id 11
                local-address 1.1.216.100
                no shutdown
            exit
            encryption-group "EG-1" create
                ca-name "CA-1"
                encryption-label 50012 //encryption sid that uniquely identifies this encrypting node and is pushed on the bottom of label stack when the node encrypts the LSP.
                security-termination-policy "STP-1"
                peer-tunnel-attributes
                    igp-instance-id 11
                exit
                peer 1.1.216.136 create
                    no shutdown
                exit
                no shutdown
            exit
        exit

ANYsec OAM MPLS support

OAM support with Segment Routing tunnels

ANYsec supports OAM with following Segment Routing tunnels:

SR-ISIS
SR-OSPF
SR-OSPF3

OAM command support

ANYsec supports OAM tools including P2MP LSP ping and services OAM tools if any services are riding over the ANYsec tunnel. ANYsec supports the use of the following inband OAM commands:

LSP ping
SDP ping
VCCV ping
Service ping
ping over a non default service
L2 service ping

Note: Inband OAM packets are transmitted encrypted over an MPLS tunnel and outband OAM packets are transmitted unencrypted. For example, ANYsec does not encrypt an ICMP reply that comes out of band, such as in IP/UDP.