Network Group Encryption

In This Chapter

This chapter provides information to configure network group encryption (NGE). Topics in this chapter include:

  1. NGE Overview
  2. NGE Global Encryption Label
  3. Key Groups
  4. Services Encryption
  5. QoS for NGE Traffic
  6. Statistics
  7. Remote Network Monitoring (RMON) Support
  8. Configuration Notes
  9. Configuring NGE with CLI
  10. NGE Command Reference

NGE Overview

The network group encryption (NGE) feature provides the ability to configure end-to-end encryption of MPLS-based user data traffic without the need to create and manage a mesh of IPSec tunnels to achieve an any-to-any connectivity model, as used in VPRN or VPLS services for example. Figure 111 illustrates any-to-any encryption of MPLS-based services

Figure 111:  Any-to-Any Encryption of MPLS-based Services  

The 7705 SAR provides two main types of encryption to secure MPLS services in an IP/MPLS network:

  1. SDP encryption for a variety of services (VLL, VPLS, VPRN)
  2. encryption for MP-BGP-based VPRN services

The NGE solution on the 7705 SAR is fully redundant. When an activity switch occurs, there is no traffic loss for any encrypted services. Operators that enable NGE encryption can choose the specific MPLS services they would like encrypted depending on their security requirements and needs per service.

NGE is supported on the following adapter cards and platforms:

  1. 7705 SAR-8/7705 SAR-18: 8-port Gigabit Ethernet Adapter card
  2. 7705 SAR-8/7705 SAR-18: 6-port Ethernet 10Gbps Adapter card
  3. 7705 SAR-18: 10-port 1GigE/1-port 10GigE X-Adapter card
  4. 7705 SAR-H (NGE is also supported over T1/E1 interfaces using the 4-port T1/E1 and RS-232 Combination module)
  5. 7705 SAR-Hc
  6. 7705 SAR-W
  7. 7705 SAR-Wx
  8. 7705 SAR-X

This section contains information on the following topics:

  1. NGE Security Domains and Encryption Partitions
  2. 5620 SAM Management

NGE Security Domains and Encryption Partitions

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 to use specific key groups depending on security policies for the service and network topology.

Figure 112 illustrates a typical application of NGE key-group partitioning.

In the Figure 112 scenario, 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 might be considered less critical than the Transmission or Distribution Substation network equipment. It is ideal to ensure that nodes more at risk of a security breach do not contain more critical information than is necessary. To this end, encryption keys for the sensitive portions of the network should not be available on nodes that are at risk. The 7705 SAR NGE feature enables operators to partition and distribute encryption keys between different domains or groups in a network. NGE partitions are enabled by configuring different key groups per security partition.

For example, assume an attacker attempts to gain access to the network from a DA/FAN location where the physical installation of equipment in remote locations and a large number of devices could make those locations more prone to attack, and NGE has partitioned this part of the network. Because those devices do not contain any highly sensitive key-group information used for other parts of the network, the attacker is limited in the potential scope of any attack.

Figure 112:  Key-Group Partitioning 

Another application of key-group partitioning allows different parts of an organization to have a method of end-to-end communication without the need to share keys or key security policies across the entire network. If two domains need to communicate between domains, gateway nodes could be configured with both key groups and gateway functionality between various encryption domains, as needed.

5620 SAM Management

The NGE feature is tightly integrated with the 5620 SAM for key-group management associated with MPLS services that are configured on nodes and for encryption-service provisioning on a network-wide basis. The following functions are provided by the 5620 SAM :

  1. managing and synchronizing keys within key groups on a network-wide basis
  2. configuring NGE by downloading relevant key groups to nodes with NGE enabled
  3. managing network-wide re-keying of key values within key groups
  4. managing services that are encrypted by ensuring that only the nodes that need specific key groups have those key groups downloaded

The 5620 SAM acts as the key server for the nodes and provides the keys in key groups that are used to perform encryption and authentication. The 5620 SAM ensures that all nodes in a key group are kept in synchronization and that only the key groups that are relevant to a particular node are downloaded with sensitive keys.

The 5620 SAM also provides the function of re-keying a key group with zero outage time during the re-key procedure. Different key groups can be re-keyed at different times, if desirable, or all key groups can be re-keyed network-wide at the same time.

For more information on 5620 SAM management, refer to the “Service Management” section in the Alcatel-Lucent 5620 SAM User Guide.

NGE Global Encryption Label

The global encryption label must be a unique network-wide label (that is, 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 that node.

The label is used for identifying packets that have an NGE encrypted payload.

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

The 5620 SAM helps coordinate the distribution of the global encryption label and ensures that all nodes in the network are using the same global encryption label.

Key Groups

Key groups are used to organize encryption keys into distinct groups that allow a user to partition the network based on security requirements. A key group contains the following elements:

  1. an encryption algorithm—see Key Group Algorithms
  2. an authentication algorithm—see Key Group Algorithms
  3. a list of security associations (SAs)—see Security Associations (SAs)
  4. an active outbound SA—see Active Outbound SA

Figure 113 illustrates the use of key groups (KGs), security associations (SAs), and security parameter indices (SPIs). The 7705 SAR-8 Shelf V2 and 7705 SAR-18 both have the same set of key groups configured. One path uses key group 1 (KG1) and the other uses key group 2 (KG2). Each key group contains the elements listed above. Key group 1 has four live keys, SPI_1 through SPI_4, and SPI_3 is the active outbound SA. The active outbound SA is identified by its SPI, and this SPI is embedded in the NGE packet.

Each SA listed in a key group, indexed by an SPI, specifies a single key for encryption and a single key for authentication. Packets transmitted or received that reference a particular SPI use the keys in the SA for that SPI when performing encryption and authentication.

Before enabling encryption, key groups must be configured on the node. Only after a key group is configured can it be assigned to an SDP or VPRN services.

Figure 113:  Key Groups and a Typical NGE Packet  

Key Group Algorithms

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 (see lists below). One encryption algorithm and one authentication algorithm must be selected per key group.

Encryption algorithms available per key group include:

  1. AES128 (a 128-bit key, requiring a 32-digit ASCII hexadecimal string)
  2. AES256 (a 256-bit key, requiring a 64-digit ASCII hexadecimal string)

Authentication algorithms available per key group include:

  1. HMAC-SHA-256 (a 256-bit key, requiring a 64-digit ASCII hexadecimal string)
  2. 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.

Encapsulating Security Payload (ESP)

The NGE feature uses the Encapsulating Security Payload (ESP) protocol according to IETF RFC 4303. ESP maintains data integrity, ensuring privacy and confidentiality for encrypted traffic.

The ESP protocol used by NGE relies on symmetric ciphers, meaning that the same key is used for encryption and decryption. The 7705 SAR supports Cipher Block Chaining (CBC) encryption mode. Block ciphers used by NGE include:

  1. AES128 with a 128-bit key using 128-bit blocks
  2. AES256 with a 256-bit key using 128-bit blocks

For authentication, the integrity check value (ICV) size is as follows:

  1. HMAC-SHA-256 (16 bytes or 128 bits)
  2. HMAC-SHA-512 (32 bytes or 256 bits)

Security Associations (SAs)

Each key group has a list of up to four SAs. An SA is a reference to a particular pair of encryption and authentication keys that can 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 as long as 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. Figure 113 illustrates these relationships.

As shown in Figure 113, each SA is referenced by a particular 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.

Note:

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 OS-encrypted form, which is indicated by the system-appended crypto keyword when an info command is run. The 7705 SAR OS also includes the crypto keyword with an admin>save operation so that the 7705 SAR OS 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).

Active Outbound SA

The active outbound SA is specified by the SPI referencing the specific SA used to encrypt and authenticate packets egressing the node for the SDP or service using the key group. The SPI value for the active outbound SA is included in the Encapsulating Security Payload (ESP) header of packets being encrypted and authenticated.

Services Encryption

The NGE feature provides the ability to encrypt MPLS services using key groups that are configured against these services. These services include:

  1. VLL service (Epipe and Cpipe)
  2. VPRN service using Layer 3 spoke-SDP termination
  3. IES service using Layer 3 spoke-SDP termination
  4. VPLS service using spoke and mesh SDPs
  5. routed VPLS service into a VPRN or IES
  6. MP-BGP-based VPRNs

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

For MP-BGP services, auto-bind is supported using LDP, GRE, RSVP-TE, or MPLS (LDP or RSVP-TE).

This section contains information on the following topics:

  1. Services Encryption Overview
  2. Assigning Key Groups to Services
  3. Pseudowire Switching for NGE Traffic
  4. Pseudowire Control Word for NGE Traffic
  5. VPRN Layer 3 Spoke-SDP Encryption and MP-BGP-based VPRN Encryption Interaction
  6. NGE and RFC 3107
  7. NGE Packet Overhead and MTU Considerations

Services Encryption Overview

NGE adds a global encryption label to the label stack for encrypting MPLS services. The global encryption label is used to identify NGE packets that are encrypted 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.

Figure 114 illustrates the NGE MPLS/GRE label stack. Figure 115 illustrates VPRN and PW (with control word) packet formats using NGE encryption.

Figure 114:  NGE MPLS/GRE Label Stack  
Figure 115:  NGE Encryption and Packet Formats  

Assigning Key Groups to Services

Assigning key groups to services requires configuring an inbound and outbound key group on a per-service basis, for directional processing (see Figure 116).

Figure 116:  Inbound and Outbound Key-Group Assignments 

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, then the node ensures that packets are either unencrypted or are using one of the valid key groups configured in the system.

In the majority of 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:

  1. easily enable NGE for existing services
  2. move services from one key-group domain to another domain without halting encryption

The NGE feature makes use of the 5620 SAM to help manage the assignment of key groups to services on a network-wide basis. Refer to the Alcatel-Lucent 5620 SAM User Guide for more information.

Pseudowire Switching for NGE Traffic

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:

  1. PW switch 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.
  2. PW switch 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.
  3. PW switch 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. The converse occurs in the reverse direction (that is, traffic from an unencrypted PW to an encrypted PW gets encrypted before it is sent).

See Pseudowire Switching for more information.

Pseudowire Control Word for NGE Traffic

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.

VPRN Layer 3 Spoke-SDP Encryption and MP-BGP-based VPRN Encryption Interaction

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:

  1. When VPRN encryption is enabled, all routes resolved via MP-BGP are encrypted or decrypted using the VPRN key group.
  2. 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.

  1. 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.
  2. 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.
  3. 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.

NGE and RFC 3107

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.

Note:

It is the responsibility of the network operator to ensure key group consistency across the RR.

NGE Packet Overhead and MTU Considerations

NGE adds overhead packets to services. Table 148 shows the additional overhead for the worst-case scenario. Additional overhead depends on which encryption and authentication algorithms are chosen.

Table 148:  NGE Overhead  

Item

Number of Bytes

Encryption label

4

ESP

24

ICV

32

Padding

17

Control word copy

4

Total

81

For MP-BGP-based VPRNs, the total is 77 bytes because the control word copy is not required.

The overhead values in Table 148 must be considered for services that are supported by NGE.

Note:

Currently, the port MTU has a default value of 1572 bytes. This value is too low for outbound traffic when NGE is enabled. Users must configure new MTU values to adjust for the overhead associated with NGE, as outlined below for MPLS-based and GRE-based services. For details on configuring MTU, refer to the “MTU Configuration Guidelines” section in the 7705 SAR OS Interface Configuration Guide.

The sample calculations in Table 149 show how NGE overhead affects SDP MTU and service MTU values for MPLS-based, GRE-based, and VPRN-based services. The calculations are with and without NGE enabled.

Table 149:  Accounting for NGE Overhead SDP and Service MTU — Sample Calculations   

Service Type

MTU Values With and Without NGE Enabled

MPLS-based services

SDP MTU (MPLS)

     = 1572 (network port MTU) – 14 (Ethernet header) – 4 (outer label) – 4 (inner label)

     = 1550 bytes (without NGE enabled)

     => 1469 bytes (with NGE enabled)

Service MTU (MPLS) considerations with NGE enabled

  1. Layer 3 spoke IP MTU (MPLS)
         = 1469 – 14 (inner Ethernet header)
         = 1455 bytes
  2. PW spoke SDP MTU (MPLS)
         = SDP MTU
         = 1469 bytes

GRE-based services

SDP MTU (GRE)

     = 1572 (network port MTU) – 14 (Ethernet header) – 20 (IP header) – 4 (GRE header)           – 4 (inner label)

     = 1530 bytes (without NGE enabled)

     => 1449 bytes (with NGE enabled)

Service MTU (GRE) considerations with NGE enabled

  1. Layer 3 Spoke IP MTU (GRE)
         = 1449 – 14 (inner Ethernet header)
         = 1435 bytes
  2. PW Spoke MTU (GRE)
         = SDP MTU
         = 1449 bytes

VPRN-based services

Each interface inherits its MTU from the SAP or spoke SDP to which it is bound and can be manually changed using the ip-mtu command.

MP-BGP-based VPRN services

The MTU of the egress IP interface is used. When NGE is enabled on a VPRN service, customers must account for the additional 77 bytes of overhead needed by NGE for any egress IP interface used by the VPRN service.

QoS for NGE Traffic

The 7705 SAR provides priority and scheduling for traffic into the encryption and decryption engines on nodes that support NGE. This is described for the following traffic directions:

  1. Network Ingress
  2. Network Egress

For information on QoS and QoS policies, refer to the 7705 SAR OS Quality of Service Guide. Also, since QoS for NGE is similar to QoS for IPSec, see QoS for IPSec for more information.

Network Ingress

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 Figure 117):

  1. the network QoS policy determines the forwarding class (FC) for the packet (item 1)
  2. 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)
  3. 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)
  4. after decryption, normal QoS processing takes place as if NGE was not enabled for the service (item 4).
Figure 117:  QoS for NGE Traffic (Network Ingress) 

For more information on QoS for network ingress, refer to the “Network Ingress” section in the 7705 SAR OS Quality of Service Guide.

Network Egress

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:

  1. 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
  2. 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 on QoS for network egress, refer to the “Network Egress” section in the 7705 SAR OS Quality of Service Guide.

Statistics

Statistics specific to NGE are counted for the following main areas:

  1. key group
  2. SPI
  3. MDA
  4. service

Remote Network Monitoring (RMON) Support

Remote network Monitoring (RMON) can be used in conjunction with NGE statistics to provide event and alarm reporting. This can be used by customers to detect security breaches of NGE traffic flows and provide real-time reporting of such events.

Threshold crossing alerts and alarms using RMON are supported for SNMP MIB objects, including NGE.

Configuration Notes

This section describes NGE configuration caveats.

  1. To enable NGE for an SDP or VPRN service, follow these steps:
    1. install the outbound direction key group on each node for the service
    2. install the inbound direction key group on each node for the service
  2. To change NGE from one key group to another key group for an SDP or VPRN service, follow these steps in order:
    1. remove the inbound direction key group from each node for the service
    2. change the outbound direction key group on each node for the service
    3. install the new inbound direction key group on each node for the service
  3. To disable NGE for an SDP or VPRN service, follow these steps in order:
    1. remove the inbound direction key group from each node providing the service
    2. remove the outbound direction key group from each node for the service
  4. 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.
  5. The key group bound to an SDP or service must be unbound from that SDP or service before the active outgoing SA for the key group can be removed.
  6. The active outgoing SA must be removed (deconfigured) before the SPI can be deleted from the SA list in the key group.
  7. The encryption or authentication algorithm for a key group cannot be changed if there are any SAs in the key group.
  8. The encryption configured on an SDP used to terminate the Layer 3 spoke SDP of a VPRN (enabled or disabled) always overrides any VPRN-level configuration for encryption. See VPRN Layer 3 Spoke-SDP Encryption and MP-BGP-based VPRN Encryption Interaction for more information.
  9. The 5620 SAM provides configuration parameters that are not configurable using the CLI. See 5620 SAM Management for more information.

Reference Sources

For information on supported IETF drafts and standards as well as standard and proprietary MIBS, refer to Standards and Protocol Support.