Skip to main content

Cisco GET VPN

Group Encrypted Transport VPN

VPN Service Without Tunnels
Networks today need to support all forms of media-including data, voice, and video-to enhance business communications and lower operating costs. Voice and video applications are accelerating the need for instantaneous, branch-to-branch communications, while network security risks are increasing.
Cisco Group Encrypted Transport VPN, eliminates the need for compromise between network intelligence and data privacy in private WAN environments. Service providers can finally offer managed encryption without a provisioning and management nightmare since GET VPN simplifies the provisioning and management of VPN. GET VPN defines a new category of VPN, one that does not use tunnels.

Benefits
·       Simplifies branch-to-branch instantaneous communications — Ensures low latency and jitter by enabling full-time, direct communications between sites, without requiring transport through a central hub
·       Maximizes security — Provides encryption for MPLS networks while maintaining network intelligence such as full-mesh connectivity, natural routing path, and quality of service (QoS)
·       Complies with governmental regulation and privacy laws — Helps you meet security compliance and internal regulation by encrypting all WAN traffic
·       Offers management flexibility — Eliminates complex peer-to-peer key management with group encryption keys

Restrictions for Cisco Group Encrypted Transport VPN
·       If you are encrypting high packet rates for counter-based antireplay, ensure that you do not make the lifetime too long or it can take several hours for the sequence number to wrap. For example, if the packet rate is 100 kilopackets per second, the lifetime should be configured as fewer than 11.93 hours so that the SA is used before the sequence number wraps.
·       Transport mode should be used only for Group Encrypted Transport VPN Mode (GM) to GM traffic.
·       Crypto maps are not supported on tunnel interface and port-channel interface.


·       Because Path MTU Discovery (PMTUD) does not work for GET VPN, there is a possibility that encapsulated packets could be dropped when the df-bit is set and the MTU of an intermediate link is less than the size of the encapsulated packet. In such an event, the router that drops the packet sends a notification to the source IP address on the packet, indicating that the packet has been dropped because the router could not fragment the packet due to the df-bit setting. In GET VPN, this message goes past the encapsulating endpoint directly to the source of the data due to the header preservation feature of GET VPN. Thus, the encapsulating router never knows that it has to fragment the packet to a smaller size before setting the df-bit after encapsulation. It continues to set the df-bit on the packets and they continue to be dropped at the intermediate router. (This is known as black-holing the traffic.)

Comparison between IPSEC and GET VPN

IPSec Crypto
 GET Crypto
Main concept
Per link point-to-point security paradigm: each pair of devices establishes a separate security association.(figure3)
Group-based security paradigm: allows a set of network entities to connect through a single group security association.
Encapsulation
Requires the establishment of tunnel to secure the traffic between encrypting gateways.- a new header is added to the packet (figure4).- Limited QoS preservation (only ToS).
Tuneless: does not use tunnels and preserves the original src/dst IP in the header of the encrypted packet for optimal routing (figure6).- Preserve same established routing path.- Preserve entire QoS parameter set.
Multicast
– Traditional IPSec encapsulate multicast into encrypted PTP unicast GRE tunnels.- Alternatively, inefficient multicast replication at the HUB using DMVPN with many multicast deployment restrictions (RP, MA and multicast source location at the HUB).
GET VPN is particularly suited for multicast traffic encryption with native support. The WAN multicast infrastructure is used to transport encrypted GET-VPN multicast traffic.
Infrastructure
IPSec creates Overlay VPN and secures it over the Internet.
• Relies on MPLS/VPLS Any-to-Any VPN.• Direct Flows between all CE.• Leverages Existing VPNs.- GET VPN suited for enterprises running over MPLS private networks.- GET-VPN ONLY secure an already established VPN (MPLS-VPN), it doesn’t create it
Management
– Per-link security management: Each pair holds a security association for each other.- Resource consumption.- Alternative centralized HUB-based management with DMVPN though heterogeneous protocol suite (mGRE, NHRP)- Less scalable.
– Full mesh direct communications between sites.Same group members hold a single security association; don’t care about others on the group.- Relies on centralized membership management through key servers :A centralized entity (Key Server manage the control plane) and not involved in the data plane communication.Data plane communications don’t require transport through a hub HUB entity.- Low latency/jitter.
– More scalable.
Security Perimeter
Per-link
All Sites within the same group.
Routing
Two routing levels(figure5a):Core routing+Overlay routing between encrypting gateways
Single end-to-end routing level with MPLS-VPN as the underlying VPN infrastructure(figure6a).

Cisco Group Encrypted Transport VPN Architecture
GET VPN encompasses Multicast Rekeying, a way to enable encryption for “native” multicast packets, and unicast rekeying over a private WAN. Multicast Rekeying and GET VPN is based on GDOI as defined in Internet Engineering Task Force (IETF) RFC 3547.
GDOI
GDOI is defined as the Internet Security Association Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) for group key management. In a group management model, the GDOI protocol operates between a group member and a group controller or key server (GCKS), which establishes SAs among authorized group members. The ISAKMP defines two phases of negotiation. GDOI is protected by a Phase 1 ISAKMP security association. The Phase 2 exchange is defined in RFC 6407. The topology shown in the figure below and the corresponding explanation show how this protocol works.


Group Member
The group member registers with the key server to get the IPsec SA or SAs that are necessary to communicate with the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. These keys are refreshed periodically, and before the current IPsec SAs expire, so that there is no loss of traffic.
Key Server
The responsibilities of the key server include maintaining the policy and creating and maintaining the keys for the group. When a group member registers, the key server downloads this policy and the keys to the group member. The key server also rekeys the group before existing keys expire.

The key server has two responsibilities: servicing registration requests and sending rekeys. A group member can register at any time and receive the most current policy and keys. When a group member registers with the key server, the key server verifies the group ID that the group member is attempting to join. If this ID is a valid group ID, the key server sends the SA policy to the group member. After the group member acknowledges that it can handle the downloaded policy, the key server downloads the respective keys.
There are two types of keys that the key server can download: the key encryption key (KEK) and the traffic encryption key (TEK). The TEK becomes the IPsec SA with which the group members within the same group communicate. The KEK encrypts the rekey message.

The GDOI protocol is protected by an ISAKMP Phase 1 exchange. The GDOI key server and the GDOI group member must have the same ISAKMP policy. This Phase 1 ISAKMP policy should be strong enough to protect the GDOI protocol that follows. The GDOI protocol is a four-message exchange that follows the Phase 1 ISAKMP policy. The Phase 1 ISAKMP exchange can occur in main mode or aggressive mode.

Rekeying
Rekey messages are used to refresh IPsec SAs. When the IPsec SAs or the rekey SAs are about to expire, one single rekey message for a particular group is generated on the key server. No new IKE sessions are created for the rekey message distribution. The rekey messages are distributed by the key server over an existing IKE SA.
Rekeying can use multicast or unicast messages. GET VPN supports both unicast and multicast rekeying.

With CSCti89255, KEK rekeys before the KEK timer expires. The group member also starts a timer and expects to receive refreshed keys before timer expiration. If they are not received, the group member initiates a jittered re-registration prior to KEK expiry. KEK is deleted when the KEK lifetime expires. This ensure the following:
·       A safer KEK expiry checking mechanism
·       A safer KEK re-registration mechanism
·       Avoids use of KEK beyond configured lifetime

Configuration Example

Task-1: Configure GET VPN between R1, R2, R3 & R4 as GM-1, GM-2, GM-3 & GM-4 respectively, Configure Key Server with following parameters:

ISAKMP Parameters:
Encryption: 3DES
Hash: MD5
DH Group: 2
Authentication: Pre-Share
Key: cisco123

IPSEC Parameters:
Encryption: 3DES
Hash: SHA

GDOI Parameters:
Group Name: Cisco
Identity Number: 111
Server: Local
Address: 192.1.16.6
Interested Traffic: Source 10.1.0.0/16, Destination 10.1.0.0/26

Initial Configuration:

Key Server:

interface Ethernet0/0
 ip address 192.1.16.6 255.255.255.0
end

router eigrp 1
 network 192.1.16.0

R1 [Group Member -1]:

interface Ethernet0/0
 ip address 192.1.10.1 255.255.255.0
end

interface Ethernet0/1
 ip address 192.1.16.1 255.255.255.0
end

interface Loopback0
 ip address 10.1.1.1 255.255.255.0
end

router eigrp 1
 network 10.0.0.0
 network 192.1.10.0
 network 192.1.16.0

R2 [Group Member -2]:

interface Ethernet0/0
 ip address 192.1.20.2 255.255.255.0
end

interface Loopback0
 ip address 10.1.2.1 255.255.255.0
end

router eigrp 1
 network 10.0.0.0
 network 192.1.20.0

R3 [Group Member -3]:

interface Ethernet0/0
 ip address 192.1.30.3 255.255.255.0
end

interface Loopback0
 ip address 10.1.3.1 255.255.255.0
end
!
router eigrp 1
 network 10.0.0.0
 network 192.1.30.0

R4 [Group Member -4]:

interface Ethernet0/0
 ip address 192.1.40.4 255.255.255.0
end

interface Loopback0
 ip address 10.1.4.1 255.255.255.0
end

router eigrp 1
 network 10.0.0.0
 network 192.1.40.0

R5 [ISP]:

interface Ethernet0/0
 ip address 192.1.10.10 255.255.255.0
end

interface Ethernet0/1
 ip address 192.1.40.10 255.255.255.0
end

interface Ethernet0/2
 ip address 192.1.30.10 255.255.255.0
end

interface Ethernet0/3
 ip address 192.1.20.10 255.255.255.0
end

router eigrp 1
 network 0.0.0.0
Task-1: Configure GET VPN between R1, R2, R3 & R4 as GM-1, GM-2, GM-3 & GM-4 respectively, Configure Key Server with following parameters:

Solution:

Key Server: 

Step-1: Configure ISAKMP on Key Server [With all the GM’s]:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.10.1     
crypto isakmp key cisco123 address 192.1.20.2     
crypto isakmp key cisco123 address 192.1.30.3     
crypto isakmp key cisco123 address 192.1.40.4    
Step-2: Configure IPSEC Transform Set:

crypto ipsec transform-set GET-TSET esp-3des esp-sha-hmac 

Step-3: Configure IPSEC Profile:

crypto ipsec profile GET-PROF
 set transform-set GET-TSET 

Step-4: Configure Interested Traffic ACL:

access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255

Step-5: Configure GDOI Group:

crypto gdoi group CISCO
 identity number 111
 server local
  sa ipsec 1
   profile GET-PROF
   match address ipv4 101
  address ipv4 192.1.16.6

Configure Group Members:

R1 [Group Member -1]:

Step-1: Configure ISAKMP with Key Server to exchange session key:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.16.6  

Step-2: Configure GDOI Group:

crypto gdoi group ABC
 identity number 111
 server address ipv4 192.1.16.6

Step-3: Configure GDOI Crypto Map:

crypto map CMAP 1 gdoi 
 set group ABC

Step-4: Apply crypto map to WAN Interface:

interface Ethernet0/0
 crypto map CMAP
end

R2 [Group Member -2]:

Step-1: Configure ISAKMP with Key Server to exchange session key:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.16.6  

Step-2: Configure GDOI Group:

crypto gdoi group ABC
 identity number 111
 server address ipv4 192.1.16.6

Step-3: Configure GDOI Crypto Map:

crypto map CMAP 1 gdoi 
 set group ABC

Step-4: Apply crypto map to WAN Interface:

interface Ethernet0/0
 crypto map CMAP
end

R3 [Group Member -3]:

Step-1: Configure ISAKMP with Key Server to exchange session key:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.16.6  

Step-2: Configure GDOI Group:

crypto gdoi group ABC
 identity number 111
 server address ipv4 192.1.16.6

Step-3: Configure GDOI Crypto Map:

crypto map CMAP 1 gdoi 
 set group ABC


 Step-4: Apply crypto map to WAN Interface:

interface Ethernet0/0
 crypto map CMAP
end

R4 [Group Member -3]:

Step-1: Configure ISAKMP with Key Server to exchange session key:

crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key cisco123 address 192.1.16.6  

Step-2: Configure GDOI Group:

crypto gdoi group ABC
 identity number 111
 server address ipv4 192.1.16.6

Step-3: Configure GDOI Crypto Map:

crypto map CMAP 1 gdoi 
 set group ABC

Step-4: Apply crypto map to WAN Interface:

interface Ethernet0/0
 crypto map CMAP
end

Note: As soon as you apply crypto map to WAN interface your GM will get registered to KS and download the configuration from KS, you will get following message:

*Feb 25 03:41:30.311: %CRYPTO-5-GM_REGSTER: Start registration to KS 192.1.16.6 for group ABC using address 192.1.10.1 fvrf default ivrf default
*Feb 25 03:41:30.312: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Feb 25 03:41:30.313: %GDOI-5-GM_REGS_COMPL: Registration to KS 192.1.16.6 complete for group ABC using address 192.1.10.1 fvrf default ivrf default
*Feb 25 03:41:30.313: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 192.1.16.6 for group ABC & gm identity 192.1.10.1 fvrf default ivrf default

Verification:

Group Member:

R1#show crypto isakmp sa 
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.1.16.6      192.1.10.1      GDOI_IDLE         1001 ACTIVE


R1#show crypto ipsec sa

interface: Ethernet0/0
    Crypto map tag: CMAP, local addr 192.1.10.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
   remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
   Group: ABC
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.1.10.1, remote crypto endpt.: 0.0.0.0
     plaintext mtu 1446, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
     current outbound spi: 0xB3A0C220(3013657120)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xB3A0C220(3013657120)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 3, flow_id: SW:3, sibling_flags 80000040, crypto map: CMAP
        sa timing: remaining key lifetime (sec): 1444
        Kilobyte Volume Rekey has been disabled
        IV size: 8 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xB3A0C220(3013657120)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 4, flow_id: SW:4, sibling_flags 80000040, crypto map: CMAP
        sa timing: remaining key lifetime (sec): 1444
        Kilobyte Volume Rekey has been disabled
        IV size: 8 bytes
        replay detection support: N
        Status: ACTIVE(ACTIVE)


R1#show crypto gdoi
GROUP INFORMATION

    Group Name               : ABC
    Group Identity           : 111
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 0
    IPSec SA Direction       : Both

     Group Server list       : 192.1.16.6
                               
Group Member Information For Group ABC:
    IPSec SA Direction       : Both
    ACL Received From KS     : gdoi_group_ABC_temp_acl

    Group member             : 192.1.10.1      vrf: None
       Local addr/port       : 192.1.10.1/848
       Remote addr/port      : 192.1.16.6/848
       fvrf/ivrf             : None/None
       Version               : 1.0.8 
       Registration status   : Registered
       Registered with       : 192.1.16.6
       Re-registers in       : 1324 sec
       Succeeded registration: 2
       Attempted registration: 2
       Last rekey from       : 0.0.0.0
       Last rekey seq num    : 0
       Multicast rekey rcvd  : 0
       DP Error Monitoring   : OFF
       Active TEK Number     : 1

       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 0
       After latest register : 0
       Rekey Received        : never

 ACL Downloaded From KS 192.1.16.6:
   access-list   permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255

TEK POLICY for the current KS-Policy ACEs Downloaded:
  Ethernet0/0:
    IPsec SA:
        spi: 0xB3A0C220(3013657120)
        transform: esp-3des esp-sha-hmac 
        sa timing:remaining key lifetime (sec): (1419)
        Anti-Replay(Counter Based) : 64
        tag method : disabled
        alg key size: 24 (bytes)
        sig key size: 20 (bytes)
        encaps: ENCAPS_TUNNEL

R1#ping 10.1.2.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/7 ms

R1#ping 10.1.3.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms

R1#ping 10.1.4.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.4.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms

Key Server:

KEY-SERVER#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
192.1.16.6      192.1.40.4      GDOI_IDLE         1001 ACTIVE
192.1.16.6      192.1.10.1      GDOI_IDLE         1003 ACTIVE
192.1.16.6      192.1.30.3      GDOI_IDLE         1002 ACTIVE
192.1.16.6      192.1.20.2      GDOI_IDLE         1004 ACTIVE


KEY-SERVER#show crypto ipsec sa
No SAs found

KEY-SERVER#show crypto gdoi detail 
GROUP INFORMATION

    Group Name               : CISCO (Multicast)
    Re-auth on new CRL       : Disabled
    Group Identity           : 111
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Group Members            : 4
    IPSec SA Direction       : Both
    Group Rekey Lifetime     : 86400 secs
    Rekey Retransmit Period  : 10 secs
    Rekey Retransmit Attempts: 2

      IPSec SA Number        : 1
      IPSec SA Rekey Lifetime: 3600 secs
      Profile Name           : GET-PROF
      Replay method          : Count Based
      Replay Window Size     : 64
      Tagging method         : Disabled
      SA Rekey
         Remaining Lifetime  : 1312 secs
        Time to Rekey        : 931 secs
      ACL Configured         : access-list 101
          
     Group Server list       : Local
                               





Thank You !!!

Comments

Post a Comment

Popular posts from this blog

Flex VPN

Cisco FLEX VPN with IKEv2 Large customers deploying IPSec VPN over IP networks are faced with high complexity and high cost of deploying multiple types of VPN to meet different types of connectivity requirements. Customers often have to learn different types of VPNs to manage and operate different types of network. And once a technology is selected for a deployment, migrating or adding functionality to enhance the VPN is often avoided. FlexVPN was created to simplify the deployment of VPNs, to address the complexity of multiple solutions, and as a unified ecosystem to cover all types of VPN: remote access, teleworker, site to site, mobility, managed security services, and others. Cisco IOS FlexVPN Features and Benefits: Cisco IOS FlexVPN is a unified VPN solution and provides the following benefits: ●     Scalability:  IKEv2 provides scalability feature with the help of IKEv2 Proposal, in which we can use multiple integrity, encryption & DH...
Post a Comment
Read more

VRF Aware IPSEC Site-to-Site VPN

VRF [Virtual Routing & Forwarding] Virtual Private Networks (VPNs) provide a secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table. A VPN routing table is called a  VPN routing/forwarding (VRF) table. About VRF-lite VRF-lite is a feature that enables a service provider to support two or more VPNs, where IP addresses can be overlapped among the VPNs. VRF-lite uses input interfaces to distinguish routes for different VPNs and forms virtual packet-forwarding tables by associating one or more Layer 3 interfaces with each VRF. Interfaces in a VRF can be either physical, such as Ethernet ports, or logical, such as VLAN SVIs, but a Layer 3 interface cannot belong to more than one VRF at any time. Terminology ·  ...
1 comment
Read more

Introduction to Segment Routing

Segment Routing Introduction Before we proceed to understand the segment routing technology, we must understand that SR is a technology and every technology has made for a solution. So, first, we need to understand the solution and its need. All the Service providers are facing following issues with current infrastructure: 1.     A lot of manual configuration for reserving the path in the SP Core network for a different type of traffics. 2.     Lack of application-level visibility which leads to classifying network based on only IP, Port and QoS classification. 3.     Lack of application integration with the network. 4.     No centralized control over the path based on different type of services. 5.     No end-to-end visibility from Data Center to an End user, which leads to sub-optimal paths for application in different domains. 6.     The separate signaling protocol is r...
2 comments
Read more