Brksec 3011

Advanced IPsec with GET VPN
BRKSEC-3011
Follow us on Twitter for real time updates of the event:

@ciscoliveeurope, #CLEUR
Housekeeping
We value your feedback- don't forget to complete your online session

evaluations after each session & the Overall Conference Evaluation
which will be available online from Thursday
Visit the World of Solutions and Meet the Engineer
Visit the Cisco Store to purchase your recommended readings
Please switch off your mobile phones
After the event dont forget to visit Cisco Live Virtual:
www.ciscolivevirtual.com
Follow us on Twitter for real time updates of the event:
@ciscoliveeurope, #CLEUR
BRKSEC-3011 2012 Cisco and/or its affiliates. All rights reserved. Cisco Public 2
Agenda
GET VPN Fundamentals GET VPN Control Plane (cont.)

Basic Configuration - Cooperative Key Servers
- Network Splits & Merges
GET VPN Data Plane
- IKE Authentication
- IPsec Group Policies & GDOI Authorization
- Fail-Open & Fail-Close
Advanced Topics
- Receive-Only & Passive Mode
- Multiple Groups
- Time-Based Anti Replay
- Virtualization (VRF)
GET VPN Control Plane - NAT & NAT Traversal
- GM Registration - Load Balancing
- Unicast & Multicast Rekeys - Fragmentation
- Policy Changes - IPv6 Support
- Triggered Rekeys - Management
- GM Removal
Scalability & Positioning
GET VPN Fundamentals
Key Servers & Group Members
Key Server (KS): a device that distributes Policy

keys & policies to group members
KS
Group Member (GM): a device that registers GM
with a group controlled by the KS to
communicate securely with other GM's
The protocol between GM and KS is GDOI
GM
- IKE-based (DOI defined in RFC 3547) GM
- no GDOI between GM's GM
Traffic Encryption Key (TEK): protects

traffic between GM's (IPsec SA)
Key Encryption Key (KEK): protects rekeys IPsec SA Rekey SA
between KS and GM's (GDOI SA)
IPsec Rekey
TEK policy KEK policy
Tunnel Header Preservation
IP header IP payload
Original IP packet
IP header ESP header IP header IP payload ESP

Encrypted IP packet
IP header preservation (tunnel mode)
ESP transport mode:

- not meant for traffic forwarding by security gateways
- fragmentation/reassembly limitations
GET VPN uses ESP tunnel mode with header preservation:

- all fields copied from inner IP header (source, destination, DSCP, ID, )
- enables native multicast replication
- IPsec transform-set must be configured in tunnel mode
Secure Data Plane Unicast
GM's do not know their potential Policy KS

encryption peers
Each GM knows that other
legitimate GM's receive Traffic GM
Encryption Key (TEK) and IPsec
policy from KS
Outbound traffic is encrypted
with current TEK if matching the
crypto policy received from KS
GM
GM
Inbound IPsec traffic is accepted
if matching the crypto policy and
encrypted with a valid TEK
GM
Secure Data Plane Multicast
GM's encrypt multicast traffic Policy KS

with IP address preservation,
same as for unicast
Enables native replication in the GM
core based on the original (S,G)
GM
GM
GM
Policies & Rekeys
KEK policy (GDOI SA) OLD NEW

- cryptographic parameters
KS
- KEK SPI & remaining lifetime
GM
- rekey transport type (unicast / multicast)
TEK policy (IPsec SA)

- cryptographic transform set GM
GM
- TEK SPI & remaining lifetime
- traffic selectors (IPsec group policy) GM
KS sends regular rekeys to registered GM's

- unicast or multicast (configured on KS)
- encrypted with active KEK
- containing KEK and/or TEK(s)
- each KEK/TEK bundled with a policy
Basic Configuration
Key Server Configuration
crypto gdoi group wan-getvpn

identity number 1
server local
rekey address ipv4 100
rekey retransmit 40 number 3
rekey authentication mypubkey rsa getvpn-rekey
sa ipsec 1
profile getvpn-profile Multicast source
match address ipv4 getvpn-encrypt address for rekeys
replay time window-size 5
address ipv4 192.168.10.10 Global policy for
! traffic encryption
access-list 100 permit ip any host 239.192.l.1
!
ip access-list extended getvpn-encrypt
deny udp any eq 848 any eq 848
permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
permit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255
Global encryption policy configured on KS, pushed to GM's

Rekey can be unicast instead of multicast crypto gdoi group wan-getvpn
identity number 1
server local
rekey transport unicast
Group Member Configuration
interface Ethernet0/0
ip address 192.168.1.14 255.255.255.252
crypto map cmap
Crypto selector for
!
outbound traffic
crypto map cmap 10 gdoi
set group getvpn-wan Local policy for
match address getvpn-exclude traffic encryption
!
ip access-list extended getvpn-exclude
deny ip host 192.168.1.14 host 192.168.1.13
!
crypto gdoi group getvpn-wan
identity number 1
Group definition
server address ipv4 192.168.10.10
Outbound traffic selected for encryption by crypto map applied on interface

Local encryption policy on GM complements global policy pushed by KS
IPsec Group Policies
IPsec Group Policy
Crypto group policy must be read as an egress traffic selector

- permits traffic to be encrypted
- denies traffic to be sent out in the clear
Just like a regular crypto map, but non-directional proxies

Example network:
- Traffic to/from 10.x.0.0/16 and 172.16.x.0/24 must be encrypted
- Traffic to/from 192.168.0.x/32 must remain unencrypted
IPsec VPN
10.1.0.0/16 10.2.0.0/16
IP VPN
172.16.1.0/24 172.16.2.0/24
GM 1 GM 2
192.168.0.1/32 192.168.0.2/32
Central IPsec Group Policy
Pushed by KS to all GM's
Required policy on GM1: Combine Required policy on GM2:
permit 10.1.0.0/16 10.2.0.0/16 permit 10.2.0.0/16 10.1.0.0/16
permit 172.16.1.0/24 172.16.2.0/24 permit 172.16.2.0/24 172.16.1.0/24
deny any any deny any any
Resulting global policy on KS:
permit 10.1.0.0/16 10.2.0.0/16
permit 10.2.0.0/16 10.1.0.0/16
permit 172.16.1.0/24 172.16.2.0/24
permit 172.16.2.0/24 172.16.1.0/24
deny any any (implicit)
Resulting policy on GM1: Resulting policy on GM2:
permit 10.1.0.0/16 10.2.0.0/16 permit 10.1.0.0/16 10.2.0.0/16
permit 10.2.0.0/16 10.1.0.0/16 Push Push permit 10.2.0.0/16 10.1.0.0/16
permit 172.16.1.0/24 172.16.2.0/24 permit 172.16.1.0/24 172.16.2.0/24
permit 172.16.2.0/24 172.16.1.0/24
KS permit 172.16.2.0/24 172.16.1.0/24
IPsec VPN
10.1.0.0/16 10.2.0.0/16
IP VPN
172.16.1.0/24 172.16.2.0/24
GM 1 GM 2
192.168.0.1/32 192.168.0.2/32
Central IPsec Group Policy (2)
Simplify using network summarization
Required policy on GM1: Summarize Required policy on GM2:
permit 10.1.0.0/16 10.2.0.0/16 permit 10.2.0.0/16 10.1.0.0/16
permit 172.16.1.0/24 172.16.2.0/24 permit 172.16.2.0/24 172.16.1.0/24
Simplified global policy on KS:
permit 10.0.0.0/8 10.0.0.0/8
permit 172.16.0.0/16 172.16.0.0/16
deny any any (implicit)
Resulting policy on GM1: Push Push Resulting policy on GM2:

permit 10.0.0.0/8 10.0.0.0/8 permit 10.0.0.0/8 10.0.0.0/8
permit 172.16.0.0/16 172.16.0.0/16 permit 172.16.0.0/16 172.16.0.0/16
KS
OK, superset of
required policy
IPsec VPN
10.1.0.0/16 10.2.0.0/16
IP VPN
172.16.1.0/24 172.16.2.0/24
GM 1 GM 2
192.168.0.1/32 192.168.0.2/32
Simplest form using "any-any" ber-summary
Global policy on KS:

permit any any
Push Push
permit any any permit any any
Can be tuned on each GM KS

using local security policy
IPsec VPN
10.1.0.0/16 10.2.0.0/16
IP VPN
172.16.1.0/24 172.16.2.0/24
GM 1 GM 2
192.168.0.1/32 192.168.0.2/32
Local IPsec Policy
Configured on GM
KS
Global IPsec policy on KS, in order: Global policy on KS:

deny tcp any any eq ssh
- Global deny statement(s) (don't encrypt) deny pim any host 224.0.0.13
...
- Global permit statement(s) (encrypt) permit ip any any
- Implicit deny any-any (don't encrypt)
Global Policy
Registration
Local IPsec policy on GM: Concatenated policy on GM:
- Local deny statement(s) (don't encrypt) deny ip host 192.168.0.1 any
deny tcp any any eq ssh
- NO permit statements allowed deny pim any host 224.0.0.13
...
permit ip any any
Resulting policy on GM, in order:
- Local deny
- Global deny
Local policy on GM:
- Global permit deny ip host 192.168.0.1 any
GM
- Implicit deny
ASR1k requires mirrored ACL before 15.1(3)S Local policy on ASR1k pre-15.1(3)S:
deny ip host 192.168.0.1 any
deny ip any host 192.168.0.1
Combining "any-any" with local policy
Global policy on KS:

permit any any
Push Push
deny 192.168.0.1/32 any deny 192.168.0.2/32 any
permit any any permit any any
Override Override
Local policy on GM1: KS Local policy on GM2:
deny 192.168.0.1/32 any deny 192.168.0.2/32 any
IPsec VPN
10.1.0.0/16 10.2.0.0/16
IP VPN
172.16.1.0/24 172.16.2.0/24
GM 1 GM 2
192.168.0.1/32 192.168.0.2/32
Recommendations for IPsec Policies
Maximum 100 ACL entries per group

Minimize global policy size
- summarize networks
- use symmetrical permit policies (cuts ACL in )
- use permit ip any any as much as possible
The use of local policies is strongly recommended

- for management and control plane exceptions
- when fail-close is used
- to avoid fragmentation of rekey packets
Common policy exceptions
deny udp <local> eq isakmp any eq isakmp

IKE & GDOI (prevent recursive encryption)
deny udp <local> eq 848 any eq 848
deny esp <local> any IPsec/ESP (prevent recursive encryption)
deny tcp <local> any eq {tacacs,ssh,bgp}

TCP-based control plane protocols
deny tcp <local> eq {tacacs,ssh,bgp} any
deny udp <local> any eq {ntp,dns,syslog,

snmptrap,1645,1646,1812,1813} UDP-based control plane protocols
deny udp <local> eq snmp any
deny ip <local> 224.0.0.0 0.0.0.255 Link-layer control protocols
deny ip <local> host 224.0.1.39

Auto-RP & RP-Discovery
deny ip <local> host 224.0.1.40
Fail-Open & Fail-Close
Unknown
- rebooted
Fail-Open & Fail-Close - misconfigured
- cleared GDOI
Initialization
Fail-Close
GM that has not yet registered with - registering
Fail-Open
- registering
a KS can take 2 possible actions - dropping traffic based
- not encrypting traffic
on fail-close policy
- Fail-open (default): allow all egress
traffic to go in the clear until Registration
registered
- Fail-close: drop some or all egress Rekey Registered
traffic until registered - receiving rekeys
- encrypting traffic
based on IPsec policy Registration
Once initialized, GM remains in fail- TEK Expiring
open or fail-close until registered
Re-Registering
with a KS - registering
- receiving rekeys
GM that cannot re-register upon - encrypting traffic
based on IPsec policy
TEK expiration:
- does not go back to fail-open or TEK Expired
TEK Expired
fail-close - registering
- dropping traffic
- drops egress traffic matching most based on most recent
recent IPsec policy IPsec policy
Fail-Close Configuration
ACL syntax: permit to drop traffic, deny to let through in the clear
Bootstrap ACL required to allow control plane traffic (incl. GDOI)
Implicit permit ip any any at end of fail-close ACL (drop all traffic)
Default (no match address): permit ip any any
ip address 192.168.1.14 255.255.255.252
crypto map cmap
!
crypto map cmap gdoi fail-close
match address getvpn-exclude Need "activate" keyword
activate to enable fail-close policy
set group getvpn-wan
match address getvpn-exclude
! Fail-close ACL can be
ip access-list extended getvpn-exclude shared with local policy
deny udp any any eq 848
deny ospf any any
GDOI traffic must be
...
explicitly excluded
deny ip host 192.168.1.14 host 192.168.1.13
Fail-Close Logic
Fail-close policy applied at end of crypto map

Removed once all groups have registered
site-site-vpn: permit ...
getvpn-2-exclude: deny ...
fail-close-exclude:
crypto map cmap gdoi fail-close
deny ...
match address fail-close-exclude permit ip any any
activate
crypto map cmap 5 ipsec-isakmp
...
match address site-site-vpn getvpn-1 site-site-vpn: permit ...
crypto map cmap 10 gdoi registration getvpn-1-global: permit ...
set group getvpn-1 getvpn-2-exclude: deny ...
crypto map cmap 20 gdoi fail-close-exclude:
set group getvpn-2 deny ...
match address getvpn-2-exclude permit ip any any
getvpn-2
registration site-site-vpn: permit ...
getvpn-1-global: permit ...
getvpn-2-exclude: deny ...
getvpn-2-global: permit ...
Receive-Only & Passive Mode
Receive-Only & Passive Mode (1)
Receive-only Mode Passive Mode

- Configured globally on KS for group - Configured locally on GM
- GM's never encrypt egress traffic - GM's always encrypt egress traffic
GM's accept cleartext and encrypted packets matching the IPsec policy
crypto gdoi group wan-getvpn crypto gdoi group getvpn-wan

identity number 1 identity number 1 on GM
server local passive
on KS
sa receive-only server address ipv4 192.168.10.10
GM GM
LAN WAN cleartext LAN WAN
encrypted
SND SND
SA SA
Crypto Crypto
Engine Engine
RCV RCV
SA SA
Receive-Only & Passive Mode (2)
Useful during initial GET VPN deployment

- configure Receive-Only mode on KS'es
- gradually configure GET VPN on all GM's
- no actual encryption performed by GM's
- check the control plane, ensure GDOI stability
- gradually configure Passive Mode on GM's
- verify encryption/fragmentation/... one GM at a time
Once all GM's are configured in Passive Mode

- ensure the GET VPN is stable, rekeys are working, no re-registrations
- disable Receive-Only mode on KS'es
- remove Passive Mode from all GM's
Time-Based Anti Replay
Time-Based Anti Replay (TBAR)
GET VPN does not have a notion of remote peer

Replay vector only works with notion of remote peer
GET VPN replaces replay vector with Time-Based Anti Replay (aka TBAR)
Inside the KS policy:
- pseudo-time: relative time driven by the KS (a bit like NTP)
- window size: time interval around the pseudo-time where packet is allowed
GM's:
- synchronize pseudo time with KS periodically
(at each rekey or every 2 hours, whichever is shorter)
- tag each packet sent with a pseudo-timestamp
- check in received packets whether pseudo-timestamp falls within window
Data Plane Encapsulation (1)
TBAR Disabled
Host A GM A Router Router GM B Host B

10.1.1.1 10.1.1.9 10.2.2.9 10.2.2.2
s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2

IP Payload ESP Header (SPI) IP Payload
s=10.1.1.1 d=10.2.2.2
IP Payload
Encrypted ESP Trailer
Data Plane Encapsulation (2)
TBAR Enabled
KS
Reference Pseudo-Time Reference Pseudo-Time
Host A GM A Router Router GM B Host B

10.1.1.1 10.1.1.9 10.2.2.9 10.2.2.2
s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2

IP Payload ESP Header (SPI) IP Payload
Cisco Meta-Data
s=10.1.1.1 d=10.2.2.2
Pseudo-Timestamp Pseudo-Timestamp
IP Payload
Encrypted ESP Trailer
GM A Pseudo-Time GM B Pseudo-Time
Reject Reject
Accept Accept
window window
For Your
Data Plane Packet Structure Reference
Preservation of Original IP Addresses and DSCP

Encapsulating Security Payload (ESP) with irrelevant Sequence Number
OPTIONAL: Time-based Anti-Replay
- IPsec Next Header identified as IANA Private Encryption (protocol = 99)
- Cisco Meta Data (99) carries Pseudo-Timestamp for receiver verification
Encrypted IP Packet follows 1 byte 1 byte 1 byte 1 byte
IP Header (proto = ESP, src/dst/DSCP copied from inner header)

Pseudo-Timestamp overhead ESP SPI
- 12 bytes (non-Nitrox based) ESP Seq# (ignored by receiver)
NxtHdr = IP Length = 0x2 Version = 0x1 Reserved
- 16 bytes (Nitrox-based) 0x1 Type = 0x5 (TBAR) Reserved
(ASR1k, VSA, some ISRs) Pseudo-Timestamp
Original IP Header
IP Payload
IP Payload Padding Pad Length NxtHdr = 99
IP
ESP Authentication
GET VPN Control Plane
GDOI Protocol
GDOI means Group Domain of Interpretation

RFC 3547, IETF MSEC WG
IKE Phase 1 (UDP port 848) provides:
- GM authentication
- confidentiality
- integrity
GDOI Registration provides:

- GM authorization
- replay protection
Traffic Encryption Key (TEK): protects traffic between GM's

Key Encryption Key (KEK): protects rekeys between KS and GM's
GDOI Exchanges
RFC 3547 defines two new IKE Phase 2 exchanges

GROUPKEY-PULL (aka Registration):
- initiated by GM
- unicast between GM and KS
- GM sends group ID to KS
- KS supplies policy to GM
- GM acknowledges policy
- KS supplies KEK/TEK to GM
GROUPKEY-PUSH (aka Rekey):

- initiated by KS
- can be unicast or multicast
- KS supplies new policy and/or KEK/TEK
- GM acknowledges rekey (unicast only)
KS RSA Keypair
Shared by all KS'es for the group

Must be synchronized manually
- generate as exportable if multiple KS'es
- a certificate is not needed for this key
Public key sent to GM during registration (GROUPKEY-PULL)

All rekeys (GROUPKEY-PUSH) are signed by the private key
Scheme guarantees rekey authentication
GDOI Registration & Rekey
GM KS
t = 0s IKE SA IKE Phase 1 GDOI SA IPsec SA IKE SA
IKE authentication
exp.300s exp.300s
Group ID KEK 1 TEK 1
exp.8000s exp.3000s
GDOI authorization
Policies
KS RSA keypair
GDOI SA IPsec SA (priv, PUB)
ACK
KEK 1, TEK 1, PUB, seq#0 GROUPKEY-PULL

KS PUB KEK 1 TEK 1
exp.8000s exp.3000s Protected by: IKE SA
(IKE SA has expired)

t = 2200s
GDOI SA IPsec SA
TEK 2, SA Pol., seq#1, SIG
GDOI SA IPsec SA
ACK (if unicast)
KEK 1 TEK 1 TEK 2
exp.5800s exp.800s exp.7200s
KS PUB KEK 1 TEK 1 TEK 2
exp.5800s exp.800s exp.7200s KS RSA keypair
(priv, PUB)
t = 3000s GDOI SA IPsec SA GROUPKEY-PUSH

Protected by: GDOI SA (KEK)
TEK 1 has expired Signed with: KS RSA private key
KS PUB KEK 1 TEK 2 TEK 2 is now in use
exp.5000s exp.6400s
IPsec & GDOI SA's interface: Ethernet0/0
Crypto map tag: cmap, local addr 10.0.0.10
local ident: (172.16.0.0/255.255.0.0/0/0)

remote ident: (172.16.0.0/255.255.0.0/0/0)
One TEK = one ESP SPI current outbound spi: 0xE52B0808(3844802568)

inbound esp sas:
spi: 0xE52B0808(3844802568)
- same SPI inbound and outbound outbound esp sas:
spi: 0xE52B0808(3844802568)
- same SPI for all proxies
local ident: (192.168.0.0/255.255.0.0/0/0)
- multiple SPI's can coexist after rekey remote ident: (192.168.0.0/255.255.0.0/0/0)
(old/new) or after network merge current outbound spi: 0xE52B0808(3844802568)
inbound esp sas:
- volume-based lifetime disabled spi: 0xE52B0808(3844802568)
outbound esp sas:
One KEK = one GDOI SA spi: 0xE52B0808(3844802568)
- shows up as an ISAKMP SA spi: 0xE52B0808(3844802568)

transform: esp-aes esp-sha-hmac ,
- state begins with "GDOI" in use settings ={Tunnel, }
conn id: 87, flow_id: SW:87, sibling_flags 80000040
- multiple KEK's can coexist sa timing: remaining key lifetime (sec): (165)
Kilobyte Volume Rekey has been disabled
after rekey (old/new) or after IV size: 16 bytes
network merge replay detection support: Y replay window size: 2
Status: ACTIVE
IPv4 Crypto ISAKMP SA

dst src state conn-id status
10.0.0.10 10.0.0.1 GDOI_REKEY 1059 ACTIVE
For Your
Control Plane Replay Protection Reference
Control plane replay protection added in:

12.4(15)T10, 12.4(22)T3, 12.4(24)T2, 15.0(1)M, and ASR1k 2.5.0 (12.2(33)XNE)
GM checks seq# and pseudo-time when processing rekeys

Not backward-compatible with older KS:
- if any GM runs a release with control plane replay protection, then
- all KS'es must be upgraded to support it, but
- other GM's can remain on older releases
New GM / old KS incompatibility will cause failed rekeys

%GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 2
in seq payload for group get-group, last seq # 6
%GDOI-3-PSEUDO_TIME_TOO_OLD: Rekey received in group get-group
is too old and failed PST check: my_pst is 184 sec, peer_pst
is 25 sec, allowable_skew is 10 sec
GM Registration
For Your
GM Registration Timings Reference
Initial & Re-Registration
IKE retransmissions for GDOI:

- 3 times per configured KS, with 10s interval
- vs. 5 times for non-GDOI IKE
GM cycles through list of KS'es until success
- all KS'es tried in turn without delay (except retransmissions)
- interval between cycles: 70s, 140s, 280s, 480s (backoff mechanism)
- starts counting since first IKE attempt on last KS in the list
- these timers are not configurable
Recovery after GM transport network failure can take a long time
- all KS'es unreachable during one or more tries
- backoff interval kicks in between cycles
- maximum recovery time:
480s (longest interval) - 40s (tries on last KS) = 440s
For Your
GM Re-Registration Timings Reference
KS finishes TEK rekey at 90% of TEK lifetime

GM's that did not get the rekey will re-register before TEK expires
Original timing:
- 60s before TEK expiry
- +/- 6s jitter added to re-register timer
Enhanced timing:
- starting from 12.4(15)T9, 12.4(22)T2 and 12.4(24)T
- re-register max(60s, 5% TEK lifetime) before expiry
- add jitter +/- max(6s, 2% TEK lifetime)
- improved scalability (#GM's per KS)
jitter (2%)
TEK lifetime (%)

90% 95% 100%
Unicast & Multicast Rekeys
Unicast Rekey Model
Send to batches of 50 GM's at a time (allow for up to 5s per batch)

Retransmit to GM's that did not ACK the rekey
- only if retransmission is configured
- only once all GM batches have been processed
GM's that did not get the rekey will re-register before TEK expiry (*)
- compute head start to finish rekey long enough before re-registration:
max(10% TEK lifetime, 90s) + (#retrans * interval) + (5 * #GMs / 50)
10% TEK lifetime
~5s ~5s ~5s ~5s 10s 10s ( 30s) ( 30s) 30s
(*) timing depends on GM version

Unicast Rekey Example
10% TEK lifetime
~5s ~5s ~5s ~5s 10s 10s ( 30s) ( 30s) 30s

KS
GM87
KEK, TEK
REGISTER
GM112
GM137
GM194
For Your
Unicast Rekey Scalability Reference
TEK lifetime must be much larger than the time needed to rekey
- recommended TEK lifetime: 2 hours (7200s)
KEK lifetime should be much larger than TEK lifetime
- recommended KEK lifetime: between 3 * TEK lifetime and 24 hours
Pseudo-time sync rekey happens after 120min (not configurable)
Use unicast rekey if not more than a few hundreds of GM's, or if
multicast routing is not available
Unicast rekey bursts can overrun slow links if too many GM's
- no actual delay between batches of 50 GM's (5s is only for timing calc.)
- distribute GM's amongst multiple COOP Key Servers
- reduce size of global policy (#lines in the crypto ACL)
Multicast Rekey Model
Send to all GM's at the same time

- configurable multicast destination address
- all GM's must join the rekey multicast group
Multicast rekeys are always retransmitted if configured

GM's that did not get the rekey will re-register before TEK expiry (*)
- compute head start to finish rekey long enough before re-registration:
max(10% TEK lifetime, 90s) + (#retrans * interval)
10% TEK lifetime
10s 10s ( 30s) ( 30s) 30s
(*) depends on GM version

Multicast Rekey Example
10% TEK lifetime
10s 10s ( 30s) ( 30s) 30s

KS
TEK
GM54
KEK, TEK
REGISTER
GM108
GM149
GM186
Policy Changes, Triggered Rekeys & GM Removal
For Your
KEK/TEK Policy Changes Reference
Before 15.2(1)T
Some KEK/TEK policy changes trigger an immediate rekey

- rekey takes place after user exits configuration mode
- some changes do not take immediate effect on GM's after the rekey
- TEK policy changes require creation of a new IPsec SA
- old IPsec SAs remain on GM (in use or not) until they expire
Policy change Triggers rekey ? Effect

KEK: SA lifetime No Next rekey
KEK: authentication key or crypto algorithm Yes Immediate
TEK: SA lifetime No TEK expiry
TEK: IPsec profile or transform-set Yes TEK expiry
TEK: traffic selector ACL Yes Immediate
TEK: enable / disable TBAR or replay count Yes TEK expiry
TEK: change TBAR or replay count window No Next rekey
TEK: enable / disable receive-only Yes Immediate
Triggered Rekeys
Since 15.2(1)T
No automatic rekey upon KEK/TEK policy changes since 15.2(1)T

Syslog printed when user exits configuration mode
%GDOI-5-POLICY_CHANGE: GDOI group GET policy has changed.
Use 'crypto gdoi ks rekey' to send a rekey, or the changes
will be sent in the next scheduled rekey
User can wait for next rekey, or trigger a rekey manually from EXEC
router# crypto gdoi ks [group <name>] rekey [replace-now]
- KEK: old SA deleted immediately, new SA takes effect immediately
- TEK: old SA lifetime shortened to 5%, new SA takes effect after expiry
- with replace-now : old SA deleted, new SA takes effect immediately
All GM's must run a compatible version for shortening the old SA
- if not, KS will send a normal rekey (or reject if replace-now)
- check GM versions from KS EXEC with:
show crypto gdoi feature policy-replace
GM Removal
Since 15.2(1)T
No way of forcibly removing a GM from the network before 15.2(1)T

User can trigger KEK & TEK expiration on all GM's from KS EXEC
router# clear crypto gdoi ks members [now]
- KEK and non-active TEK's deleted immediately
- current TEK lifetime shortened to 5%
(min: 90s, max: 1h, except if expires sooner)
- GM's schedule re-registration randomly within 2% of TEK lifetime
- with now : all KEK/TEK deleted, no traffic before GM's have registered
All KS'es & GM's must run a compatible version

- otherwise, risk of network disruption (CLI warning displayed)
- check KS & GM versions from KS EXEC with:
show crypto gdoi feature gm-removal
Cooperative Key Servers
Key Server Redundancy
Single KS = single point of failure

Multiple KS provide redundancy and load sharing
Cooperative Key Servers = a set of trusted Key Servers that manage
a common set of keys and policies for GET VPN Group Members
KS'es communicate using COOP Protocol
COOP
KS KS 1 KS 2
GM GM GM GM
GM GM GM GM
Cooperative Key Servers (1)
Introduction
KS'es establish ISAKMP SA's with each other KS 2
Exchange COOP announcement messages KS 1

(carried inside IKE Notification payloads) GM
- synchronization (policy, TEK, KEK)

- active GM's GM KS 3
- election of primary KS (role, priority)
Election of Primary KS (master Key Server)

GM
- generates KEK, TEK GM
- distributes policy and keys to other KS'es

- sends out rekeys
Multiple KS'es can share the load of GM

registrations
Election of Primary KS
Each KS initially assumes Secondary role KS 2 (10)
Sends out announcements including current role KS 1 (50)

& configured priority GM
PRIMARY
Peers respond with:

- current group database (active GM's) GM KS 3 (30)
- their own role & configured priority
Election logic: GM
GM
- if a single Primary KS exists, other KS'es remain
Secondary, regardless of their own priority
(no preemption)
- if no Primary, KS with highest priority is elected
- if multiple Primaries, KS with highest priority wins
- if priorities are equal, highest IP address wins
Role of Primary KS
Primary KS generates KEK and TEK, then KS 2

pushes to all Secondary KS'es
KS 1
Primary KS periodically sends out group GM
PRIMARY
information updates to all Secondary KS'es DB updates
Secondary KS'es send updates to Primary KS GM KS 3

whenever there is a change in their database
(active/inactive GM's)
If Secondary KS'es miss updates from Primary GM
GM
KS for a period of time, they go back to election
process and pick a new Primary KS
Re-election based on priority can be forced
through CLI (on current Primary KS only)
clear crypto gdoi ks cooperative role
Registrations & Rekeys
GM's register to any KS, Secondary or Primary

Registration load distribution among multiple KS'es (through different
ordering of KS addresses on each GM)
Rekeys are always sent by Primary KS
KS 2
KS 2
KS 1
KS 1
GM GM
PRIMARY PRIMARY
KS 3
GM GM KS 3
GM GM
GM GM
Scalability & Reliability
Recommendations:
- reliable KS identity for registration &
COOP protocol (Loopback interface)
- all GM's that did not get a rekey must be
able to re-register before TEK rollover
- diverse and reliable paths between all KS ( 30s) 30s
Re-registration
- KS-to-KS COOP through out-of-band window (*)
management network
Distribution of GM's:
Backup
- do not exceed KS capacity Primary (30) Secondary
(50) (40)
- N+1 redundancy
Example:
- KS capacity = 1500 GM's
- total nodes = 3000 GM's
- 3 KS handle all GM's (2+1) 1500 1500
(*) timing depends on GM version
For Your
COOP Protocol Timers Reference
Primary Refresh Timer:

- frequency at which announcement messages are sent by the Primary
KS to all active Secondary KS'es (default: 20s)
Secondary Periodic Timer:

- frequency at which announcement messages from the Primary KS are
expected by the Secondary KS (default: 30s)
- if no announcement received from Primary KS during this time,
Secondary KS sends accouncement query (return flag set)
Retransmit:
- number of retransmissions of announcement messages by Secondary
before marking the Primary as dead (default: 2)
- switchover time for Secondary to become Primary: 30s + (2 x 30s) = 90s
Can be tuned through CLI, but defaults are recommended values

- protocol command (under GDOI group > local server > redundancy)
- service internal needed
Network Splits & Merges
Network Split
Happens when KS'es no longer see each other (COOP-wise)

- original Primary KS remains primary in first half of the network
- Secondary KS with highest priority gets elected to Primary in other half
Key lifetime threshold for KEK/TEK

- before 12.4(22)T, promoted KS would always re-generate KEK/TEK
- since 12.4(22)T, KEK/TEK are kept if enough lifetime remains (> 150s)
- new behavior minimizes disruption due to short network splits
KS 1 (50) KS 3 (30)
PRIMARY PRIMARY
KS 2 (10) KS 4 (10)
GM GM
Network Merge
COOP connectivity comes back after a network split

- Primary KS with highest priority remains Primary
- other Primary KS demoted to Secondary
- Primary and demoted KS compare and merge policies, KEK and TEK
- rekeys must be sent out if policy, KEK or TEK changed
KS 1 (50) KS 3 (30)
PRIMARY DEMOTED
PRIMARY
REKEY
KS 2 (10) NEEDED ? KS 4 (10)
GM GM
GM Synchronization Upon Merge
If KEK/TEK did not change, no rekey needed

If KEK changed:
- demoted KS sends rekey to all GM's with KEK from Primary
If TEK changed:
- Primary KS sends rekey to all GM's with merged TEK's
If KEK and TEK changed:

- demoted KS sends rekey with KEK from Primary and merged TEK's
- Primary KS sends rekey with merged TEK's
KS 1 (50) KS 3 (30)
Multiple KEK/TEK's coexist during transient state
PRIMARY DEMOTED
- GM's use TEK with shortest lifetime until expiry
GM GM
IKE Authentication & GDOI Authorization
For Your
IKE Authentication Reference
PKI & PSK
Public Key Infrastructure (PKI): recommended

- common Root or Subordinate CA for all GM's in the network
- install CA certificate for GM's on all KS'es
- slightly higher cost in registration time
Choice of PKI Certification Authority

- integrate GET VPN into existing enterprise CA infrastructure
- use Cisco IOS Certificate Server feature
Pre-Shared Keys (PSK)

- GM's should not share the same PSK
- a GM can use the same PSK to authenticate to all KS'es
- a GM can use different PSK's to authenticate to each KS
ISAKMP Profile
Limitations
No enforcement of match statements in ISAKMP profile

crypto pki certificate map getvpn-map
subject-name co ou = getvpn
! NOT ENFORCED !
crypto isakmp profile getvpn-ikeprof
trustpoint mycert
match certificate getvpn-map
!
crypto ipsec profile getvpn-ipsecprof
set transform-set tset
set isakmp-profile getvpn-ikeprof
!
identity number 1
server local
sa ipsec 1
profile getvpn-profile
match address ipv4 getvpn-encrypt
address ipv4 192.168.10.10
GDOI Authorization (1)
Address-Based
Standard ACL to match IP addresses of GM's and other KS'es

identity number 1
server local
authorization address ipv4 group-members
sa ipsec 1
address ipv4 192.168.10.10
!
ip access-list standard group-members
permit 192.168.20.0 0.0.0.255
permit 192.168.30.0 0.0.0.255
GDOI Authorization (2)
Certificate-Based
Crypto identity with one or more DN or FQDN match expressions

Less flexible than ISAKMP profile matching or certificate maps, but
only available option
identity number 1
server local
authorization identity getvpn-id-ou
sa ipsec 1
address ipv4 192.168.10.10
!
crypto identity getvpn-id-ou
dn ou=getvpn
Multiple Groups & Virtualization
Multiple Groups on KS
KS GM mgmt
crypto gdoi group mgmt

identity number 1
server local
authorization address gm-mgmt
sa ipsec 1
match address ipv4 noc-hosts
!
GM p1 GM o1
ip access-list standard gm-mgmt
permit ip host <GM>
... GM p2 GM o2
!
ip access-list extended mgmt-policy ip access-list extended data-policy
permit ip any host <noc-station> deny ip <control> <control>
permit ip host <noc-station> any permit ip any any
crypto gdoi group purple crypto gdoi group olive

identity number 2 identity number 3
server local server local
authorization address gm-purple authorization address gm-olive
sa ipsec 1 sa ipsec 1
match address ipv4 data-policy match address ipv4 data-policy
! !
ip access-list standard gm-purple ip access-list standard gm-olive
permit ip host <GM-p1> permit ip host <GM-o1>
permit ip host <GM-p2> permit ip host <GM-o2>
Multiple Groups on GM
KS GM mgmt
crypto gdoi group mgmt

identity number 1
server address ipv4 <KS>
!
crypto gdoi group purple
identity number 2
GM p1
!
set group mgmt GM p2
set group purple
match address exceptions
!
ip access-list extended exceptions
deny ...
!
crypto map cmap
Virtualization
Reminder: VRF-aware IPsec
VRF blue (fVRF)
(VTI config) (crypto map config)
IKE Profile: purple IKE Profile: olive

Front VRF: blue Front VRF: blue
IPsec traffic Inner VRF: olive
interface GigabitEthernet0/0
ip vrf forwarding blue
crypto map cmap
Decryption Decryption
interface Tunnel1
ip vrf forwarding purple
tunnel source GigabitEthernet0/0 interface GigabitEthernet1/1
tunnel protection ipsec profile vti ip vrf forwarding olive
Cleartext traffic Cleartext traffic
VRF purple (iVRF, LAN phy.ifc or VLAN) VRF olive (iVRF, LAN phy.ifc or VLAN)
GET VPN VRF-Awareness
crypto map purple-map 10 gdoi
set group purple
!
Key Server: crypto map green-map 10 gdoi
set group olive
- no VRF support (all in global) !
Group Member (pre-15.0 & ASR1k): ip vrf forwarding purple
crypto map purple-map
- only VRF-lite supported !
- iVRF = fVRF ip vrf forwarding olive
crypto map olive-map
- control plane VRF = data plane VRF
- crypto map on single interface
- each GDOI group in a single VRF crypto map blue-map 10 gdoi
set group blue
GM (since 15.0): VRF-aware GDOI !
- separate VRF for control plane ip vrf forwarding purple
crypto map blue-map
- same crypto map on multiple ifcs !
- same GDOI group in multiple VRFs ip vrf forwarding green
crypto map blue-map
VRF-aware GM (1)
Before IOS 15.0
GM (pre-15.0)
crypto gdoi group purple LAN WAN
identity number 2 purple-map
!
crypto gdoi group olive Crypto
ifc ifc
identity number 3 GDOI
server address ipv4 <KS> VRF purple
! KS
crypto map purple-map 10 gdoi VRF olive
set group purple GDOI
ifc ifc
match address except-purple Crypto
!
crypto map olive-map 10 gdoi olive-map
set group olive
match address except-olive
!
ip vrf forwarding purple
crypto map purple-map
!
interface Ethernet0/1 1 group per VRF
ip vrf forwarding olive 1 IKE SA per group
crypto map olive-map 1 registration per group
1 rekey per group
VRF-aware GM (2)
IOS 15.0 and later: multiple groups, multiple VRFs
GM (15.0+)
crypto gdoi group purple LAN WAN
... purple-map
client registration interface Lo0
!
crypto gdoi group olive Crypto
ifc ifc
...
client registration interface Lo0 VRF purple
!
crypto map purple-map 10 gdoi VRF olive
set group purple ifc ifc
! Crypto
crypto map olive-map 10 gdoi
set group olive olive-map
!
interface Ethernet0/0 GDOI ifc
VRF mgmt
ip vrf forwarding purple KS
crypto map purple-map Rekeys
!
ip vrf forwarding olive
crypto map olive-map 1 group per VRF
! 1 IKE SA per KS
interface Loopback0 1 registration per group
ip vrf forwarding mgmt 1 rekey per group
VRF-aware GM (3)
IOS 15.0 and later: shared group, multiple VRFs
GM (15.0+)
crypto gdoi group shared LAN WAN
...
client registration interface Lo0
!
crypto map shared-map 10 gdoi Crypto
ifc ifc
set group shared
! VRF purple
interface Ethernet0/0 shared-map
ip vrf forwarding purple VRF olive
crypto map shared-map ifc ifc
! Crypto
ip vrf forwarding olive
crypto map shared-map
! GDOI ifc
VRF mgmt
interface Loopback0 KS
ip vrf forwarding mgmt Rekey
1 group for multiple VRFs

1 IKE SA per KS
1 registration per group
1 rekey per group
NAT, Load Balancing & Fragmentation
NAT & NAT-Traversal
NAT allowed NAT allowed
NAT not allowed
Host A GM Router Router GM Host B

10.1.1.1 10.3.3.9 10.4.4.9 10.2.2.2
s=10.1.1.1 s=10.3.3.3 s=10.3.3.3 s=10.3.3.3 s=10.3.3.3

d=10.4.4.4 d=10.4.4.4 d=10.4.4.4 d=10.4.4.4 d=10.2.2.2
Payload Payload ESP Payload Payload
s=10.3.3.3
Source d=10.4.4.4
NAT Destination
Payload
Encryption Decryption NAT
ESP
NAT of encrypted traffic:

- not supported, breaks tunnel header preservation
NAT before encryption/after decryption:

- IPsec policy must include NAT'ed addresses
- NAT can be done between traffic endpoint and GM, or on GM itself
- on GM, encryption takes place after NAT, decryption before NAT
Load Balancing
Shared group SA
Front-end / back-end load balancing GM
- distribute crypto operations on multiple GM's

- SLB appliance or CEF-based
- dynamic route distribution Encryption
- platform consolidation
LB
IGP
GM GM GM
IGP
LB
Fragmentation (1)
After/Before Encryption
IP Payload IP Payload
GM
GM
IP ESP IP Payload ESP
IP ESP IP#1 Pay.. ESP

IP#1 ESP IP Pay..
IP#2 ..load ESP
IP ESP IP#2 ..load ESP
GM GM GM GM
IP#2 ..load
IP#1 Pay..
IP Payload
After encryption Before encryption
Fragmentation (2)
Configuration
interface FastEthernet0/0
Objective description WAN interface
ip mtu 1400
- fragment before encryption crypto map getvpn-cmap
!
- encrypt/decrypt IP fragments interface GigabitEthernet1/1
- reassemble on destination host description LAN interface
ip tcp adjust-mss 1380
Fragmentation avoidance
- IP MTU: configure ip mtu on interface
(100 bytes below minimum link MTU)
- TCP MSS: configure ip tcp adjust-mss
on interface (20 bytes below IP MTU)
Account for TBAR overhead

- 16 bytes (12 + optional Nitrox padding) added to ESP packets
Fragmentation (3) Actual
performances
GM Constraints Throughput (Mbps) will vary
ASR1000
Throughput limited by: 8,000
- physical link speed Scale Compressed
2,000
- crypto engine capability
1,500
Packet forwarding metrics: 1,000
3945e
- PPS vs. Mbps 500
Scale Compressed
Impact of fragmentation: 300
3945
- smaller packets: not optimal 250
- 50% hit on PPS rate 200

2951
Fragmentation has a dramatic 150
impact 100 2901
1941
50
1
74 512 1000 1400
Packet Size
IPv6 Support
IPv6 Support
No IPv6 support in GET VPN until mid-2012

IPv6 support will come in two phases
- 15.2(3)T IPv6 data plane, IPv4 control plane (GDOI/COOP on IPv4)
- TBD IPv6 data & control plane (GDOI/COOP on IPv6)
GET VPN Management
GET VPN Management
Cisco Security Manager (CSM)
GET VPN Scalability & Positioning
KS Scalability (1)
Unicast Rekeys COOP Announcements
Depends #SA, #permit, #deny #GM, #SA, #permit, #deny

Packet Size
Maximum 12 KBytes per SA (100 permit entries) 64 KBytes

Example 1 SA, 10 permit: 1358 Bytes 1 SA, 1000 GM: 12584 Bytes
Fragmentation Likely if >10 permit entries Unavoidable if >50 GM's
Depends #GM, packet size

Data
Rate
2000 GM's, size = 1430: time = 15s

Example
rekey burst rate = 1.52 Mbps for 15s
GM Registrations
#GM, IKE auth.type, platform

Session
Depends
Rate
IKE oversubscribed on KS
Risks
GM's cannot register on time
KS Scalability (2)
buffers huge permanent 10
Configuration buffers huge size 65535
!
crypto call admission limit ike in-neg 50
!
COOP announcements: ip access-list extended gdoi
permit udp any eq 848 any eq 848
- optimize huge buffers
!
- avoid 2nd-order fragmentation class-map match-all gdoi-packets
match access-group gdoi
!
Unicast rekeys: policy-map gdoi-shaper
class gdoi-packets
- increase outbound hold-queue shape average <link-speed>
- avoid 2nd-order fragmentation shape max-buffers 4096
set precedence 6
fair-queue
QoS to manage rekey/COOP burst queue-limit 4096
!
GM registrations: interface <register-ifc>
service-policy output gdoi-shaper
- increase inbound hold-queue hold-queue 4096 in
hold-queue 4096 out
- configure IKE Call Admission Control ip mtu 1480
Policy ACLs:
- global policy (KS): "permit" entries, symmetrical & aggregated
- local policy (GM): "deny" entries (all exceptions on GM)
For Your
General Scalability Reference
General scalability:
- with old registration timings: 3000 GM's total, 1000 GM's per KS
- with new registration timings: 5000 GM's total, 3000 GM's per KS
Platform numbers taken from Design & Implementation Guide (DIG) on cisco.com
- ISR-G2 numbers pending on new DIG to be published within the next months
Max GM's tested Max CPU

Platform Crypto card Time to register
(2 KS in COOP) (regist./rekey)
C7200/7201 VAM2+ 5000 40% / 18% 15s
C3845 AIM-VPN/SSL-3 1000 46% / 20% 15s
C3825 AIM-VPN/SSL-3 500 34% / 14% 15s
C2851 AIM-VPN/SSL-3 200 25% / 15% 15s
C2821 AIM-VPN/SSL-3 100 30% / 14% 15s
C7200 w/ PKI VAM2+ 1000 (*) 30% / 10% 20s
(*) PKI scales the same as PSK, but has lower IKE setup rate
Positioning
FlexVPN
EzVPN DMVPN GET VPN
Infrastructure
Public Internet Transport Public Internet Transport Private IP Transport
Network
Network Style Hub-Spoke (Client) Any-Any (Site-to-Site) Any-Any (Site-to-Site)
Routing Reverse Route Injection Dynamic on tunnels Dynamic on IP WAN
Failover Stateful Hub Crypto Route Distribution Route Distribution
Redundancy Failover Model Model + Stateful
Virtualization Yes Yes No
IP Multicast Replication at hub Replication at hub Replication in IP WAN

Forward/Backward
Yes Yes No
Access Control
PFS Yes Yes Groupkey-Pull only
Recovery methods DPD (min 15s) Routing+DPD (min 15s) None (key lifetime)
Authorization IP address, ID based
IKE Profile based IKE Profile based
management (crypto map)
Unlimited Unlimited 5000 GMs total,
Scalability
3000+ Clients/Server 4000+ Spokes/Hub 3000 GM/KS
Encryption Style Per-peer keys Per-peer keys 1 key for all GM's
Recommended Reading
Please visit the Cisco Store for suitable reading.

Please complete your Session Survey
We value your feedback
Don't forget to complete your online session evaluations after each session.
Complete 4 session evaluations & the Overall Conference Evaluation
(available from Thursday) to receive your Cisco Live T-shirt
Surveys can be found on the Attendee Website at www.ciscolivelondon.com/onsite

which can also be accessed through the screens at the Communication Stations
Or use the Cisco Live Mobile App to complete the

surveys from your phone, download the app at
www.ciscolivelondon.com/connect/mobile/app.html
1. Scan the QR code

(Go to http://tinyurl.com/qrmelist for QR code reader
software, alternatively type in the access URL above)
2. Download the app or access the mobile site
3. Log in to complete and submit the evaluations
http://m.cisco.com/mat/cleu12/

Brksec 3011

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brksec 3011

Uploaded by

Copyright:

Available Formats

Advanced IPsec with GET VPN

Follow us on Twitter for real time updates of the event:

We value your feedback- don't forget to complete your online session

GET VPN Fundamentals GET VPN Control Plane (cont.)

Key Server (KS): a device that distributes Policy

- no GDOI between GM's GM

Traffic Encryption Key (TEK): protects

IP header ESP header IP header IP payload ESP

ESP transport mode:

GET VPN uses ESP tunnel mode with header preservation:

GM's do not know their potential Policy KS

GM's encrypt multicast traffic Policy KS

KEK policy (GDOI SA) OLD NEW

TEK policy (IPsec SA)

KS sends regular rekeys to registered GM's

crypto gdoi group wan-getvpn

Global encryption policy configured on KS, pushed to GM's

Outbound traffic selected for encryption by crypto map applied on interface

Crypto group policy must be read as an egress traffic selector

Just like a regular crypto map, but non-directional proxies

Resulting policy on GM1: Push Push Resulting policy on GM2:

Global policy on KS:

Can be tuned on each GM KS

Global IPsec policy on KS, in order: Global policy on KS:

- Implicit deny any-any (don't encrypt)

Global policy on KS:

Maximum 100 ACL entries per group

The use of local policies is strongly recommended

deny udp <local> eq isakmp any eq isakmp

deny esp <local> any IPsec/ESP (prevent recursive encryption)

deny tcp <local> any eq {tacacs,ssh,bgp}

deny udp <local> any eq {ntp,dns,syslog,

deny ip <local> 224.0.0.0 0.0.0.255 Link-layer control protocols

deny ip <local> host 224.0.1.39

Fail-close policy applied at end of crypto map

Receive-only Mode Passive Mode

crypto gdoi group wan-getvpn crypto gdoi group getvpn-wan

Useful during initial GET VPN deployment

Once all GM's are configured in Passive Mode

GET VPN does not have a notion of remote peer

Host A GM A Router Router GM B Host B

s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2

Host A GM A Router Router GM B Host B

s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2 s=10.1.1.1 d=10.2.2.2

Preservation of Original IP Addresses and DSCP

Encrypted IP Packet follows 1 byte 1 byte 1 byte 1 byte

IP Header (proto = ESP, src/dst/DSCP copied from inner header)

GDOI means Group Domain of Interpretation

GDOI Registration provides:

Traffic Encryption Key (TEK): protects traffic between GM's

RFC 3547 defines two new IKE Phase 2 exchanges

GROUPKEY-PUSH (aka Rekey):

Shared by all KS'es for the group

Public key sent to GM during registration (GROUPKEY-PULL)

KEK 1, TEK 1, PUB, seq#0 GROUPKEY-PULL

(IKE SA has expired)

t = 3000s GDOI SA IPsec SA GROUPKEY-PUSH

local ident: (172.16.0.0/255.255.0.0/0/0)

One TEK = one ESP SPI current outbound spi: 0xE52B0808(3844802568)

- shows up as an ISAKMP SA spi: 0xE52B0808(3844802568)

IPv4 Crypto ISAKMP SA

Control plane replay protection added in:

GM checks seq# and pseudo-time when processing rekeys