Network Group Encryption overview
Network Group Encryption (NGE) is a mechanism for the end-to-end encryption of MPLS- or GRE-based traffic at the service level that does not require meshes of IPsec tunnels at the network layer. NGE is supported on 7705 SAR, 7705 SAR-Hm, VSR, and 7750 SR devices. With 7750 SR devices, only WLAN GW interface encryption is supported.
See the device documentation for information about the chassis variants that support NGE, and for detailed information about NGE operation on an NE.
NGE provides the following main levels of encryption to secure an IP/MPLS network:
-
Router interface and Ethernet port encryption— Layer 3 and Layer 2 user plane and control plane encryption
L2 encryption is supported for 7705 SAR NEs only
-
PW template encryption for L2 service PW templates:
L3 routing interface encryption and L2 Ethernet port encryption are supported in an NGE domain; see NGE domains.
NFM-P NGE management minimizes network downtime in the event of a catastrophic failure such as a natural disaster, and maintains network security functions and critical network traffic transmission during events such as unexpected NE reboots and link disruptions.
The NFM-P generates the keys for the participating NGE NEs. An NFM-P operator assigns encryption and authentication keys to a key group. The operator then associates NGE supported objects for inbound and outbound traffic with the key group, as required, and the NFM-P distributes the key group to each NE that hosts an associated NGE supported object. The keys in a key group are randomly generated by the NFM-P using the FIPS 140-2 standard.
NGE version support
The current NSP release only supports NGE version 2. To use NGE, all 7705 SAR NEs must be running Release 8.0 R4 or later, and all VSR and 7705 SAR-Hm NEs must be running Release 15.0 R4 or later.
NFM-P management of NGE
The NFM-P has a comprehensive suite of NGE functions that include the following:
-
selective key distribution only to service sites associated with a key group
-
automatic NGE configuration of sites added to an encrypted service
The NFM-P uses SNMP to deploy general NGE attributes to NEs, and SSH2 sessions to configure the key values. You can use an existing SSH2 user account on each NE, or, to facilitate the tracking of key value configuration activity, you can use the UserNGE account. The NFM-P creates the account on each participating NGE NE and uses the account only for creating and updating key values. The NFM-P user activity log records all NGE configuration activity.
In a key group, an NFM-P operator specifies the service objects that are to be encrypted using the key group, then initiates the encryption. The NFM-P then deploys the key group to each NE associated with the service objects; for example, the two NEs associated with an SDP, or the sites in an MP-BGP VPRN service.
The NFM-P subsequently configures the key group for outbound traffic, then the key group for inbound traffic, on each NE. The NGE key group associations are displayed on the properties form of each associated service object.
The NFM-P ensures that the keys on all NEs in a key group are synchronized.
If a service object associated with a key group is deleted by the NFM-P or through a CLI, the NFM-P removes the object association from the key group.
A connectivity loss between the NFM-P and participating NEs does not affect the existing encrypted services.
Prerequisites for NGE management
To use NGE, all nodes must be configured to provide reachability to the NFM-P.
All NGE nodes must be managed by the same NFM-P.
Some potential scenarios to allow for a node to be reachable include:
-
Out of band management – The node uses an out of band network to allow for NFM-P traffic. When the node comes back up, the NFM-P is reached using the out-band network and downloads the key group keys using this network.
-
In-band using GRT (RI encryption disabled) – The node can establish routing and control plane functions when it comes back online. Based on established routing, the NFM-P re-discovers the node, and sends SNMP and SSH messages to the node to update the required key groups.
-
In-band using GRT (RI encryption enabled) – IP exception ACLs are preconfigured in the network to allow SNMP traffic through RI encryption enabled interfaces. Note that when the node that was off-line comes back up, it will not be able to send or receive any control plane packets as the RI interface NGE keys are old. The node will need static routes for the SNMP/SSH traffic to and from the NFM-P to allow these packets to be routed. If the network is over a L2/L3 service provider, then the IP exception ACLs are required on the off-line node itself and the gateway node. If the node is part of a private IP/MPLS network the IP exception ACLs are required on the expected bordering nodes to the node that goes off-line.
The default ACLs allow reachability to the NFM-P to then update key groups with new keys to bring up RI encryption and other services that were using old keys. The default ACLs do not need to be used for normal NFM-P management traffic after the NFM-P updates key groups.
-
In-band using management VPRN service (preferred for 7705 SAR-Hm scenarios) – A default manually configured GRE-SDP with reachability to a gateway node and a default in-band management VPRN are configured, using the default GRE-SDP to reach the NFM-P. This VPRN could also be NGE encrypted using a key group that remains static (does not get rekeyed) for double encrypting the NFM-P traffic. When the node comes back on-line, this default VPRN service is available for the NFM-P to reach the node and update key groups.