iSec is a new Layer 3 encryption technology that can be considered an enhancement to IPsec. It is easy to deploy and expand and provides high-quality security assurance for point-to-multipoint Internet data transmission.

Benefits of iSec

As network scales rapidly expand, the traditional security encryption technology IPsec commonly used in networks encounters the following bottlenecks:

· Network scale and configuration complexity limitations—IPsec can only establish point-to-point encrypted tunnels. If multiple nodes exist in the network, tunnels must be established between each pair of nodes. The number of encrypted tunnels and configuration complexity increase exponentially as the number of nodes grows, significantly raising maintenance challenges. Therefore, IPsec is not applicable to large-scale networks.

· Coupling between encryption and network architecture—IPsec requires deploying standalone encrypted tunnels, creating overlay deployment issues and increasing network complexity.

· Key negotiation and scalability issue—IPsec relies on the IKE protocol to negotiate keys node by node, limiting its scalability.

· Performance and reliability issue—IPsec in tunnel mode involves multi-layer encapsulation that affects throughput, and reliability policies require separate deployment.

iSec solves the preceding issues with the following features:

· Using the BGP expansion protocol to enable point-to-multipoint negotiation—iSec distributes encryption policies to multiple nodes through a single-point configuration, avoiding individual tunnel deployment. In a network with N nodes, if you use IPsec, you must configure IPsec for a maximum of N*(N-1) times, as each encrypted tunnel on each node corresponds to bidirectional SAs. If you use iSec, you only need to configure the iSec security policy once for each of the N nodes. If new nodes are added, you only need to add BGP configurations.

· Encryption capability through routes—In iSec, encryption is decoupled from the tunnel. The service data is encrypted through the information carried in routes, without the need for an additional tunnel and simplifying network design. In an SRv6 scenario, iSec encryption capabilities can directly inherit the reliability mechanisms of the service tunnel (such as tailend protection and TI-LFA FRR), reducing service recovery time and simplifying network design.

· Automated key negotiation—iSec uses dynamic key computation materials generated by the DH algorithm, which can be carried in BGP routing information for multipoint synchronization updates.

· High performance—iSec encapsulates fields directly into the original packet and enhances packet processing efficiency by using encryption through routes.

iSec security services

iSec offers two key security mechanisms: authentication and encryption. The authentication mechanism allows the recipient of IP communication data to acknowledge the sender's true identity and whether the data has been tampered with during transmission. The encryption mechanism ensures data confidentiality by encrypting data to prevent eavesdropping during transmission.

Security association

Before the iSec security mechanism takes effect, a security association (SA) is established between the two endpoints of iSec encryption, which are peers to each other. A security association (SA) is an agreement negotiated between two iSec peers. It includes the security protocols, encryption algorithm, authentication algorithm, key-related information, and the SA's lifetime.

An SA is uniquely identified by a security parameter index (SPI), which is carried in the encrypted encapsulation to help the receiving end determine the security policy to execute for the packet.

SA information is exchanged through the BGP protocol. After peers exchange information, they negotiate to establish an SA. After an SA is established, as long as the relevant configurations are not deleted, the BGP neighborhood between iSec peers will be maintained, and the SA will remain valid.

An SA is a unidirectional logical concept. Two SAs are needed to protect data flows in a bidirectional communication. For each pair of iSec peers, two SAs are established at each end: one for sending packets and one for receiving packets.

iSec authentication and encryption

ESP security protocol

Currently, iSec supports only the Encapsulating Security Payload (ESP) protocol. ESP provides data encryption, source authentication, data integrity checks, and anti-replay functions. ESP encrypts protected user data before encapsulating it into IP packets to ensure data confidentiality.

The encapsulation method of the ESP protocol involves inserting an ESP header after the IP header of an IP packet, followed by an ESP trailer and authentication data (ICV, Integrity Check Value) after the data payload.

In an SRv6 network, an ESP-encapsulated is as shown in Figure 1.

Figure 1 ESP encapsulation structure

ESP encryption covers the payload (the data from the transport layer and above) and the ESP trailer. The authentication section includes the ESP header, payload, and ESP trailer. Authentication verifies the integrity of data sources, ensuring that they are trustworthy and have not been tampered with. Encryption converts readable plaintext data into unreadable ciphertext data to protect data secrecy.

The ESP header includes the SPI and the anti-replay sequence number. The anti-replay sequence number is an incremental counter used to counter replay attacks. Replay attack prevention is not supported in the current software version.

Key exchange

Basic concepts

The encryption and decryption processes in iSec both require the use of a key. Plain text and a key generate ciphertext through an encryption algorithm, and the cipher text is restored to plain text through the key and a decryption algorithm.

iSec uses the same key for encryption and decryption. Therefore, iSec needs to share the key during the encrypted packet exchange between the two ends.

For security reasons, complete keys are prohibited from being transmitted directly over the network. Currently, there are two methods for sharing keys:

· Out-of-band sharing—iSec users share keys via email, face-to-face communication, or dedicated hardware devices. This method enhances security and effectively reduces the risk of key computation materials being intercepted during network transmission. However, this method has limited scalability and involves a huge workload for exchanging keys in a large-scale network, so it is not recommended. Currently, iSec does not support manual configuration of keys.

· Autonegotiation—Devices can freely exchange key computation materials using the BGP protocol. The SSL/TLS protocol can be used to securely encrypt BGP packets. The Diffie-Hellman (DH) algorithm is used generate key materials and compute the final key for use. With this three-pronged approach, iSec can dynamically exchange keys across multiple points without the need for manual key configuration.

DH algorithm

Using the DH algorithm, both parties in communication can generate a shared key without exchanging the actual key, simply by exchanging publicly available information.

Figure 2 Shows the DH key exchange process.

Figure 2 DH key exchange process

The specific process is as follows:

2. Device A and B exchange two prime numbers, P and G, where P is a very large prime number and G is a number related to P.

3. Device A and Device B each generate a random number, and the generated random number is known only to the respective device that generated it and is not disclosed to the other party.

4. Both parties use P and G to perform exponentiation and modular operations on random numbers, and send the results to each other.

5. Both parties will calculate the numbers received from each other.

¡ For Device A, calculate A to the power and then take mod P. The result is ((G^B mod P)^A) mod P.

¡ For Device B, calculate B to the power and then take mod P. The result is (G^A mod P)^B mod P.

6. Mathematically, it can be proven that (G^B mod P)^A mod P = (G^A mod P)^B mod P = G^(A×B) mod P. As a result, Device A and Device B calculated and obtained the same shared key.

Third-party devices on the network cannot compute the same key even if they obtain G, P, G^B mod P, and G^A mod P, because the important items used to compute the key are the confidential digits A and B, which are not transmitted over the network. Deriving A and B from G^B mod P and G^A mod P involves the discrete logarithm problem. However, since P is extremely large and no effective algorithm exists, it is considered infeasible.

The DH key group consists of prime numbers P and G, and the key group length refers to the bit length of P. A larger key group length indicates that it is more difficult to deduce A and B from G^B mod P and G^A mod P, thus enhancing security. DH key groups are divided into two categories:

· Common DH key group—Achieves key exchange by using the complexity of the discrete logarithm problem.

· Elliptic curve DH key group—Uses the complexity of the discrete logarithm problem on elliptic curves to perform key exchange. This type of key group offers significantly higher security than a common DH key group of the same bit length. For example, a 512-bit elliptic curve key group provides more security than a 2048-bit common key group.

Encryption and authentication process

Control plane encryption

Because BGP is used to transfer critical security information, such as data required for SA negotiation and key exchange materials, the secure transmission of BGP protocol packets must be ensured. The BGP protocol can multiplex the SSL/TLS protocol to establish secure connections between iSec peers. This provides data encryption, identity verification, and packet integrity verification functions for BGP protocol communication, enhancing the security of the entire iSec network.

For more information about SSL, see SSL configuration in Security Configuration Guide.

Data plane encryption and authentication

The following figure shows the process of data plane encryption and authentication between iSec peers.

Figure 3 iSec data plane encryption and authentication process

When Device A sends an encrypted packet to Device B, the detailed encryption and authentication process is as follows:

2. iSec peers use symmetric keys for encryption and authentication. A symmetric key enables both the sender and receiver to encrypt, decrypt, or authenticate data by using the same key. Encryption keys and authentication keys are two separate sets of keys. The keys used for encryption and authentication are derived through the DH algorithm from key calculation materials exchanged via BGP.

3. The packet sender encrypts the packet, and the supported encryption algorithms include:

¡ SM4-CBC—Use the SM4 algorithm in CBC mode with a 128-bit key.

4. The sender encrypts the packet and processes it using the HMAC authentication algorithm. HMAC combines a hash function and a key to calculate a fixed-length output called an Integrity Check Value (ICV). Currently supported authentication algorithms include:

¡ HMAC-MD5 authentication algorithm—The key length and output length are both 128 bits.

¡ HMAC-SM3 authentication algorithm—The key length and output length are both 256 bits.

5. The sender adds the ICV to the end of the encrypted packet and then sends both the encrypted packet and ICV to the receiver.

6. The receiver also uses the HMAC authentication algorithm to process the received encrypted packet.

7. The receiver compares the locally calculated ICV with the ICV carried in the received packet. If they are the same, it indicates that the received packet is complete and has not been tampered with, and passes authentication. If they differ, the received packet is untrustworthy and is discarded.

8. The receiver decrypts authenticated packets using the same algorithm to obtain plaintext packets.

BGP extension and iSec packet processing policy

In an iSec network, the BGP protocol primarily transmits various types of information for negotiating SA and materials for key calculations. To meet this requirement, the BGP protocol needs new capabilities. Additionally, which packets need to trigger the iSec encryption policy is related to the exchange of BGP routes. The following introduces the BGP extension and the iSec packet processing policy.

BGP extensions

BGP has added a new class of route attribute, the iSec attribute. The iSec attribute is a BGP tunnel encapsulation attribute. It is an optional attribute of BGP routes, primarily used to guide traffic encapsulation. Tunnel encapsulation attributes are organized in TLV format, with iSec attributes being private and containing all the information iSec needs to transmit.

The iSec attribute is carried in EVPN Ethernet autodiscovery routes. Currently, it supports the EVPN L3VPN over SRv6 scenario.

For more information about BGP, see BGP configuration in Layer 3—IP Routing Configuration Guide.

For more information about EVPN L3VPN over SRv6, see EVPN L3VPN over SRv6 configuration in Segment Routing Configuration Guide.

BGP routing and iSec packet processing policy

With its inline encryption capabilities, iSec can automatically establish SAs during BGP routing interactions, and encrypt and authenticate matching packets by using the corresponding iSec policy.

This section first introduces the SA negotiation mechanism in iSec, and then explains the relationship between routing, iSec policies, and packet forwarding.

SA negotiation mechanism

In an iSec network, SA negotiation is based on exchange of Ethernet autodiscovery routes. Ethernet autodiscovery routes in iSec differ from those in standard networks. They are only used to transmit security policy information in iSec. They do not advertise ES or service IDs, which are transmitted in standard EVPN networks. The generation of Ethernet autodiscovery routes involves the following concepts:

· Global EVPN—Used to configure global settings for iSec.

· Layer 3 source address—Configured in a global EVPN and used to generate the router distinguisher (RD) for Ethernet autodiscovery routes.

· ESI value—Configured in a global EVPN and used to distinguish different iSec policies. Each ESI value uniquely corresponds to an ESI alias, which simplifies configuration and reduces the workload associated with long ESI value strings.

· IPsec policy—Used by an ESI and contains DH key exchange parameters, slots for processing IPsec traffic, and the iSec transform set.

· IPsec proposal for iSec—Used by an iSec security policy and contains the encryption algorithm and authentication algorithm used by SAs.

Figure 4 SA negotiation process

As shown in Figure 4, the SA negotiation process for iSec is as follows:

2. In a global EVPN, for each ESI created, an Ethernet autodiscovery route with that ESI as a prefix is generated. The RD is the Layer 3 source address configured in a global EVPN, and the information carried in the iSec attribute is the security policy information used in the iSec policy of an ESI.

3. After an ESI alias is specified in a BGP-VPN instance, the Ethernet autodiscovery route associated with the ESI alias will carry the ERT corresponding to the VPN instance of that BGP-VPN instance. When carrying the RT attribute, Ethernet autodiscovery routes can be advertised to BGP neighbors. An alias can be specified for multiple BGP-VPN instances, and multiple aliases can be specified for a single BGP-VPN instance. When an alias is specified for multiple BGP-VPN instances, the corresponding Ethernet autodiscovery route will carry the ERTs of multiple VPN instances. When multiple aliases are specified for one BGP-VPN instance, the Ethernet autodiscovery routes corresponding to these aliases will all carry the ERT of that VPN instance.

4. The route receiver uses RT matching rules to determine whether to receive Ethernet autodiscovery routes. Accepted routes are added to the local BGP EVPN routing table.

5. After both parties successfully receive the Ethernet autodiscovery routes from each other and complete the redistribution, they negotiate to establish an SA. To establish SAs, both parties must receive Ethernet autodiscovery routes with the same ESI prefix . Each ESI creates a separate SA group.

iSec packet processing policy

After completing Ethernet autodiscovery, route exchange, and SA negotiation, the device matches packets with the iSec policy rules as shown in Figure 5.

Figure 5 iSec packet processing policy

For example, when Device B forwards a packet based on routes from Device A, the process of matching the iSec policy is as follows:

2. ESI alias 1 is specified in a BGP-VPN instance.

3. Based on the IP prefix generated in the private network routes in the BGP-VPN instance, the route will carry the ESI value corresponding to ESI alias 1.

4. The route sender advertises the IP prefix route carrying the ESI value to the iSec peer.

5. When the route receiver receives the IP prefix route, it compares the carried ESI value with the locally received Ethernet autodiscovery route prefix. If there is an Ethernet autodiscovery route with the same prefix ESI value, it associates the IP prefix route with the Ethernet autodiscovery route. If there is no Ethernet autodiscovery route with the same ESI prefix value, the IP prefix route will not take effect and cannot be selected.

6. When the route receiver forwards packets that the match IP prefix, it uses the iSec policy corresponding to ESI 1 of the autodiscovery route associated with the IP prefix route to authenticate and encrypt the packets.

Configuring iSec

iSec tasks at a glance

To configure iSec, perform the following tasks:

1. Building an SRv6 VPN network

2. Configuring an iSec security policy

3. Configuring global EVPN

4. Configuring the iSec feature for the BGP protocol

5. (Optional.) Configuring BGP peers to establish secure connections through the SSL protocol

6. (Optional.) Configuring a local router ID for iSec

Restrictions and guidelines: iSec configuration

This feature takes effect only when the operating mode of a subslot is set to iSec. For more information about the iSec mode of a subslot, see device management in Fundamentals Configruation Guide.

Building an SRv6 VPN network

About this task

iSec is primarily used in an SRv6 VPN network and currently supports only EVPN L3VPN over SRv6. For more information, see EVPN L3VPN over SRv6 configuration in Segment Routing Configuration Guide.

Configuring an iSec security policy

About this task

All iSec encryption and authentication-related information is configured in an iSec security policy, including DH key exchange parameters, slots for handling iSec traffic, and encryption and authentication algorithms.

Procedure

1. Enter system view.

system-view

2. Create a failover group and enter its view, or enter the view of an existing failover group.

failover group group-name [ id group-id ] [ type { default | isec | waas } ]

By default, no failover group exists. (Devices that do not support auto failover groups.)

By default, the automatic failover group with its name including AutoBackup exists and no manual failover groups exist.(Devices that support auto failover groups.)

When you create a failover group, you must specify a group ID. When you enter failover group view, a group ID is optional.

3. Assign a node to a failover group.

bind slot slot-number [ subslot subslot-number ] { primary | secondary }

By default, a failover group has no nodes.

The primary node and the secondary node in a failover group cannot be the same node. Different failover groups cannot share the same primary node.

4. Return to system view.

quit

5. Create a service instance group and enter its view, or enter the view of an existing service instance group.

service-instance-group service-instance-group-name [ type { default | isec | waas } ]

6. Associate a failover group with the service instance group.

failover-group failover-group-name

By default, a service instance group is not associated with any failover groups.

7. Create an iSec security policy and enter iSec security policy view.

isec policy policy-name

By default, no iSec security policy exists.

8. Specify a DH group to be used for key negotiation.

exchange-dh { group15 | group16 | group19 | group20 | group21 } *

By default, no DH group is specified.

9. Specify an iSec transform set for the iSec security policy.

transform-set transform-set-name &<1-6>

By default, no iSec transform set is specified.

10. Bind a service instance group to the iSec security policy.

service-instance-group group-name

By default, no service instance group is bound to any iSec security policy.

11. Return to system view.

quit

12. Create an iSec transform set and enter iSec transform set view.

isec transform-set transform-set-name

By default, no iSec transform set exists.

13. Specify an authentication algorithm for the ESP protocol.

esp authentication-algorithm { md5 | sm3 }

By default, no authentication algorithm is specified.

14. Specify an encryption algorithm for the ESP protocol.

esp encryption-algorithm sm4-cbc

By default, no encryption algorithm is specified.

Configuring global EVPN

About this task

Global EVPN carries ESI-related configurations and route-associated information, including the ESI, iSec security policy, and source address.

Procedure

1. Enter system view.

system-view

2. Enter global EVPN view.

evpn global

By default, no global EVPN view exists.

3. Configure the Layer 3 source address for EVPN.

evpn esi-l3 source-address ipv4-address

By default, no Layer 3 source address is configured for EVPN.

4. Create a type-200 ESI and its corresponding alias, and enter ESI view.

esi type-200 esi-id alias esi-name

By default, no ESI exists.

5. Specify an iSec security policy for the ESI.

isec-policy policy-name

By default, no iSec security policy is specified.

Configuring the iSec feature for the BGP protocol

About this task

Between iSec peers, configure the BGP protocol as follows:

· Execute the peer advertise auto-discovery isec command to advertise Ethernet autodiscovery routes with iSec attributes to the peer.

· Execute the evpn ip-prefix recursive-lookup auto-discovery command to enable the capability that associates IP prefix route with Ethernet autodiscovery routes.

· To encrypt traffic guided by IP prefix routes with iSec, make sure the IP prefix route carries an ESI value. You can achieve this by using the following methods:

¡ Execute the default esi name command in the BGP-VPN-instance for IP prefix routes.

¡ The sender of the IP prefix route is configured with a routing policy, and the default esi name command is executed in the routing policy. For more information about this command, see routing policy commands in Layer 3—IP Routing Command Reference.

· To advertise Ethernet autodiscovery routes with a specific ESI prefix, execute the esi name command.

The difference between the default esi name command and the esi name command is as follows:

· The default esi name command is used to associate an ESI with an IP prefix route. The command specifies an ESI alias that generates an Ethernet autodiscovery route with the corresponding ESI value as a prefix, carrying the iSec attribute and the RT of the corresponding VPN instance. However, only one ESI alias can be specified for one address family.

· The esi name command is used to generate an Ethernet autodiscovery route. The route uses the alias's ESI value as a prefix and includes iSec attributes and the corresponding VPN instance's RT. You can execute the command multiple times for one address family to flexibly set the RT attribute for Ethernet autodiscovery routes.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

For more information about this command, see Layer 3—IP Routing Command Reference.

3. Enter BGP EVPN address family view.

address-family l2vpn evpn

For more information about this command, see EVPN Command Reference.

4. Advertise Ethernet autodiscovery routes with iSec attributes to a BGP EVPN peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise auto-discovery isec

By default, no Ethernet autodiscovery routes with iSec attributes can be advertised to BGP EVPN peers or peer groups.

5. Return to BGP instance view.

quit

6. Enter BGP-VPN IPv4 unicast address family view or BGP-VPN IPv6 unicast address family view.

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

7. Associate IP prefix route with Ethernet autodiscovery routes.

evpn ip-prefix recursive-lookup auto-discovery

By default, IP prefix routes are not associated with Ethernet autodiscovery routes. Whether an IP prefix route takes effect is regardless of an Ethernet autodiscovery route.

8. Configure the Ethernet autodiscovery route to carry the VPN instance ERT, and set the ESI value carried by the IP prefix route generated under the current address family to the ESI value corresponding to the specified ESI alias.

default esi name esi-name

By default, Ethernet autodiscovery routes do not carry the VPN instance's ERT, and IP prefix routes do not carry the ESI value corresponding to the alias specified in this command.

9. Configure Ethernet autodiscovery routes to carry the VPN instance ERT.

esi name esi-name

By default, Ethernet autodiscovery routes do not carry the ERT of the VPN instance.

Configuring BGP peers to establish secure connections through the SSL protocol

About this task

Secure Socket Layer (SSL) is a security protocol that ensures communication privacy. BGP peers can use the SSL protocol to establish secure connections, which provides data encryption, identity verification, and packet integrity verification for BGP communication. In an iSec network, SSL-encrypted BGP connections between iSec peers can ensure secure transmission of iSec security policy information.

For more information about SSL, see SSL configuration in Security Configuration Guide.

For the device to act as an SSL server, execute the ssl-policy role command to specify the its role as an SSL server. Execute the peer ssl-server certificate command to enable the SSL certificate verification function, and execute the peer ssl-policy name command to specify an SSL server policy.

For the device to act as an SSL client, execute the ssl-policy role command to specify the its role as an SSL client and execute the peer ssl-policy name command to specify an SSL client policy.

Restrictions and guidelines

When specifying the dynamic neighbor configuration command 'peer ssl-policy role', you must set the local SSL role to SSL server.

If a peer belongs to a peer group and this task is performed for both the peer and its peer group, the configuration for the peer will take effect.

In the SSL policy used in this function, verify the other party's digital certificate to successfully establish an SSL secure connection. You can apply for a digital certificate online or offline, or import it locally. For more information, see SSL or PKI configuration in Security Configuration Guide.

For more information about commands in this section, see Layer 3—IP Routing Command Reference.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view or BGP-VPN instance view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP-VPN instance view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

3. (Optional.) Enable server-side certificate verification in the SSL secure connection established with the a peer or peer group.

peer { group-name | ipv4-address | ipv6-address } ssl-server certificate

By default, the server-side certificate verification function is not enabled.

This command takes effect only when the device acts as an SSL server.

4. Specify the SSL role of the local end when establishing an SSL secure connection with a peer or peer group.

peer { group-name | ipv4-address | ipv6-address } ssl-policy role { client | server }

By default, no SSL role is specified.

5. Specify an SSL server policy or SSL client policy for establishing secure SSL connections with a peer or peer group.

peer { group-name | ipv4-address | ipv6-address } ssl-policy name ssl-policy-name

By default, no SSL server policy or SSL client policy is specified.

Configuring a local router ID for iSec

About this task

Currently, this function serves no practical purpose. Use it to adjust the display of certain fields and add an ID to the local device.

Procedure

1. Enter system view.

system-view

2. Configure a local router ID for iSec.

isec route-id route-id

By default, no local router ID is configured.

Display and maintenance commands for iSec

Execute display commands in any view and reset commands in user view.

Task	Command
Display iSec security policy information.	display isec policy [ policy-name ]
Display iSec transform set information.	display isec transform-set [ transform-set-name ]
Display iSec SA information.	display isec sa [ brief \| slot slot-number ]
Display the historical information related to iSec.	display isec history
Display the statistics for packets processed by iSec.	display isec statistics
Clear the historical information related to iSec.	reset isec history
Clear packet statistics for iSec.	reset isec statistics

iSec configuration examples

Example: Configuring iSec in an EVPN L3VPN over SRv6 BE network

Network configuration

As shown in Figure 6, the backbone network uses IPv6 and the private network uses IPv4. Deploy EVPN L3VPN over SRv6 BE between PE devices in the IPv6 backbone network to forward IPv4 private network packets through an SRv6 tunnel.

· Both CE 1 and CE 2 belong to in VPN 1.

· PE 1 and CE 1 establish an EBGP peer relationship to exchange VPN routing information. PE 2 and CE 2 establish an EBGP peer relationship to exchange VPN routing information.

· PEs achieve IPv6 network interoperability through IS-IS and exchange EVPN routing information via MP-IBGP.

· To ensure the security of data transmission in the IPv6 backbone network, deploy iSec between PEs to authenticate and encrypt private network user packets.

Network diagram

Figure 6 Network diagram

Table 1 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	XGE3/1/1	10.1.1.2/24	PE 2	Loop0	3, 3 to 128
PE 1	Loop0	1, 1 to 128		XGE3/1/1	10.2.1.1/24
	XGE3/1/1	10.1.1.1/24		XGE3/1/2	2002, 1 to 96
	XGE3/1/2	2001, 1 to 96	CE 2	XGE3/1/1	10.2.1.2/24
P:	Loop0	2, 2 to 128
	XGE3/1/1	2001, 2 to 96
	XGE3/1/2	2002, 2 to 96

Procedure

1. Configure IPv6 IS-IS on the PE and P devices in the backbone network to establish connectivity between them.

# Configure PE 1.

<PE1> system-view

[PE1] isis 1

[PE1-isis-1] is-level level-1

[PE1-isis-1] cost-style wide

[PE1-isis-1] network-entity 10.1111.1111.1111.00

[PE1-isis-1] address-family ipv6 unicast

[PE1-isis-1-ipv6] quit

[PE1-isis-1] quit

[PE1] interface loopback 0

[PE1-LoopBack0] ipv6 address 1::1 128

[PE1-LoopBack0] isis ipv6 enable 1

[PE1-LoopBack0] quit

[PE1] interface ten-gigabitethernet 3/1/2

[PE1-Ten-GigabitEthernet3/1/2] ipv6 address 2001::1 96

[PE1-Ten-GigabitEthernet3/1/2] isis ipv6 enable

[PE1-Ten-GigabitEthernet3/1/2] quit

# Configure P.

<P> system-view

[P] isis

[P-isis-1] is-level level-1

[P-isis-1] cost-style wide

[P-isis-1] network-entity 10.2222.2222.2222.00

[P-isis-1] address-family ipv6 unicast

[P-isis-1-ipv6] quit

[P-isis-1] quit

[P] interface loopback 0

[P-LoopBack0] ipv6 address 2::2 128

[P-LoopBack0] isis ipv6 enable

[P-LoopBack0] quit

[P] interface ten-gigabitethernet 3/1/1

[P-Ten-GigabitEthernet3/1/1] ipv6 address 2001::2 96

[P-Ten-GigabitEthernet3/1/1] isis ipv6 enable

[P-Ten-GigabitEthernet3/1/1] quit

[P] interface ten-gigabitethernet 3/1/2

[P-Ten-GigabitEthernet3/1/2] ipv6 address 2002::2 96

[P-Ten-GigabitEthernet3/1/2] isis ipv6 enable

[P-Ten-GigabitEthernet3/1/2] quit

[P] commit

# Configure PE 2.

<PE2> system-view

[PE2] isis

[PE2-isis-1] is-level level-1

[PE2-isis-1] cost-style wide

[PE2-isis-1] network-entity 10.3333.3333.3333.00

[PE2-isis-1] address-family ipv6 unicast

[PE2-isis-1-ipv6] quit

[PE2-isis-1] quit

[PE2] interface loopback 0

[PE2-LoopBack0] ipv6 address 3::3 128

[PE2-LoopBack0] isis ipv6 enable

[PE2-LoopBack0] quit

[PE2] interface ten-gigabitethernet 3/1/2

[PE2-Ten-GigabitEthernet3/1/2] ipv6 address 2002::1 96

[PE2-Ten-GigabitEthernet3/1/2] isis ipv6 enable

[PE2-Ten-GigabitEthernet3/1/2] quit

After the configuration is completed, PE 1, P, and PE 2 can establish IS neighbor relationships. Execute the display isis peer command to verify that the neighbors are in up state. Execute the display isis route ipv6 command to view the routes of the loopback interfaces learned between PEs.

2. Configure VPN instances on PEs to allow CE access.

# Configure PE 1.

[PE1] ip vpn-instance vpn1

[PE1-vpn-instance-vpn1] route-distinguisher 100:1

[PE1-vpn-instance-vpn1] vpn-target 111:1

[PE1-vpn-instance-vpn1] quit

[PE1] interface ten-gigabitethernet 3/1/1

[PE1-Ten-GigabitEthernet3/1/1] ip binding vpn-instance vpn1

[PE1-Ten-GigabitEthernet3/1/1] ip address 10.1.1.1 24

[PE1-Ten-GigabitEthernet3/1/1] quit

# Configure PE 2.

[PE2] ip vpn-instance vpn1

[PE2-vpn-instance-vpn1] route-distinguisher 100:1

[PE2-vpn-instance-vpn1] vpn-target 111:1

[PE2-vpn-instance-vpn1] quit

[PE2] interface ten-gigabitethernet 3/1/1

[PE2-Ten-GigabitEthernet3/1/1] ip binding vpn-instance vpn1

[PE2-Ten-GigabitEthernet3/1/1] ip address 10.2.1.1 24

[PE2-Ten-GigabitEthernet3/1/1] quit

# Assign an IP address to the interface on CE 1.

<CE1> system-view

[CE1] interface ten-gigabitethernet 3/1/1

[CE1-Ten-GigabitEthernet3/1/1] ip address 10.1.1.2 24

[CE1-Ten-GigabitEthernet3/1/1] quit

# Assign an IP address to the interface on CE 2.

<CE1> system-view

[CE2] interface ten-gigabitethernet 3/1/1

[CE2-Ten-GigabitEthernet3/1/1] ip address 10.2.1.2 24

[CE2-Ten-GigabitEthernet3/1/1] quit

After the configuration is completed, execute the display ip vpn-instance command on a PE to view the VPN instance configuration. Each PE can successfully ping the connected CE.

Take PE 1 and CE 1 as an example:

[PE1] display ip vpn-instance

Total VPN-Instances configured : 1

Total IPv4 VPN-Instances configured : 1

Total IPv6 VPN-Instances configured : 1

VPN-Instance Name RD Address family Create time

vpn1 100:1 N/A 2025/01/12 13:59:39

[PE1] ping -vpn-instance vpn1 10.1.1.2

Ping 10.1.1.2 (10.1.1.2): 56 data bytes, press CTRL+C to break

56 bytes from 10.1.1.2: icmp_seq=0 ttl=255 time=2.000 ms

56 bytes from 10.1.1.2: icmp_seq=1 ttl=255 time=0.000 ms

56 bytes from 10.1.1.2: icmp_seq=2 ttl=255 time=1.000 ms

56 bytes from 10.1.1.2: icmp_seq=3 ttl=255 time=0.000 ms

56 bytes from 10.1.1.2: icmp_seq=4 ttl=255 time=0.000 ms

--- Ping statistics for 10.1.1.2 in VPN instance vpn1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/0.600/2.000/0.800 ms

3. Establish an EBGP peer relationship between the PE and CE, and enable the PE to import VPN routes to BGP.

# Configure CE 1.

<CE1> system-view

[CE1] bgp 65410

[CE1-bgp-default] peer 10.1.1.1 as-number 100

[CE1-bgp-default] address-family ipv4 unicast

[CE1-bgp-default-ipv4] peer 10.1.1.1 enable

[CE1-bgp-default-ipv4] import-route direct

[CE1-bgp-default-ipv4] quit

[CE1-bgp-default] quit

Configure CE 2 in the same way CE 1 is configured. The only difference is that the BGP peer address is 10.2.1.1. (Details not shown.)

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] router-id 1.1.1.1

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 10.1.1.2 as-number 65410

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] peer 10.1.1.2 enable

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

Configure PE 2 in the same way PE 1 is configured. The only differences are the router ID is 3.3.3.3, the BGP peer address is 10.2.1.2, and the peer AS number is 65420. (Details not shown.)

Execute the display bgp peer ipv4 vpn-instance command on the PEs to verify that they have BGP peers in Established state with the CEs.

4. Establish MP-IBGP peer relationships between the PEs.

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] peer 3::3 as-number 100

[PE1-bgp-default] peer 3::3 connect-interface loopback 0

[PE1-bgp-default] address-family l2vpn evpn

[PE1-bgp-default-evpn] peer 3::3 enable

[PE1-bgp-default-evpn] quit

[PE1-bgp-default] quit

# Configure PE 2.

[PE2] bgp 100

[PE2-bgp-default] peer 1::1 as-number 100

[PE2-bgp-default] peer 1::1 connect-interface loopback 0

[PE2-bgp-default] address-family l2vpn evpn

[PE2-bgp-default-evpn] peer 1::1 enable

[PE2-bgp-default-evpn] quit

[PE2-bgp-default] quit

Execute the display bgp peer l2vpn evpn command to verify that the PEs have BGP peers in Established state with each other.

5. Specify a source address for the outer IPv6 header of SRv6-encapsulated EVPN IPv4 L3VPN packets on the PEs.

# Configure PE 1.

[PE1] segment-routing ipv6

[PE1-segment-routing-ipv6] encapsulation source-address 1::1

# Configure PE 2.

[PE2] segment-routing ipv6

[PE2-segment-routing-ipv6] encapsulation source-address 3::3

6. Configure an SRv6 locator on the PEs and advertise the locator through IGP.

# Configure PE 1.

[PE1-segment-routing-ipv6] locator aaa ipv6-prefix 1:1:1:: 112 static 8

[PE1-segment-routing-ipv6-locator-aaa] quit

[PE1-segment-routing-ipv6] quit

[PE1] isis 1

[PE1-isis-1] address-family ipv6 unicast

[PE1-isis-1-ipv6] segment-routing ipv6 locator aaa

[PE1-isis-1-ipv6] quit

[PE1-isis-1] quit

# Configure PE 2.

[PE2-segment-routing-ipv6] locator bbb ipv6-prefix 3:3:3:: 112 static 8

[PE2-segment-routing-ipv6-locator-bbb] quit

[PE2-segment-routing-ipv6] quit

[PE2] isis 1

[PE2-isis-1] address-family ipv6 unicast

[PE2-isis-1-ipv6] segment-routing ipv6 locator bbb

[PE2-isis-1-ipv6] quit

[PE2-isis-1] quit

7. Configure the PEs to add the End.DT4 SID attribute to VPN routes.

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] segment-routing ipv6 locator aaa evpn

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

# Configure PE 2.

[PE2] bgp 100

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] segment-routing ipv6 locator bbb evpn

[PE2-bgp-default-ipv4-vpn1] quit

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

Execute the display ipv6 routing-table command on the PEs to verify that the End.DT4 SIDs have been introduced into the routing table and SRv6 routes have been created for them.

Use PE 1 as an example:

[PE1] display ipv6 routing-table protocol srv6

Summary count : 8

SRv6 Routing table status : <Active>

Summary count : 8

Destination: 1:1:1::/128 Protocol : SRv6

NextHop : ::1 Preference: 4

Interface : InLoop0 Cost : 0

Destination: 1:1:1::100/128 Protocol : SRv6

NextHop : ::1 Preference: 4

Interface : InLoop0 Cost : 0

Destination: 1:1:1::101/128 Protocol : SRv6

NextHop : ::1 Preference: 4

Interface : InLoop0 Cost : 0

Destination: 1:1:1::102/128 Protocol : SRv6

NextHop : ::1 Preference: 4

Interface : InLoop0 Cost : 0

Destination: 1:1:1::103/128 Protocol : SRv6

NextHop : ::1 Preference: 4

Interface : InLoop0 Cost : 0

Destination: 1:1:1::104/128 Protocol : SRv6

NextHop : FE80::3E08:4BFF:FE51:206 Preference: 4

Interface : GE0/0/2 Cost : 0

Destination: 1:1:1::105/128 Protocol : SRv6

NextHop : FE80::3E08:4BFF:FE51:206 Preference: 4

Interface : GE0/0/2 Cost : 0

Destination: 1:1:1::106/128 Protocol : SRv6

NextHop : FE80::3E08:4BFF:FE51:206 Preference: 4

Interface : GE0/0/2 Cost : 0

SRv6 Routing table status : <Inactive>

Summary count : 0

8. On the PEs, enable exchange of End.DT4 SIDs between the IPv6 peers, and resolve the VPN routes through recursive routing to the End.DT4 SID routes.

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] address-family l2vpn evpn

[PE1-bgp-default-evpn] peer 3::3 advertise encap-type srv6

[PE1-bgp-default-evpn] quit

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] segment-routing ipv6 best-effort evpn

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

# Configure PE 2.

[PE2] bgp 100

[PE2-bgp-default] address-family l2vpn evpn

[PE2-bgp-default-evpn] peer 1::1 advertise encap-type srv6

[PE2-bgp-default-evpn] quit

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] segment-routing ipv6 best-effort evpn

[PE2-bgp-default-ipv4-vpn1] quit

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

9. Configure the iSec feature on PE 1.

# Enter global EVPN view.

[PE1] evpn global

# Set the Layer 3 source address for EVPN to 1.1.1.1.

[PE1-evpn] evpn esi-l3 source-address 1.1.1.1

# Create a type-200 ESI and its corresponding alias, and enter ESI view.

[PE1-evpn] esi type-200 c800.0000.0000.0000.0120 alias esi1

# Specify iSec policy 100 for the ESI.

[PE1-evpn-esi-c800.0000.0000.0000.0120] isec-policy 100

[PE1-evpn-esi-c800.0000.0000.0000.0120] quit

[PE1-evpn] quit

# Configure the local router ID as 1.1.1.1.

[PE1] isec route-id 1.1.1.1

# Create failover group 1 and add nodes to the failover group.

[PE1] failover group 1 id 1 type isec

[PE1-failover-group-1]

[PE1-failover-group-1] bind slot 5 primary

[PE1-failover-group-1] bind slot 7 secondary

[PE1-failover-group-1] quit

# Create service instance group group1 and associate it with failover group 1.

[PE1] service-instance-group group1 type isec

[PE1-service-instance-group-group1] failover-group 1

[PE1-service-instance-group-group1] quit

# Create iSec security policy 100, specify service instance group group1, specify iSec transform set 1, and use a 3072-bit DH group to exchange keys.

[PE1] isec policy 100

[PE1-isec-policy-100] service-instance-group group1

[PE1-isec-policy-100] transform-set 1

[PE1-isec-policy-100] exchange-dh group15

[PE1-isec-policy-100] quit

# Create iSec transform set 1, and configure the ESP protocol to use the SM4-CBC encryption algorithm and the SM3 authentication algorithm.

[PE1] isec transform-set 1

[PE1-isec-transform-set-1] esp encryption-algorithm sm4-cbc

[PE1-isec-transform-set-1] esp authentication-algorithm sm3

[PE1-isec-transform-set-1] quit

# Configure the iSec feature for the BGP protocol.

[PE1] bgp 100

[PE1-bgp-default] address-family l2vpn evpn

[PE1-bgp-default-evpn] peer 3::3 advertise auto-discovery isec

[PE1-bgp-default-evpn] quit

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] evpn ip-prefix recursive-lookup auto-discovery

[PE1-bgp-default-ipv4-vpn1] default esi name esi1

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

10. Configure the iSec feature on PE 2.

# Enter global EVPN view.

[PE2] evpn global

# Set the Layer 3 source address for EVPN to 1.1.1.1.

[PE2-evpn] evpn esi-l3 source-address 3.3.3.3

# Create a type-200 ESI and its corresponding alias, and enter ESI view.

[PE2-evpn] esi type-200 c800.0000.0000.0000.0120 alias esi1

# Specify iSec policy 100 for the ESI.

[PE2-evpn-esi-c800.0000.0000.0000.0120] isec-policy 100

[PE2-evpn-esi-c800.0000.0000.0000.0120] quit

[PE2-evpn] quit

# Configure the local router ID as 3.3.3.3.

[PE2] isec route-id 3.3.3.3

# Create failover group 1 and add nodes to the failover group.

[PE2] failover group 1 id 1 type isec

[PE2-failover-group-1]

[PE2-failover-group-1] bind slot 5 primary

[PE2-failover-group-1] bind slot 7 secondary

[PE2-failover-group-1] quit

# Create service instance group group1 and associate it with failover group 1.

[PE2] service-instance-group group1 type isec

[PE2-service-instance-group-group1] failover-group 1

[PE2-service-instance-group-group1] quit

# Create iSec security policy 100, specify service instance group group1, specify iSec transform set 1, and use a 3072-bit DH group to exchange keys.

[PE2] isec policy 100

[PE2-isec-policy-100] service-instance-group group1

[PE2-isec-policy-100] transform-set 1

[PE2-isec-policy-100] exchange-dh group15

[PE2-isec-policy-100] quit

# Create iSec transform set 1, and configure the ESP protocol to use the SM4-CBC encryption algorithm and the SM3 authentication algorithm.

[PE2] isec transform-set 1

[PE2-isec-transform-set-1] esp encryption-algorithm sm4-cbc

[PE2-isec-transform-set-1] esp authentication-algorithm sm3

[PE2-isec-transform-set-1] quit

# Configure the iSec feature for the BGP protocol.

[PE2] bgp 100

[PE2-bgp-default] address-family l2vpn evpn

[PE2-bgp-default-evpn] peer 1::1 advertise auto-discovery isec

[PE2-bgp-default-evpn] quit

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] evpn ip-prefix recursive-lookup auto-discovery

[PE2-bgp-default-ipv4-vpn1] default esi name esi1

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

Verifying the configuration

1. View BGP EVPN routes on PE 1.

<PE1> display bgp l2vpn evpn

BGP local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of routes from all PEs: 2

Route distinguisher: 100:1

Total number of routes: 3

* >i Network : [1][c800.0000.0000.0000.0120][4294967295]/120

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 0

MED : 0

Path/Ogn: i

* >e Network : [5][0][24][10.1.1.0]/80

NextHop : 10.1.1.2 LocPrf :

PrefVal : 0 OutLabel : NULL

MED : 0

Path/Ogn: 65410?

* >i Network : [5][0][24][10.2.1.0]/80

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 3

MED : 0

Path/Ogn: 65420?

Route distinguisher: 1.1.1.1:0

Total number of routes: 1

* > Network : [1][c800.0000.0000.0000.0120][4294967295]/120

NextHop : 0.0.0.0 LocPrf : 100

PrefVal : 32768 OutLabel : NULL

MED : 0

Path/Ogn: i

Route distinguisher: 3.3.3.3:0

Total number of routes: 1

* >i Network : [1][c800.0000.0000.0000.0120][4294967295]/120

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 0

MED : 0

Path/Ogn: i

PE 1 successfully generated IP prefix routes originating from the private network and Ethernet autodiscovery routes based on its ESI value. It also successfully received the IP prefix routes advertised by the peer for the private network and the Ethernet autodiscovery routes advertised by the peer.

2. View detailed information about the received IP prefix routes on PE 1.

<PE1> display bgp l2vpn evpn [5][0][24][10.2.1.0]/80

BGP local router ID: 1.1.1.1

Local AS number: 100

Route distinguisher: 100:1

Total number of routes: 1

Paths: 1 available, 1 best

BGP routing table information of [5][0][24][10.2.1.0]/80:

From : 3::3 (3.3.3.3)

Rely nexthop : FE80::3E08:4BFF:FE51:206

Original nexthop: 3::3

Out interface : Ten-GigabitEthernet3/1/2

Route age : 00h05m52s

OutLabel : 3

Ext-Community : <RT: 111:1>

RxPathID : 0x0

TxPathID : 0x0

PrefixSID : End.DT4 SID <3:3:3::103>

SRv6 Service TLV (37 bytes):

Type: SRV6 L3 Service TLV (5)

Length: 34 bytes, Reserved: 0x0

SRv6 Service Information Sub-TLV (33 bytes):

Type: 1 Length: 30, Rsvdl: 0x0

SID Flags: 0x0 Endpoint behavior: 0x13 Rsvd2: 0x0

SRv6 SID Sub-Sub-TLV:

Type: 1 Len: 6

BL: 112 NL: 0 FL: 16 AL: 0 TL: 0 TO: 0

AS-path : 65420

Origin : incomplete

Attribute value : MED 0, localpref 100, pref-val 0

State : valid, internal, best

Source type : local

IP precedence : N/A

QoS local ID : N/A

Traffic index : N/A

EVPN route type : IP prefix advertisement route

ESI : c800.0000.0000.0000.0120

Ethernet tag ID : 0

IP prefix : 10.2.1.0/24

Gateway address : 0.0.0.0

MPLS label : 3

Tunnel policy : NULL

Rely tunnel IDs : N/A

Re-origination : Disable

The IP prefix routes from PE 2 carry the SID attribute and ESI value.

3. View BGP VPNv4 routes on PE 2. (Details not shown.)

4. View established iSec SAs.

# Use PE 1 as an example.

<PE1> display isec sa

-----------------------------------------

iSec policy name: 100

-----------------------------------------

Local route-id: 1.1.1.1

Remote route-id: 3.3.3.3

Protected connection: c800.0000.0000.0000.0120:3.3.3.3

[Inbound ESP SA]

SPI: 1521745904 (0x5ab3fff0)

SA ID: 1 (0x00000001)

Transform set: ESP-ENCRYPT-SM4-CBC ESP-AUTH-SM3

Creation time: 2025/2/18 09:22:06

[Outbound ESP SA]

SPI: 3588426688 (0xd5e30bc0)

SA ID: 2 (0x00000002)

Transform set: ESP-ENCRYPT-SM4-CBC ESP-AUTH-SM3

Creation time: 2025/2/18 09:22:06

A set of SAs has been established between PE 1 and PE 2 based on the ESI value c800.0000.0000.0000.0120.

5. Users in the 10.1.1.0/24 network segment of CE 1 can ping users in the 10.2.1.0/24 network segment of CE 2, and vice versa.

13-Security Configuration Guide

iSec tasks at a glance

About this task

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

Display and maintenance commands for iSec

Network configuration

Network diagram

Procedure

Verifying the configuration

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us