Network group encryption

The NGE feature allows a tiered approach to managing encryption keys in a network using key groups. This is accomplished by the configuration of services, router interfaces, or Ethernet ports to use specific key groups depending on security policies for the service and network topology.

The following figure shows a typical application of NGE key group partitioning in which there are several critical levels (tiers) of security that need to be considered. In this example, the protection of distribution automation and field area network (DA/FAN) equipment may be considered less critical than the transmission or distribution substation network equipment. It may be ideal to ensure that nodes more at risk of a security breach do not contain more critical information than is necessary. Therefore, encryption keys for the sensitive portions of the network (such as control center traffic) should not be available on nodes that are at risk. The 7705 SAR NGE feature enables operators to partition and distribute encryption keys among different services, NGE domains, or nodal groups in a network. NGE partitions are enabled by configuring different key groups per security partition and applying those key groups as needed.

Another application of key group partitioning allows different parts of an organization to have their own method of end-to-end communication without the need to share encryption keys between each organization. If two partitions need to communicate between themselves, gateway nodes configured with both key groups allow inter-organization traffic flows between the key group partitions, as needed.

An NGE domain is a group of nodes and router interfaces forming a network that uses a single key group to create a security domain. NGE domains are created when router interface encryption is enabled on router interfaces that need to participate in the NGE domain. The NSP NFM-P assists operators in managing the nodes and interfaces that participate in the NGE domain. See the NSP NFM-P User Guide for more information.

The following figure shows various traffic types crossing an NGE domain.

In the figure, nodes A, B, C, and D have router interfaces configured with router interface encryption enabled (and optionally Layer 2 NGE on the Ethernet port). Traffic is encrypted when entering the NGE domain using the key group configured on the router interface and is decrypted when exiting the NGE domain.

Traffic may traverse multiple hops before exiting the NGE domain, yet decryption only occurs on the final node when the traffic exits the NGE domain. Various traffic types are supported and encrypted when entering the NGE domain, as illustrated by the following items on node A in the figure:

• item 1: self-generated packets – these packets, which include all types of control plane and management packets such as OSPF, BGP, LDP, SNMPv3, SSH, ICMP, RSVP-TE, and 1588, are encrypted

• item 2: user Layer 3 packets – any Layer 3 user packets that are routed into the NGE domain from an interface outside the NGE domain are encrypted

• item 3: IPSec packets – IPSec packets are NGE-encrypted when entering the NGE domain to ensure that the IPSec packet’s security association information does not conflict with the NGE domain

GRE-MPLS-based service traffic consists of Layer 3 packets, and router interface NGE is not applied to these types of packets. Instead, service-level NGE is used for encryption to avoid double-encrypting these packets and impacting throughput and latencies. The two types of GRE-MPLS packets that can enter the NGE domain are illustrated by items 4 and 5 in the figure:

• item 4: GRE-MPLS packets (SDP or VPRN) with service-level NGE enabled – these encrypted packets use the key group that is configured on the service. The services key group may be different from the key group configured on the router interface where the GRE-MPLS packet enters the NGE domain.

• item 5: GRE-MPLS packets (SDP or VPRN) with NGE disabled – these packets are not encrypted and can traverse the NGE domain in clear text. If these packets require encryption, SDP or VPRN encryption must be enabled.

Creating an NGE domain from the NSP NFM-P requires the operator to determine the type of NGE domain being managed. This will indicate whether NGE gateway nodes are required to manage the NGE domain, and other operational considerations. The two types of NGE domains are:

• Private IP/MPLS network NGE domain

• Private over intermediary network NGE domain

The NGE feature is tightly integrated with the NSP NFM-P. The following functions are provided by the NSP NFM-P :

• managing and synchronizing encryption and authentication keys within key groups on a network-wide basis

• configuring NGE on MPLS services and managing associated key groups

• configuring NGE on router interfaces and Ethernet ports and managing associated key groups

• coordinating network-wide rekeying of key groups

The NSP NFM-P acts as the key manager for NGE-enabled nodes and allocates the keys in key groups that are used to perform encryption and authentication. The NSP NFM-P ensures that all nodes in a key group are kept in synchronization and that only the key groups that are relevant to the associated nodes are downloaded with key information.

The NSP NFM-P performs network-wide hitless rekeying for each key group at the rekeying interval specified by the operator. Different key groups can be rekeyed at different times as needed, or all key groups can be rekeyed network-wide at the same time.

For more information about NSP NFM-P management, see the ‟Service Management” section in the NSP NFM-P User Guide.

All SAs configured in a key group share the same encryption algorithm and the same authentication algorithm. The size and values required by a particular key depend on the requirements of the algorithms selected. One encryption algorithm and one authentication algorithm must be selected per key group.

Encryption algorithms available per key group include:

• AES128 (a 128-bit key, requiring a 32-digit ASCII hexadecimal string)

• AES256 (a 256-bit key, requiring a 64-digit ASCII hexadecimal string)

Authentication algorithms available per key group include:

• HMAC-SHA-256 (a 256-bit key, requiring a 64-digit ASCII hexadecimal string)

• HMAC-SHA-512 (a 512-bit key, requiring a 128-digit ASCII hexadecimal string)

Encryption and authentication strengths can be mixed depending on the requirements of the application. For example, 256-bit strength encryption can be used with 512-bit strength authentication.

The configured algorithms cannot be changed when there is an existing SA configured for the key group. All SAs in a key group must be deleted before a key group algorithm can be modified.

Key values are not visible in CLI or retrievable using SNMP. Each node calculates a 32-bit CRC checksum for the keys configured against the SPI. The CRC can be displayed in the CLI or read by SNMP. The purpose of the CRC is to provide a tool to check consistency between nodes, thereby verifying that each node is set with the same key values while keeping the actual key values hidden.

Each key group has a list of up to four security associations (SAs). An SA is a reference to a pair of encryption and authentication keys that are used to decrypt and authenticate packets received by the node and to encrypt packets leaving the node.

For encrypted ingress traffic, any of the four SAs in the key group can be used for decryption if there is a match between the SPI in the traffic and the SPI in the SA. For egress traffic, only one of the SAs can be used for encryption and is designated as the active outbound SA. Key groups and a typical NGE packet illustrates these relationships.

As shown in the figure, each SA is referenced by an SPI value, which is included in packets during encryption and authentication. SPI values must be numerically unique throughout all SAs in all key groups. If an SPI value is configured in one key group and an attempt is made to configure the same SPI value in another key group, the configuration is blocked.

NGE adds a global encryption label to the label stack for encrypting MPLS services. The global encryption label must be a unique network-wide label; in other words, the same label must be used on all nodes in the network that require NGE services. The label must be configured on individual nodes before NGE can become operational on those nodes.

The global encryption label is used to identify packets that have an NGE-encrypted payload and is added to the bottom of the stack. This allows network elements such as LSRs, ABRs, ASBRs, and RRs to forward NGE packets without needing to understand NGE or to know that the contents of these MPLS packets are encrypted. Only when a destination PE (7705 SAR) receives a packet that needs to be understood at the service layer does the PE check for an encryption label and then decrypt the packet.

When the global encryption label is set, it should not be changed. If the label must be changed without impacting traffic, all key groups in the system should first be deleted. Next, the label should be changed, and then all key groups should be reconfigured.

The NSP NFM-P helps to coordinate the distribution of the global encryption label and ensures that all nodes in the network are using the same global encryption label.

The following figure illustrates the NGE MPLS/GRE label stack.

The following figure illustrates VPRN and PW (with control word) packet formats using NGE encryption.

Assigning key groups to services requires configuring an inbound and outbound key group for directional processing on a per-service basis, as shown in the following figure.

The outbound key group identifies which key group to use for traffic that egresses the node for the service. The inbound key group ensures that ingress traffic is using the correct key group for the service.

If the inbound key group is not set, the node ensures that packets are either unencrypted or are using one of the valid key groups configured in the system.

In most deployment scenarios, the inbound and outbound key groups are identical. However, it is possible to configure different key groups as the outbound and the inbound key groups, as this is not checked by the node. Using different key groups in this way is not typical.

Including an inbound and outbound direction when assigning key groups to services allows users to:

• gracefully enable and disable NGE for services

• move services from one key group domain to another domain without halting encryption

The NGE feature makes use of the NSP NFM-P to help manage the assignment of key groups to services on a network-wide basis. See the NSP NFM-P User Guide for more information.

For VLL services, the 7705 SAR supports pseudowire (PW) switching of encrypted traffic from one PW to another. There are three scenarios that are supported on the 7705 SAR with regard to PW switching of traffic:

• PW switching using the same key group

  When a PW is using an encrypted SDP, the PW may be switched to another PW that is also using an encrypted SDP, and both SDPs are in the same key group. For this case, to perform the PW switch, the 7705 SAR leaves the encrypted payload unchanged and swaps the labels as needed for passing traffic between PWs.

• PW switching using different key groups

  When a PW is using an encrypted SDP, the PW may be switched to another PW that is also using an encrypted SDP, but both SDPs are in different key groups. For this case, the 7705 SAR decrypts the traffic from the first SDP by using the configured key group for that SDP and then re-encrypts the traffic by using the egress SDP's key group egress SPI ID.

• PW switching between an encrypted and unencrypted PW

  When traffic is switched from an encrypted PW to an unencrypted PW, the traffic is decrypted before it is sent. When traffic is switched from an unencrypted PW to an encrypted PW, the traffic is encrypted before it is sent.

See Pseudowire switching for more information.

The control word is a configurable option for PWs and is included in PW packets when it (the control word) is configured. When control-word is enabled and NGE is used, the datapath creates two copies of the CW. One CW is both encrypted and authenticated, and is inserted after the ESP header. The other CW is not encrypted (clear form) and is inserted before the ESP header.

For cases where PW switching is configured, the 7705 SAR ensures—in the CLI and with SNMP—that both segments of the PW have consistent configuration of the control word when encryption is being used.

See Pseudowire control word for more information.

The encryption configured on an SDP used to terminate the Layer 3 spoke SDP of a VPRN always overrides any VPRN-level configuration for encryption:

• When VPRN encryption is enabled, all routes resolved via MP-BGP (either with spoke SDPs using spoke-sdp or autobind SDPs using auto-bind-tunnel) are encrypted or decrypted using the VPRN key group.

• When Layer 3 spoke-SDP encryption is enabled, all routes resolved via the Layer 3 interface are encrypted or decrypted using the SDP's key group.

Some examples are as follows:

• If a VPRN is enabled for encryption while a Layer 3 spoke SDP for the same VPRN is using an SDP that is not enabled for encryption, then traffic egressing the spoke SDP is not encrypted.

• If a VPRN is disabled for encryption while a Layer 3 spoke SDP for the same VPRN is using an SDP that is enabled for encryption, then traffic egressing the spoke SDP is encrypted.

• If a VPRN is enabled for encryption using key group X, while a Layer 3 spoke SDP for the same VPRN is using key group Y, then traffic egressing the spoke SDP is encrypted using key group Y.

The commands used for these scenarios are config>service>sdp>encryption-keygroup and config>service>vprn>encryption-keygroup.

When RFC 3107 is enabled on the node and NGE traffic is crossing the RR between two VPRN domains, the same key group must be used between the two domains.

NGE is supported for NG-MVPN services with multicast configurations that include:

• I-PMSI

• S-PMSI

• C-multicast signaling

• mLDP multicast tunnel LSPs

For more information about MVPN, see Multicast VPN (MVPN).

When r-VPLS is configured for the VPRN, the node can act as a receiver for an NG-MVPN service that is NGE -encrypted. The node cannot act as a source of NG-MVPN traffic from a VPLS service, so the source of this NG-MVPN traffic must originate from another node that supports that capability.

When NGE is enabled in a VPRN with NG-MVPN-based services, transit nodes (LSRs) have no knowledge that NGE is being employed or that the NGE encryption label is being used with an ESP header after the NGE label. Features that inspect packet contents to make further decisions are not supported and must be disabled for mLDP multicast paths that need to carry NG-MVPN traffic that is NGE-encrypted. These features include:

• ingress multicast path management (7750 SR only)

• IP-based LSR hashing

The packet inspection restriction includes any third-party routing function that may inspect the packet contents after the mLDP transport label and is expecting a non-encrypted payload in order to make hashing decisions.

An NGE domain is a group of nodes whose router interfaces in the base routing context (GRT) are enabled for router interface NGE or whose ports are enabled for encryption of some types of Layer 2 traffic. An interface without router interface NGE enabled is considered to be outside the NGE domain. NGE domains use only one key group when the domain is created; however, two key groups may be active at once if some links within the NGE domain are in transition from one key group to the other.

The following figure illustrates the NGE domain concept and the table describes the three configuration scenarios inside the NGE domain.

A router interface is considered to be inside the NGE domain when it has been configured with group-encryption on the interface. When group-encryption is configured on the interface, the router can receive unencrypted packets or NGE-encrypted packets from any configured key group on the router, but any other type of IPSec-formatted packet is not allowed. If an IPSec-formatted packet is received on an interface that has group-encryption enabled, it will not pass NGE authentication and will be dropped. Therefore, IPSec packets cannot exist within the NGE domain without first being converted to NGE packets. This conversion requirement delineates the boundary of the NGE domain and other IPSec services.

When NGE router interface encryption is enabled and only an outbound key group is configured, the interface can receive unencrypted packets or NGE-encrypted packets from any configured key group on the router. All outbound packets are encrypted using the outbound key group if the packet was not already encrypted further upstream in the network.

When NGE router interface encryption has been configured with both an inbound and outbound key group, only NGE packets encrypted with the key group security association can be sent and received over the interface.

When there is no NGE router interface encryption, the interface is considered outside the NGE domain where NGE is not applied.

NGE router interface encryption is never applied to GRE-MPLS packets that are used to transport MPLS services over Layer 3 networks; for example, GRE with the GRE protocol ID set to MPLS Unicast (0x8847) or Multicast (0x8848). GRE-MPLS packets that enter the NGE domain or transit the NGE domain are forwarded as is.

Because GRE-MPLS packets provide transport for MPLS-based services, they already use the NGE services-based encryption techniques for MPLS, such as SDP or VPRN-based encryption. To avoid double encryption, the packets are left in clear text when entering an NGE domain or crossing intermediate nodes in the NGE domain, and are simply forwarded as needed when exiting an NGE domain.

The payload of these GRE-MPLS packets can also be sent in clear text depending on the security requirements that are configured for the MPLS service.

GRE packets with the protocol set to other protocols are encrypted using NGE router interface encryption.

In some cases, Layer 3 packets may need to cross the NGE domain in clear text, such as when an NGE-enabled router needs to peer with a non-NGE-capable router to exchange routing information. This can be accomplished by using a router interface NGE exception filter applied on the router interface for the required direction, inbound or outbound.

The following figure shows the use of a router interface NGE exception filter.

The inbound or outbound exception filter is used to allow specific packet flows through the NGE domain in clear text, where there is an explicit inbound and outbound key group configured on the interface. The behavior of the exception filter for each router interface configuration is as follows:

• NGE enabled, no inbound/outbound key group – in this scenario, the router does not encrypt outbound traffic, and so the outbound exception filter is not applied. The router can still receive inbound NGE packets, so the exception filter is applied to inbound packets. If the filter detects a match, clear text packets can be received and forwarded by the router.

• outbound key group, no inbound key group – the outbound exception filter is applied to outbound traffic, and packets that match the filter are not encrypted on egress. The router can receive inbound NGE packets without an inbound key group set and applies the exception filter to inbound packets. If the filter detects a match, clear text packets can be received and forwarded by the router.

• inbound and outbound key group – the inbound and outbound exception filters are applied, and any packets that match are passed in clear text

IPSec packets can cross the NGE domain because they are still considered Layer 3 packets. To avoid confusion between the security association used in an IPSec packet and the one used in a router interface NGE packet, the router always applies NGE to any IPSec packet that traverses the NGE domain.

IPSec packets that originate from a router within the NGE domain are not allowed to enter the NGE domain. The only exception to this restriction is OSPFv3 packets.

The following figure shows how IPSec packets can transit an NGE domain.

An IPSec packet enters the router from outside the NGE domain. When the router determines that the egress interface to route the packet is inside an NGE domain, it selects an NGE router interface with one of the following configurations:

• NGE enabled with no inbound or outbound key group configured – this link cannot forward the IPSec packet without adding the NGE ESP, but because nothing is configured for the outbound key group, the packet must be dropped

• NGE enabled with outbound key group configured and no inbound key group configured – the packet originates outside the NGE domain, so the router adds an ESP header over the existing ESP and encrypts the payload using the NGE domain keys for the configured outbound key group

• NGE enabled with both inbound and outbound key groups configured – the packet originates outside the NGE domain, so the router adds an ESP header over the existing ESP and encrypts the payload using the NGE domain keys for the configured outbound key group

OSPFv3 IPSec support also uses IPSec transport mode packets. These packets originate from the CSM, which is considered outside the NGE domain; however, the above rules for encapsulating the packets with an NGE ESP apply and allow these packets to successfully transit the NGE domain.

Multicast packets that traverse an NGE domain can be categorized into two main scenarios:

• scenario 1 – multicast packets that ingress the router on an interface that is outside the NGE domain. These packets can egress a variety of interfaces that are either inside or outside the NGE domain.

• scenario 2 – multicast packets that ingress the router on an interface that is inside the NGE domain. These packets can egress a variety of interfaces that are either inside or outside the NGE domain. This scenario has two cases:

  • scenario 2a – the ingress multicast packet is not yet NGE-encrypted

  • scenario 2b – the ingress multicast packet is NGE-encrypted

The following figure shows these scenarios.

Multicast packets received from outside the NGE domain (scenario 1) are processed similarly to multicast packets received from inside the NGE domain (scenarios 2a and 2b).

The processing rule is that multicast packets are always forwarded as clear text over the fabric. This means that for scenario 2b, when a multicast packet is received on an encryption-capable interface and is NGE-encrypted, the packet is always decrypted first so that it can be processed in the same way as packets in scenarios 1 and 2a.

On egress, the following scenarios apply:

• egressing an interface outside the NGE domain – packets are processed in the same way as any multicast packets forwarded out a non-NGE interface

• egressing an NGE router interface and no inbound or outbound key group is configured – the router forwards these packets out from the egress interface without encrypting them, because there is no outbound key group configured. This behavior also applies to unicast packets in the same scenario.

• egressing an NGE router interface with the outbound key group configured – the router encrypts the multicast packet using the SPI keys of the outgoing SA configured in the key group. This behavior also applies to unicast packets in the same scenario.

Assigning key groups to router interfaces involves the following three steps:

1. Enable NGE with the group-encryption command.

2. Configure the outbound key group.

3. Configure the inbound key group.

Step 1 is required so that the router can initialize and differentiate the interface for NGE traffic before accepting or sending NGE packets. This assigns the interface to an NGE domain, and IPSec packets will no longer be accepted on the interface.

Assigning key groups to a router interface in steps 2 and 3 is similar to assigning key groups to SDPs or VPRN-based services. An outbound key group cannot be configured for a router interface without first enabling group-encryption.

When group-encryption is enabled and no inbound key group is configured, the router accepts NGE Layer 3 packets that were encrypted using keys from any security association configured in any key group on the system. If the packet specifies a security association that is not configured in any key group on the node, the packet is dropped.

The outbound key group references the key group to use when traffic egresses the router on the router interface. The inbound key group is used to make sure ingress traffic is using the correct key group on the router interface. If ingress traffic is not using the correct key group, the router counts these packets as errors.

An interface that has been configured to exist inside the NGE domain cannot be added to a security zone; firewalls are not supported on NGE router interfaces, as shown in the following figure.

It is recommended that firewall security policies be enabled on interfaces outside the NGE domain before traffic is allowed to enter the NGE domain.

When NGE is enabled on a router interface, BFD packets that originate from the network processor on the adapter card or from the system are encrypted in the same way as BFD packets that are generated by the CSM.

When NGE is enabled on a router interface, the ACL function is applied as follows:

• on ingress – normal ACLs are applied to traffic received on the interface that can be either NGE-encrypted or clear text. For NGE-encrypted packets, this implies that only the source, destination, and IP options are available to filter on ingress because the protocol is ESP and the packet is encrypted. If an IP exception ACL is also configured on the interface, the IP exception ACL is applied first to allow any clear text packets to ingress as needed. After the IP exception ACL is applied and if another filter or ACL is configured on the interface, the other filter processes the remaining packet stream (NGE-encrypted and IP exception ACL packets), and other ACL functions such as PBR or Layer 4 information filtering could be applied to any clear text packets that passed the exception ACL.

• on egress – ACLs are applied to packets before they are NGE-encrypted as per normal operation without NGE enabled

Typically, ICMP works as expected over an NGE domain when all routers participating in the NGE domain are NGE-capable; this includes running an NGE domain over a private IP/MPLS network and over a Layer 2 service provider where dedicated point-to-point circuits are used to create single-hop links between NGE nodes. When an ICMP message is required, the NGE packet is decrypted first and the original packet is restored to create a detailed ICMP message using the original packet’s header information.

When the NGE domain crosses a Layer 3 service provider or crosses over routers that are not NGE-aware, it is not possible to create a detailed ICMP message using the original packet’s information because the NGE packet protocol is always set to ESP. Furthermore, the NGE router that receives these ICMP messages will drop them because the messages are not NGE-encrypted.

The combination of dropping ICMP messages at the NGE border node and the missing unencrypted packet details in the ICMP information can cause problems with diagnosing network issues.

To help with diagnosing network issues, additional statistics are available on the interface to show whether ICMP messages are being returned from a foreign node. The following statistics are included in the group encryption NGE statistics for an interface:

• Group Enc Rx ICMP DestUnRch Pkts

• Group Enc Rx ICMP TimeExc Pkts

• Group Enc Rx ICMP Other Pkts

These statistics are used when clear text ICMP messages are received on an NGE router interface. The Invalid ESP statistics are not used in this situation even though the packet does not have a correct NGE ESP header. If there is no ingress exception ACL configured on the interface to allow the ICMP messages to be forwarded, the messages are counted and dropped.

If more information is required for these ICMP messages, such as source or destination address information, a second ICMP filter can be configured on the interface to allow logging of the ICMP messages. If the original packet information is also required, an egress exception ACL can be configured with the respective source or destination address information, or other criteria, to allow the original packet to enter the NGE domain in clear text and determine which flows are causing the ICMP failures.

CSM timestamping is supported when NGE router interface encryption is enabled.

GRE fragmentation is supported on NGE-encrypted GRE SDP packets on the Ethernet interfaces of the adapter cards and platforms listed in NGE overview.

To determine if an encrypted packet needs to be fragmented, the system compares the total packet size after NGE encryption to the network port MTU. If the encrypted packet size is larger than the MTU, the packet is fragmented. NGE decryption is performed after the packet is fully reassembled.

See GRE fragmentation for more information.

NGE traffic arriving on network ingress is classified based on the network QoS policy that is assigned to the network router interface. This classification is done using the EXP bits of the outer MPLS tunnel LSP or the DSCP markings on the IP packet of GRE packets.

There are two queues provided for mapping ingress NGE traffic into the decryption engine—an expedited queue and a best-effort queue. The encrypted traffic maps to one of these queues based on the queue-type configuration of the network ingress queue and the FC-to-queue (classification) mapping. Specifically, at network ingress, the following occurs (as shown in the following figure):

• the network QoS policy determines the forwarding class (FC) for the packet (item 1)

• the ingress network queue QoS policy maps the FC to a queue, where the queue-type has been configured as expedited, best-effort, or auto-expedite (item 2)

• the queue-type is used again to map to the appropriate queue into the decryption engine (that is, the expedited and best-effort queue) (item 3)

• after decryption, normal QoS processing takes place as if NGE was not enabled for the service (item 4)

For more information about QoS for network ingress, see the ‟Network ingress” section in the 7705 SAR Quality of Service Guide.

Traffic egressing a network interface typically has a known FC based on the traffic management (TM) configuration at SAP ingress.

There are two queues provided for mapping egress NGE traffic into the encryption engine—an expedited queue and a best-effort queue. The traffic maps to one of these queues based on the FC of the packet, as determined at SAP ingress. Specifically, the following occurs:

• the SAP ingress QoS policy maps the FC to a queue-type, where the queue-type of the SAP-ingress queue has been configured as expedited, best-effort, or auto-expedite

• on the network egress side of the fabric, the ingress queue-type is used to map to the appropriate queue into the encryption engine (that is, the expedited and best-effort queue)

For more information about QoS for network egress, see the ‟Network egress” section in the 7705 SAR Quality of Service Guide.

The global encryption label is the network-wide, unique MPLS encryption label used for all nodes in the network group. The same encryption label must be configured on each node in the group.

Use the following CLI syntax to configure the global encryption label:

CLI syntax:

config>group-encryption
    group-encryption-label encryption-label

The following example displays global encryption label usage:

Example:

config# group-encryption 
config>grp-encryp# group-encryption-label 34 

The following example displays the global encryption label configuration:

ALU-1>config>grp-encryp# info
-------------------------------------------------------
     group-encryption-label 34
-------------------------------------------------------
ALU-1>config>grp-encryp# 

To configure a key group, set the following parameters:

• encryption and authentication algorithms

• security association

• active outbound SA

The authentication and encapsulation keys must contain the exact number of hexadecimal characters required by the algorithm used. For example, using sha256 requires 64 hexadecimal characters.

Keys are entered in clear text using the security-association command. Once entered, they are never displayed in their original, clear text form. Keys are displayed in a 7705 SAR-encrypted form, which is indicated by the system-appended crypto keyword when an info command is run (see the CLI syntax, Example, and CLI output below). The 7705 SAR also includes the crypto keyword with an admin>save operation so that the 7705 SAR can decrypt the keys when reloading a configuration database. For security reasons, keys encrypted on one node are not usable on other nodes (that is, keys are not exchangeable between nodes).

Use the following CLI syntax to configure key group options:

CLI syntax:

config# group-encryption 
    encryption-keygroup keygroup-id [create]
        description description-string
        esp-auth-algorithm {sha256|sha512}
        esp-encryption-algorithm {aes128|aes256} 
        keygroup-name keygroup-name
        security-association spi spi authentication-key authentication-key encryption-key encryption-key [crypto]
        active-outbound-sa spi

The following example displays key group command usage:

Example:

config>grp-encryp# encryption-keygroup KG1_secure
config>grp-encryp>encryp-keygrp# description Main_secure_KG
config>grp-encryp>encryp-keygrp# esp-auth-algorithm sha256
config>grp-encryp>encryp-keygrp# esp-encryption-algorithm aes128
config>grp-encryp>encryp-keygrp# keygroup-name KG1_secure
config>grp-encryp>encryp-keygrp# security-association spi 2 authentication-key 0x88433A6DB4FA4F8A490EF661CBE69F010BFAE9C2784BED7059E5ADAAB1A225C6 encryption-key 0x63DCDD501B66F85441E4A55B597DA617 
config>grp-encryp>encryp-keygrp# security-association spi 6 authentication-key 0x88433A6DB4FA4F8A490EF661CBE69F010BFAE9C2784BED7059E5ADAAB1A225C5 encryption-key 0x63DCDD501B66F85441E4A55B597DA616 
config>grp-encryp>encryp-keygrp# active-outbound-sa 6 ]

The following example displays the key group configuration:

ALU-1>config>grp-encryp# info detail
----------------------------------------------
        group-encryption-label 34
        encryption-keygroup 2 create
            description "Main_secure_KG"
            keygroup-name "KG1_secure"
            esp-auth-algorithm sha256
            esp-encryption-algorithm aes128
            security-association spi 2 authentication-
key 0x78d9e66a6669bd17454fe3184 ee161315b67adb8912949ceda20b6b741eb63604abe17de478e2
4723a7d1d5f7b6ffafc encryption-
key 0x8d51db8f826239f672457442cecc73665f52cbe00aedfb4eda6166001247b4eb crypto
            security-association spi 6 authentication-key 0x7fb9fc5553630924ee29973f
7b0a48f801b0ae1cb38b7666045274476a268e8d694ab6aa7ea050b7a43cdf8d80977625 encryption-
key 0x72bd9b87841dbebcb2d114031367ab5d9153a41b7c79c8f889ac56b950d8fffa crypto
            active-outbound-sa 6
        exit
----------------------------------------------
ALU-1>config>grp-encryp# 

A key group can be assigned to the following entities:

• SDPs

• VPRN services

NGE supports encryption of the following services when key groups are assigned to an SDP or VPRN service:

• VLL services (Epipe and Cpipe)

• VPRN services using Layer 3 spoke-SDP termination

• IES services using Layer 3 spoke-SDP termination

• VPLS services using spoke and mesh SDPs

• routed VPLS services into a VPRN or IES

• MP-BGP-based VPRNs

• NG-MVPN

For services that use SDPs, all tunnels may be either MPLS LSPs (RSVP-TE, LDP, or static LSP) or GRE tunnels. NGE is not supported on IP tunnels.

For VPRNs, the following encryptions are supported:

• unicast VPRN – MP-BGP-based VPRN-level encryption using spoke SDPs (spoke-sdp) or autobind SDPs (auto-bind-tunnel) with LDP, GRE, RSVP-TE, or segment routing (SR-ISIS, SR-OSPF, or SR-TE) tunnels

• multicast VPRN – NG-MVPN using mLDP with auto-discovery

Use the following CLI syntax to assign a key group to an SDP or a VPRN service:

CLI syntax:

config>service# sdp sdp-id [create]
    encryption-keygroup keygroup-id direction {inbound|outbound} 

CLI syntax:

config>service# vprn service-id 
    encryption-keygroup keygroup-id direction {inbound|outbound} 

The following examples display a key group assigned to an SDP or a VPRN service:

Example:

config>service# sdp 61 create
config>service>sdp# encryption-keygroup 4 direction inbound
config>service>sdp# encryption-keygroup 4 direction outbound

Example:

config>service# vprn 22
config>service>vprn# encryption-keygroup 2 direction inbound
config>service>vprn# encryption-keygroup 2 direction outbound

The following example displays key group configuration for an SDP or a VPRN service.

ALU-1:Sar18>config>service# info 
----------------------------------------------
...
        sdp 61 create
            shutdown
            far-end 10.10.10.10
            exit
            encryption-keygroup 4 direction inbound
            encryption-keygroup 4 direction outbound
        exit
...
        vprn 22 customer 1 create
            shutdown
            encryption-keygroup 2 direction inbound
            encryption-keygroup 2 direction outbound
        exit
...
----------------------------------------------

Use the following CLI syntax to assign a key group to a router interface:

CLI syntax:

config>router# interface ip-int-name [create]
    group-encryption
        encryption-keygroup keygroup-id direction {inbound | outbound} 

The following example displays a key group assigned to a router interface:

Example:

config>router# interface demo
config>router>if# group-encryption
config>router>if>group-encryp# encryption-keygroup 6 direction inbound
config>router>if>group-encryp# encryption-keygroup 6 direction outbound

The following example displays key group configuration for a router interface.

ALU-1:Sar18>config>router# info 
----------------------------------------------
...
        interface demo
            group-encryption
                encryption-keygroup 6 direction inbound
                encryption-keygroup 6 direction outbound
                exit
            no shutdown
            exit
        exit
...
----------------------------------------------

Use the following CLI syntax to assign a key group to an Ethernet port:

CLI syntax:

config# port port-id
    ethernet
        group-encryption
            encryption-keygroup keygroup-id direction {inbound | outbound} 

The following example displays a key group assigned to an Ethernet port:

Example:

config# port 1/2/2
config>port# ethernet
config>port>ethernet# group-encryption
config>port>ethernet>group-encryp# encryption-keygroup 6 direction inbound
config>port>ethernet>group-encryp# encryption-keygroup 6 direction outbound

The following example displays key group configuration for an Ethernet port.

ALU-1:Sar18>config>port# info 
----------------------------------------------
...
        ethernet
            group-encryption
                encryption-keygroup 6 direction inbound
                encryption-keygroup 6 direction outbound
                exit
            no shutdown
            exit
        exit
...
----------------------------------------------

When modifying a key group, observe the following conditions:

• The encryption or authentication algorithm for a key group cannot be changed if there are any SAs in the key group.

• The active outgoing SA must be removed (deconfigured) before the SPI can be deleted from the SA list in the key group.

• Before the outgoing SA can be deconfigured, the key group must be removed from all services on the node that use the key group

In the following example, the active outgoing SA is deconfigured, the SAs are removed, and the encryption algorithm is changed. Then the SAs are reconfigured, followed by reconfiguration of the active outgoing SA. The output display shows the new configuration based on those shown in Configuring a key group.

Use the following CLI syntax to modify a key group. The first syntax deconfigures the key group items and the second syntax reconfigures them.

CLI syntax:

config# group-encryption 
    encryption-keygroup keygroup-id 
        no active-outbound-sa 
        no security-association spi spi 
    exit 

CLI syntax:

config# group-encryption 
    encryption-keygroup keygroup-id 
        security-association spi spi authentication-key auth-key encryption-key encrypt-key 
        esp-encryption-algorithm {aes128|aes256} 
    exit 

Example:

config>grp-encryp# encryption-keygroup KG1_secure
config>grp-encryp>encryp-keygrp# no active-outbound-sa
config>grp-encryp>encryp-keygrp# no security-association spi 2 
config>grp-encryp>encryp-keygrp# no security-association spi 6 

Example:

config>grp-encryp# encryption-keygroup KG1_secure
config>grp-encryp>encryp-keygrp# esp-encryption-algorithm aes256
config>grp-encryp>encryp-keygrp# security-association spi 2 authentication-key 0x0123456789012345678901234567890123456789012345678901234567890123 encryption-key 0x0123456789012345678901234567890123456789012345678901234567890123 
config>grp-encryp>encryp-keygrp# security-association spi 6 authentication-key 0x0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF encryption-key 0x0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF [crypto]
config>grp-encryp>encryp-keygrp# active-outbound-sa 2

The following example displays the commands used to modify a key group. The first example deconfigures the key group items and the second example reconfigures them. The encryption algorithm is changed from 128 to 256, the keys are changed, and the active outbound SA is changed to SPI 2.

ALU-1>config>grp-encryp# info detail
----------------------------------------------
        group-encryption-label 34
        encryption-keygroup 2 create
            description "Main_secure_KG"
            keygroup-name "KG1_secure"
            esp-auth-algorithm sha256
            esp-encryption-algorithm aes128
            no security-association spi 2 
            no security-association spi 6 
            no active-outbound-sa
        exit
----------------------------------------------
ALU-1>config>grp-encryp# 

ALU-1>config>grp-encryp# info detail
----------------------------------------------
        group-encryption-label 34
        encryption-keygroup 2 create
            description "Main_secure_KG"
            keygroup-name "KG1_secure"
            esp-auth-algorithm sha256
            esp-encryption-algorithm aes256
            security-association spi 2 authentication-
key 0x0123456789012345678901234567890123456789012345678901234567890123 encryption-
key 0x0123456789012345678901234567890123456789012345678901234567890123 
            security-association spi 6 authentication-
key 0x0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF encryption-
key 0x0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF crypto
            active-outbound-sa 2
        exit
----------------------------------------------
ALU-1>config>grp-encryp# 

Both inbound and outbound direction key groups must be deconfigured before the key group can be removed (unbound). The inbound and outbound key groups must be deconfigured individually. Including keygroup-id is optional.

Use the following sequence of CLI commands to change key groups:

1. Remove the inbound direction key group.

2. Change the outbound direction key group.

3. Install the new inbound direction key group.

To delete a key group from a 7705 SAR, the key group must be removed (unbound) from all SDPs, VPRN services, router interfaces, and Layer 2 NGE-encrypted Ethernet ports that use it.

To locate the key group bindings, use the CLI command show>group-encryption> encryption-keygroup keygroup-id.

Use the following CLI syntax to delete a key group:

CLI syntax:

config# group-encryption 
    no encryption-keygroup keygroup-id 

Example:

config>grp-encryp# no encryption-keygroup 8