GDOI Encryption for IPv6 Data Traffic Using IPv6 Tunnels

Available Languages

Download Options

Currently Group Domain of Interpretation (GDOI) encryption is not supported for direct IPv6 data traffic. However, you can use GDOI encryption on IPv6 packets by applying the cryptography map on the physical interface with an IPv4 address and using IPv6 tunnels between the group members. IPv6 tunnels can be either 6to4 tunnels or multipoint generic routing encapsulation (mGRE) dynamic multipoint VPN (DMVPN) tunnels.

You can deploy a 6to4 tunnel with simple configuration; it is highly scalable to secure IPv6 traffic over an IPv4 network when compared with mGRE tunnels. 6to4 tunnels are not dependent on other protocols, so a 6to4 tunnel is the preferred solution.

GDOI Encryption on IPv6 Traffic Using mGRE DMVPN Tunnels

Basic hub-and-spoke topology with DMVPN for tunneling IPv6 packets in IPv4 GRE tunnels is used for GDOI encryption. Group Encrypted Transport VPN is used for securing all the IPv4 data, including the tunneled IPv6 packets, by applying the cryptography map on the physical interface.

DMVPN tunnels are dynamically created and a new spoke could be added in the future with no changes on the hub. When native IPv6 is supported by Group Encrypted Transport VPN, you can remove the DMVPN tunnel to make the migration easier.

Figure 1 shows the final packet under this solution. The blue portion gets encrypted by Group Encrypted Transport VPN.

The following explains how to configure DMVPN hub-and-spoke routers for IPv6. It covers only the necessary configuration for enabling DMVPN and IPv6. This configuration is a sample configuration; you should customize it to your correct corporate subnets and servers. Figure 2 shows the topology for testing. Corporate LAN v6 prefix: 2001:db8:1111::/64

Use the following configuration to verify Internet Key Exchange (IKE) connection between the group member and the key system for receive rekeys:

demo-gm1#
show crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst src state conn-id status

239.192.1.190 10.5.110.88 GDOI_REKEY 1071 ACTIVE

10.5.110.88 10.5.110.34 GDOI_IDLE 1070 ACTIVE

Verify whether the group member is participating in Group Encrypted Transport VPN encryption by executing the following command-line interface (CLI) command:

demo-gm1#
show crypto gdoi

GROUP INFORMATION

Group Name :
GETVPN-DEMO

Group Identity : 1357924756

Rekeys received : 1602

IPSec SA Direction : Both

Active Group Server : 10.5.110.88

Group Server list : 10.5.110.88

Rekey Received(hh:mm:ss) : 00:00:54

Rekeys received

Cumulative : 1602

After registration : 1602

ACL Downloaded From KS 10.5.110.88:

access-list deny udp any port = 848 any port = 848

access-list deny tcp any any port = 23

access-list deny tcp any port = 23 any

access-list deny esp any any

access-list deny tcp any port = 179 any

access-list deny tcp any any port = 179

access-list deny udp any port = 500 any port = 500

access-list deny ospf any any

access-list deny eigrp any any

access-list deny igmp any any

access-list deny pim any any

access-list deny ip any 224.0.0.0 0.0.255.255

access-list deny udp any any port = 123

access-list deny udp any any port = 161

access-list deny udp any any port = 514

access-list permit ip any any

KEK POLICY:

Rekey Transport Type : Multicast

Lifetime (secs) : 27129

Encrypt Algorithm : AES

Key Size : 128

Sig Hash Algorithm : HMAC_AUTH_SHA

Sig Key Length (bits) : 1024

TEK POLICY for the current KS-Policy ACEs Downloaded:

GigabitEthernet0/0:

IPsec SA:

spi: 0x94095CF2(2483641586)

transform: esp-aes esp-sha-hmac

sa timing:remaining key lifetime (sec): (34)

Anti-Replay(Time Based) : 5 sec interval

IPsec SA:

spi: 0x1F07791F(520583455)

transform: esp-aes esp-sha-hmac

sa timing:remaining key lifetime (sec): (824)

Anti-Replay(Time Based) : 5 sec interval

Verify whether the group member is receiving rekeys from the key system after its registration using the following CLI command:

demo-gm1#
show crypto gdoi gm rekey

Group GETVPN-DEMO (Multicast)

Number of Rekeys received (cumulative) : 3

Number of Rekeys received after registration : 3

Multicast destination address : 239.192.1.190

Rekey (KEK) SA information :

dst src conn-id my-cookie his-cookie

New : 239.192.1.190 10.5.110.89 1071 E7917829 C9BAD494

Current : 239.192.1.190 10.5.110.89 1071 E7917829 C9BAD494

Verify whether the IPv6 traffic between the host at branch-office 1 and the host at headquarters gets encrypted by Group Encrypted Transport VPN by using the following CLIs:

Check the number of packets encrypted in demo1-gm as follows:

demo-gm1#
show crypto ipsec sa | incl encaps

#pkts encaps: 3329, #pkts encrypt: 3329, #pkts digest: 3329

From demo-v6-host-1 in branch-office 1, ping demo-v6-host-3 in headquarters:

demo-v6-host-1#
ping ipv6 2001:DB8:1111::2 rep 1000

Check whether all the packets are encrypted in demo1-gm in branch-office 1:

demo-gm1#
show crypto ipsec sa | incl encaps

#pkts encaps: 4329, #pkts encrypt: 4329, #pkts digest: 4329

Verify whether the IPv6 traffic between the host in branch-office 1 and the host in branch-office 2 gets encrypted by Group Encrypted Transport VPN by using the following CLIs:

Check the number of packets encrypted in demo1-gm as follows:

demo-gm1#
show crypto ipsec sa | incl encaps

#pkts encaps: 10220, #pkts encrypt: 10220, #pkts digest: 10220

From demo-v6-host-1 in branch-office 1, ping demo-v6-host-2 in branch-office 2

demo-v6-host-1# ping ipv6 2001:DB8:CCCC:1::2 rep 1000

Check whether all the packets are encrypted in demo1-gm in branch-office 1:

demo-gm1#
show crypto ipsec sa | incl encaps

#pkts encaps: 11220, #pkts encrypt: 11220, #pkts digest: 11220

GDOI Encryption on IPv6 Traffic Using 6to4 Tunnels

IP 6to4 tunneling encapsulates IPv6 packets in IPv4 tunnels where a portion of the IPv4 address represents a portion of the IPv6 address. Group Encrypted Transport VPN is used for securing all the IPv4 data, including the tunneled IPv6 packets, by applying the cryptography map on the physical interface. The IP 6to4 tunnel uses only the IP protocol. IP 6to4 tunnels are efficient and simple to configure.

Figure 3 shows the final packet under this solution. The blue portion gets encrypted by Group Encrypted Transport VPN.

Figure 3. Packet Encapsulation Using 6to4 Tunnels

Solution Test Setup Topology

Solution test setup consists of two group-member routers, demo-gm1 and demo-gm2, located in branch offices and another group-member router, demo-gm3, located at headquarters. Demonstration setup also includes one key server, demo-ks1. A multicast rekey method is used. For the testing, "demo-getvpn" simulates the network. Cisco 3845 platform routers running the Cisco IOS Software 12.4(22)T IOS image are used.

• The tunnel is automatic; no enterprise-specific configuration is required at the 6to4 relay site. 6to4 tunnels scale well.

• This solution accommodates dynamic IP addresses at the enterprise.

• The tunnel exists only for the duration of the session.

• A 6to4 tunnel requires only a one-time configuration at the Internet service provider (ISP), making the 6to4 relay service available simultaneously to many enterprises.

• 6to4 tunnels are simple and efficient. They use only the IP protocol, and are not dependent on other protocols such as Hot Standby Router Protocol (HSRP) and EIGRP, whereas mGRE tunnels for IPv6 depend on other protocols.

• IP 6to4 uses an inferred /48 prefix for a site, allowing the operator to allocate subnets with the next 16 bits. It in effect provides 64,000 subnets to a given site while providing 64 bits for the host within each subnet.

Limitations of 6to4 Tunnels

6to4 tunnel usage has the following limitations:

• Independently managed Network Address Translation (NAT) is not allowed along the path of the tunnel.

• You cannot easily implement multihoming.

• The 6to4 tunnel mechanism provides a /48 address block; no more addresses are available. All 6to4 tunnels prepend IPv4 addresses with the 2002: prefix.

• Because 6to4 tunnels are configured many-to-one and tunnel traffic can originate from multiple endpoints, 6to4 tunnels can provide only overall traffic information to the ISP.

• 6to4 tunnel prefix: 2002:XXXX:XXXX::/64, where XXXX:XXXX is the IPv4 IP address of the tunnel source in hex. For example, demo-gm1 uses 10.5.110.34 as the tunnel source; the address can be represented in hex as 0a.05.6e.22. This hex address is embedded as a prefix in the v6 address on the VPN gateway. In our example, the v6 address would be 2002:A05:6E22::1/64, where the protected v6 hosts are assigned addresses in the space provided by XXXX:XXXX::Z. The destination to a remote v6 host is inferred from the target host assigned address.

Figure 4. Topology Diagram for Using IP 6to4 Tunnels

The routing of v6 packets is quite simple. The packets are encapsulated in 6to4 headers and routed out of the platform. If the 6to4 packet encounters a Group Encrypted Transport VPN cryptography map on the egress interface, the platform encrypts the v4 packet where the v6 frame is simply payload.

Group Encrypted Transport VPN configuration used in group members and key systems are the same as the configuration given in the section "GDOI Encryption on IPv6 Traffic Using mGRE DMVPN Tunnels". The following example uses 6to4 tunnels instead of a mGRE tunnel. Unlike mGRE tunnels, EIGRP configuration is not needed for 6to4 tunnels.

The following configurations show [[correct?]] an example 6to4 tunnel interface and routing statements.