ANYsec

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)

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.

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 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 encryption; this CA cannot be reused for MACsec any longer.

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.

[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 2
            pre-shared-key 1 {
                encryption-type aes-256-cmac
                cak "2yzrsjg5sp7MYAnWpod+Nkn4SwXf7OPMEfAMRpNh9Gu/badNTWOoYEG9Qi1NDOBW hash2"
                cak-name "11"
            }
        }
    }

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 2
            exit
            no shutdown
        exit

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 within 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.

[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
            }
        }
    }

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 following figure shows the implementation of ANYsec tunnel encryption using two encryption groups with the same security termination policy, and different CAs and peers.

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:

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.

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.

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.

[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
            }
        }
    }

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

Encryption Groups (EGs) can be assigned to a service to enable encryption for that service. An EG contains the CA, which contains the PSK used for the MKA to secure the SAK. As with tunnel encryption, the MKA is established for each pair of PEs in a service. The MKA distributes the SAK to each pair of PEs. Each PE pair within a service (such as VPRN) is encrypted with a different SAK, providing additional security. If a pair of PE SAKs is compromised, other PE pairs in the same service remain compromised.

An EG can be assigned to a single service or to multiple services. If assigned to multiple services, the services use the same MKA between peers and the same datapath key (SAK) to encrypt their packets between the peers. This provides scaling benefits for ANYsec, as multiple services are encrypted using the same SAK.

EGs function as follows:

• The provider can choose to either encrypt a service or multiple services using a single MACsec CA and PSK (and its SAK), or assign each service a unique CA, PSK, and SAK.

  As with tunnel encryption, this creates an EG concept.

• An EG can be used for a set of services to be encrypted using a single CA and its corresponding PSK (CKN, CAK).
  • Services using the same EG use the same local encryption SID, which uniquely identifies the source of encrypting.
  • Each EG must be configured with a set of PEERs (PEs) that the service is encrypting traffic toward and receiving encrypted traffic from.
    • For service encryptions, these peers must match the peers discovered by dynamic protocols, such as BGP and TLDP, for each service.
    • If a service discovers a peer through overlay signaling (BGP or TLDP), and this peer is not configured under the EG for that service, traffic is dropped.

  • Each EG must be configured with its encryption SID (ES) to uniquely identify it as an encrypting source of the service.

    The peer's ES is discovered automatically through the MKA SCI field.

• A customer may configure a single EG or multiple EGs for its services, depending on their security needs.
• When the appropriate EGs are configured with their corresponding peers, the EG is assigned to a service under autobind or within the context of its spoke-SDP. The following applies:
  • When an EG is assigned to an autobind, all LSPs used by that autobind inherit the EG configuration, including the CA, ES, and local address.
  • For Epipe PW switching, each spoke-SDP has its own EG. As a result, the encryption terminates on the first spoke and switches to the second spoke, where it is encrypted again.

The security termination policy (secTP), as with tunnel encryption, contains the tunnel-protocol information, IGP instance, and flex algorithm. It also includes the local IP address, which identifies the system IP address or loopback address used to identify the local tunnel. This local IP address must match the BGP source IP address or TLDP source IP address; it is the IP address that identifies the SR tunnel terminating on the router for the service using that secTP.

Multiple EGs can have the same secTP.

The following considerations apply for service encryption:

• When identical EGs are assigned to multiple services or flex algorithms resolving through the same peer (far-end IP address), the resolution must be through the same transport tunnel and resolution filter tunnel type. Additionally, when the same EG is assigned to multiple services or flex algorithms, the same SAK is used to encrypt packets for all services that share the same EG.
• Service encryption only supports service labels per VRF, which is configured using the following command option.

  configure service vprn label-mode vrf

  • Service encryption does not support the label-mode next-hop command option, even though it can be configured when the service is encrypted. If next-hop is configured, service encryption does not function correctly.
  • Service encryption does not support the advertise-label per-prefix command option in the configure policy-options context.
• If ANYsec enabled, a service can have only a single BGP instance. For example, if ANYsec is enabled under a VPRN service, that service cannot also have an EVPN instance.

• A transport tunnel cannot be encrypted if it is used for encrypted services.

  If the transport tunnel is encrypted and assigned to an encrypted service on egress, traffic is dropped.

• Flex-E is not supported with ANYsec.

• The security termination policy is a peer and transport tunnel concept. A peer can contain multiple services, some encrypted and others cleartext. As a result, to allow a combination of encrypted and cleartext services to reside on a node, the following command should be set to false in the security termination policy.

  configure anysec security-termination-policies policy rx-must-be-encrypted false

  Note: When a service is encrypted, it accepts only encrypted traffic; any cleartext traffic is dropped.

Layer 2 and Layer 3 services can be configured in a single area or across multiple areas or ASs. Most deployments use Option A and Option C, though some also use Option B.

Service encryption supports only Option A. In this scenario, the service is decrypted at the ASBR or ABR PE, after which routes are leaked to the corresponding ASBR or ABR PE in the other domain. Traffic is forwarded in cleartext, and in the second domain the PE can reencrypt the service. The user data is in cleartext between the ASBR and ABR, and between the edge PEs.

The following figure shows an example of an encrypted service with Option A.

ANYsec uses MKA to distribute datapath keys (SAKs). For ANYsec, the MKA is established for each EG and each peer in the EG.

The MKA is uniquely identified through the source IP address, destination IP address, and SCI. The SCI is made up of the ES and endpoint ID.

The following figure shows an example of the MKA for an encrypted service.

In MKA for encrypted service, if the VPRN on PE1 has two peers (PE3 and PE2) for EG1, two MKA sessions are created: one from PE1 to PE2 and another from PE1 to PE3, both for the same VPRN. The source IP address of the MKA is the local address in the secTP. The destination IP address is the peer IP address in EG1, which has two peers (PE2 and PE3). Each pair of local addresses, peer addresses, and SCIs create an MKA session.

As a result, each EG and PE within that EG is assigned a unique SAK for encryption, as shown in the following figure.

In another example, if two VPRNs between two PEs use the same EG and secTP, only a single MKA session is created. This is because the source IP address of the MKA is the secTP local address, which is common to both VPRNs; the destination IP address is the peer IP address in the EG, which is also common. In addition, the ES is common for both VPRNs. In this case, because one MKA session serves both VPRNs, the same SAK is signaled for both. So user traffic from the two VPRNs is encrypted with the same SAK.

In the preceding example, each VPRN must be configured with a unique EG to have its own MKA and SAK.

This section provides examples of packet formats for encrypted services in different scenarios.

This section provides configuration examples for service encryption scenarios.