GET VPN, it is all about group.

September 23, 2014 2 Comments

GET VPN uses a group security paradigm comparing to the traditional point-to-point security paradigm like DMVPN, GRE IPSec or SSL. Do not confuse with any-to-any mesh which is the result of n(n-1)/2 point-to-point security associations between n peers.

We are talking about group security association (SA), group states and group keys.

Because each group member doesn’t know in advance about other group members, a central entity named key server (KS) need to manage GET VPN control plane: group member registration, distribute group keys and do the rekeys (updating security policy and group keys).

Once a group member has registered with the KS to a group, it can take care of the data plane encrypted communication with any of the other group members using the received group key and group security policy.

GET VPN doesn’t create the VPN perimeter (like Frame Relay for example), all group members and the key server are supposed to be already in the same VPN.

This lab is not supposed to be a comprehensive GET-VPN reference. Because it is all about a stories and process dynamics, I opted for a more visual approach: less words, more pictures.

I included a table summarizing the key characteristics of GET-VPN comparing with traditional IPSec, followed by a step-by-step animation of the main processes of GET-VPN.

Only then, I provide some configurations of the core MPLS-VPN and GET-VPN key server and group member.

And finally the offline lab with a myriad of useful commands collected during a running session.

By rushing to the CLI, you can easily drown yourself in a cup of water 🙂 Better take the time to understand the overall process, then configuration and troubleshooting will be straightforward and more instructive.

Outline:

Comparison of GETVPN vs traditional IPSec.
Summary of the main concepts
Step-by-step GETVPN process
Lab details
- MPLS-VPN configuration
  - Core
  - PE_CE
- GET VPN configuration
  - Basic Group member template
  - Basic key server
Offline lab
Troubleshooting

Comparison table (IPSec 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).

Figure3- Traditional IPSec PTP SAs between GMs

Figure4- Traditional IPSec PTP Packet

Figure5a-Traditional IPSec routing overlay

Figure6- Get-VPN IPSec PTP Packet + TEK

Figure6a- GETVPN end-to-end routing

Summary of the main concepts

The key server manages the control operations (group member registration and rekey and policy distribution) on a different plane, initially, under the protection of IKE, after that, protected by a common key (KEK) (figure7/8).

Rekey process can be done using unicast (default) or multicast.

Any-to-any GM communications are performed on a separate data plane using the received TEK (Traffic Encryption Key) (figure9).

COOP (Co-operative key server protocol)

A Key Server redundancy feature allowing key server communication to synchronize the keying information.

GDOI protocol (Group Domain of Interpretation)

Used for policy & key deployment with group members.

Make sure to differentiate between registration vs rekey and between authentication vs authorization processes.

A-Registration process:

1- There is two types of KS-GM authentications):

Shared key (deployed on the lab): a simple secret key shared (hopefully out-of-band) by the KS and all GMs (or per-pair).
RSA (CA-based authentication): uses asymmetric encryption with public/private key pair and requires PKI infrastructure:
- Enrollment phase:
  - Client (GM) gets CA certificate (CA public key signed with CA private key)
  - Client enrollment with CA
    - Client sends its own certificate (client public key signed with client private key)
    - CA signs the client certificate with its own (CA) public key and sends it to the client.
- Peer-to-peer (GM-to-KS) authentication:
  - Peers exchanges and verify each other signatures using CA public key.

2- Authorization (during registration):

KS verifies the group id number of the GM: If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.

B-Rekey process (after registration): uses asymmetric encryption with public/private key pair:

The Primary KS uses the private & public keys (asymmetric) generated before the registration and export them to other secondary KSs.
Primary KS generates Group control / data plane keys, TEK and KEK (symmetric keys)
The KS signs TEK/KEK + policy with its own private key and sends them to GMs(figure7/8/9)
The KS distributes public key to all GMs.
GMs check the rekeys with the received KS public key

Figure7- Control plane: GM registration

Figure8- Control plane: rekey using KEK key

Figure9- GM data plane communications using TEK key

Step-by-step GET-VPN process

Click the picture below to browse the swf animation explaining GET-VPN interactions:

Lab details

Here is the lab topology, pretty straight forward, three group members and one key server with MPLS-VPN as the underlying VPN infrastructure.

Figure1- High-level lab topology

Figure2- Low-level lab topology

GET VPN:

Customer equipments (CE) R9, R10 and R12 play the role of GETVPN group members (GM),
R11 plays the role of the key server.

MPLS_VPN:

R2, R3 and R5 are the MPLS-VPN PEs (Provider Edge equipment)

MPLS-VPN configuration:

Make sure the underlying MPLS-VPN topology works fine and all connectivity are successful before touching GET VPN.

For the sake of simplicity, a single MPLS core router (label switching router) R4 is used and static routing between CE_PE.

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

MPLS-VPN basic configuration with PE-CE static routing

R4 the MPLS core router (LSR) is configured as BGP route reflector.
Make sure PE equipments (wan interfaces and loopback rid’s) are reachable though MPLS core OSPF.
Enable MPLS on the interfaces facing PE’s.
Each PE (R2, R3 and R5) has similar configuration and a template can be used to scale client numbers.

Because this lab is not focused on MPLS-VPN, a simple PE-CE static routing is deployed. Each client has its interface and static route in the appropriate VRF. Generally multiple clients (VRFs) separately coexist in a single PE and the core transport is done through vpnv4 to and from other PE’s (figure2a)

Figure2a- MPLS-VPN PE Virtual Router Forwarding

With PE-CE static routing, only one-side redistribution is done, from static to vpnv4 address family.

You will find all details in the offline lab.

R4 (MPLS LSR router)

interface Loopback0ip address 10.0.0.4 255.255.255.255ip ospf 2345 area 0!

interface FastEthernet0/0

ip address 192.168.45.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

interface FastEthernet0/1

ip address 192.168.24.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

interface FastEthernet1/0

ip address 192.168.34.4 255.255.255.0

ip ospf 2345 area 0

mpls label protocol ldp

mpls ip

router ospf 2345

router bgp 2345

no synchronization

bgp router-id 4.4.4.4

network 192.168.24.0

network 192.168.34.0

network 192.168.45.0

neighbor 10.0.0.2 remote-as 2345

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 remote-as 2345

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 remote-as 2345

neighbor 10.0.0.5 route-reflector-client

no auto-summary

address-family vpnv4

neighbor 10.0.0.2 activate

neighbor 10.0.0.2 send-community extended

neighbor 10.0.0.2 route-reflector-client

neighbor 10.0.0.3 activate

neighbor 10.0.0.3 send-community extended

neighbor 10.0.0.3 route-reflector-client

neighbor 10.0.0.5 activate

neighbor 10.0.0.5 send-community extended

neighbor 10.0.0.5 route-reflector-client

exit-address-family

R4#sh ip bgp summBGP router identifier 4.4.4.4, local AS number 2345…10.0.0.2 4 2345 134 137 4 0 0 02:09:53 0

10.0.0.3 4 2345 134 137 4 0 0 02:09:43 0

10.0.0.5 4 2345 136 137 4 0 0 02:09:52 0

R4#

GET-VPN configuration:

Key server:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2!crypto isakmp key cisco address 192.168.103.10

crypto isakmp key cisco address 192.168.29.9

crypto isakmp key cisco address 192.168.125.12

crypto ipsec transform-set transform128 esp-aes esp-sha-hmac

crypto ipsec profile profile1

set security-association lifetime seconds 7200

set transform-set transform128

crypto gdoi group gdoi-group1

identity number 91011

server local

rekey algorithm aes 128

rekey retransmit 10 number 2

rekey authentication mypubkey rsa rekey-rsa

rekey transport unicast

sa ipsec 1

profile profile1

match address ipv4 getvpn-acl

address ipv4 192.168.115.11

interface FastEthernet0/0

ip address 192.168.115.11 255.255.255.0

ip access-list extended getvpn-acl

deny icmp any any

deny udp any eq 848 any eq 848

deny tcp any any eq 22

deny tcp any eq 22 any

deny tcp any any eq tacacs

deny tcp any eq tacacs any

deny tcp any any eq bgp

deny tcp any eq bgp any

deny ospf any any

deny eigrp any any

deny udp any any eq ntp

deny udp any eq ntp any

deny udp any any eq snmp

deny udp any eq snmp any

deny udp any any eq snmptrap

deny udp any eq snmptrap any

deny udp any any eq syslog

deny udp any eq syslog any

permit ip any any

You can recognize usual IPSec components: crypto policy, shared keys, transform-sets wrapped in an ipsec profile, followed by GETVPN GDOI group policy ( ipsec profile and group policy (group-id, symm. encr. Algorithm, asymmetric keys to use during rekey authentication and getvpn acl)

The GETVPN ACL defines what will not be encrypted; consider your own topology needs:

Exclude already encrypted traffic (https, ssh, etc.)
Exclude PE-CE routing protocols.
Exclude GETVPN control plane protocols( gdoi udp 848, tacacs, radius, etc.)
Exclude Management/monitoring protocols (snmp. syslog, device remote access, icmp, etc.)

Group member template:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2crypto isakmp key cisco address 192.168.115.11!

crypto gdoi group gdoi-group1

identity number 91011

server address ipv4 192.168.115.11

crypto map map-group1 10 gdoi

set group gdoi-group1

interface FastEthernet0/0

crypto map map-group1

All control plane parameters are controlled by the KS, GMs are dumb devices. All they have to know is how to initiate IKE phase1 for preshared or RSA authentication with the KSs to register and get the keys, which groups they want to join, to which KS they will talk (if many configured) and finally, the get crypto-map assigned to the outbound interface.

Troubleshooting:

When practicing or during tenacious data plane issues, a good idea is to use ESP-NULL, the null encryption, where the encryption process is engaged, but packets are not encrypted.

This will make much easier the packet content inspection and marking between GMs.

To facilitate the deployment and the troubleshooting, think about the topology in terms of separate technology sub-domains; make sure everything works fine before moving to the next sub-domain.

Layer2 MPLS
MPLS-VPN
Core routing
PE-CE routing
Core SSM multicast (if not unicast rekey)
CA infrastructure (if you are not using shared keys to authenticate GMs to the KS)

Possible issues	Possible causes
key servers doesn’t exchange all announcements	Bad buffer – default buffer is not enough for large nbr of gm
Reassembly timed out	Some announcement fragments are dropped or lostICMP (packet too big) denied in the pathNo fragmentation because df bit setPresence of MTU bottlenecks, multipaths, firewalls.Not tuned tcp mss “ip tcp adjust-mss”
ike failure- failed negotiation	Preshared key mismatchIKE parameters mismatchTransport issues between GMs and KSs
Nothing works just after GM registration.	GETVPN acl policy cause routing traffic encryption: traffic not symmetrically excluded
KS not synchronizing	Check KS-KS transport: avoid making KS-KS communications dependent on GET-VPN successful transport.Keys not exported or not imported
Rekey not delivered	Issue with multicast infrastructure.Issue with mVPN service.