GET VPN - Knowledge Base

1/25/2018 GET VPN - Knowledge Base
Knowledge Search this site
Base
Home
GET VPN
BGP
Data Center
GET (Group Encrypted Transport) VPN is a VPN
Docker
GPON
technology which introduces the concept to eliminate point-
Hadoop
to-point tunnels (site-to-site VPN) and associated overlay
IP Multicast
routing (DMVPN) since it relies on WAN routing. It enables
IPv6 any-to-any VPN connectivity using a group IPSec security
IS-IS paradigm.
Juniper-JUNOS
L2VPN In addition to IPSec, the following are the building blocks
LAN for GET VPN solution:
Link Aggregation
LTE Notes 1. Group Domain Of Interpretation (GDOI)
MPLS
NAT GDOI is a group key management protocol used to provide
Network Automation a set of IPSec keys to a group of IOS devices called Group
Networking Members (GM) that wish to communicate securely i.e.
DataScience
GDOI is run between a GM and a Key Server (KS). These
OAM
OSPF
keys are periodically refreshed on all devices using a
PBB
process called rekey.
PPP
QoS GDOI is a "Phase 2" protocol which is protected by "Phase 1
Security Security Association (SA)". IKE Phase 1 remains the same
Traffic Engineering as in traditional IPSec. All Group Members authenticate
VPLS themselves using IKE to the device providing keys (called a
VPN Key Server) which is statically configured for all Group
Python Members. All IKE authentication methods are supported -
Pre-Shared Keys (PSK) or RSA-Signature (PKI) or RSA-
Attachments
Encryption.
GDOI introduces two different types of encryption keys- the

Key Encryption Key (KEK) is used to secure GET VPN
https://sites.google.com/site/amitsciscozone/home/ipsec/get-vpn 1/22
control plane, and the Traffic Encryption Key (TEK)

which encrypts the data traffic.
RFC 3547 defines GDOI. GDOI runs on UDP port 848.

There are six new payloads for GDOI:
a) GDOI SA
b) SA KEK which follows the SA payload
c) SA TEK which follows the SA payload
d) Key Download Array (KD)
e) Sequence Number (SEQ)
f) Proof of Possession (POP)
2. Key Server (KS)
A Key Server is a Cisco IOS device which is responsible for

creating and maintaining GET VPN control plane. All IPSec
policies like interesting traffic, IPSec security protocols,
rekey timers, etc are manually defined on the Key Server,
and are downloaded by Group Members using registration.
Even if a Group Member owns a particular network or not, it

downloads the interesting traffic defined on the Key Server
(using ACL).
3. Co-operative Key Server (COOP KS)
GET VPN supports multiple KS if a KS fails or becomes

unreachable. A Group Member can be configured to register
with a list of KSs.
When COOP KSs boot, all KSs assume a "secondary" role

and begin election process. A KS with highest priority wins
the election (in case of a tie, the KS with highest IP Address
wins) and becomes the "primary" KS. Other KSs remain in
"secondary" state.
A GM can register with either a Primary or Secondary KS.

However, only Primary KS sends rekey messages. If a
Secondary KS does not "hear" from the Primary KS for a
period of time, the Secondary KS tries to contact Primary

KS for updated information. If the Secondary KS still does
not hear from Primary KS, re-election takes place and a
Primary KS is elected.
4. Group Member (GM)
A GM is an IOS device responsible to handle GET VPN data

plane. These are the actual devices who forms IPSec
connections between them. A GM is statically configured
with IKE Phase 1 parameters and Key Server information.
The GMs download IPSec policies and keys from the KS
during registration.
5. Rekeying
A KS performs rekey process (sending new keys when

existing keys are about to expire) which includes refreshing
keys and distributing to the GMs. GET VPN supports two
types of rekey messages:
a) Unicast rekey: In this process, the KS generates a rekey

message and sends multiple copies of the message, one for
each GM. The GM sends an ACK message upon receiving
the rekey message.
b) Multicast rekey: In this process, the KS generates a

rekey message and sends a single copy of the message to
the multicast address defined in the configuration. Each GM
joins the multicast group at the time of registration and
hence receives the rekey message. No ACK messages are
sent by GM upon receiving the rekey message.
6. Time-based Anti-Replay (TBAR)
In traditional IPSec, anti-replay capability is available using

counter-based sliding window. When the sender sends a
packet with a sequence number, the receiver uses a sliding
window to determine whether a packet is acceptable, or has
arrived out-of-sequence.
Due to group SA in GET VPN, counter-based sliding window

is ineffective. In GET VPN, all GMs can communicate with
each other using a common IPSec policy and a shared SA.
Hence, there is no need to negotiate IPSec between GMs.
GET VPN uses time-based anti-replay which is based on a
pseudotime clock maintained on the KS.
GET VPN uses Tunnel mode of IPSec, but instead of using

the tunnel endpoints in the new IP header, it reuses the
original IP header as the new Tunnel header (much like
IPSec Transport mode). This provides an advantage as the
existing routing infrastructure can be used and no separate
routing instance needs to be run for GET VPN.
Note
GET VPN is not suitable to run over Internet since it reuses the
original IP header as Tunnel IP header. This can cause end-to-end
routing issues as the traffic from Private network will not be able to
reach the remote end.
Hence, GET VPN is best suited for Private infrastructure like MPLS VPN
or VPLS.
How GDOI Works
RFC 3547 defines two new exchanges for GDOI:
i) GROUPKEY-PULL Exchange
This exchange is also called Registration. This Phase 2

exchange downloads keys for a group's Re-key SA and
Data-security SA. The Re-key SA includes Key Encryption
Key (KEK) common to the group, and the Data-security SA
includes Traffic Encryption Key (TEK) used to
encrypt/decrypt data traffic.
The Group Member (Initiator) initiates and contacts the Key

Server. The GM is configured with the group identifier and
acceptable Phase 1 policy. Once Phase 1 is complete, the

initiator moves to GDOI protocol. The initiator builds a
NONCE payload by choosing the Ni (Nonce value by
initiator), builds an ID payload using the group identifier,
and generates HASH(1). The first GDOI message is also
called Request message.
Upon receipt of the GDOI message, the Key Server

(Responder) processes the NONCE and ID payloads. It
verifies that its database contains the group information for
the group ID. It constructs the second GDOI message,
chooses the Nr (Nonce value by responder) for NONCE
payload, the policy for the group in the ID payload, followed
by SA TEK payload for traffic SAs and SA KEK payload, and
generates HASH(2). The second GDOI message is also
called Push message.
The GM receives the second GDOI message, validates the

HASH(2) and process NONCE and SA payloads. If the group
policy uses Certificates for authorization, the GM generates
a hash with Ni and Nr, and signs it. This becomes the POP
payload. The CERT payload holds the Public Key. The GM
creates the third GDOI message using POP and CERT
payloads, and generates HASH(3). The third GDOI
messages is also called ACK message.
Upon receipt of the third GDOI message, the KS validates

the hash. It constructs a fourth GDOI message including the
SEQ payload containing the sequence number, the KD
payload containing keys corresponding to policy previously
sent in SA TEK and KEK, and POP and CERT payloads (if
needed), and generates HASH(4). The fourth message is
also called Key Download message.
The GM receives the fourth GDOI message and validates

the hash. It then processes the SA TEK and KEK payloads.
The ISAKMP Header is protected by IKE Phase1 while

everything after the header is encrypted. KE payload is
used if Perfect Forward Secrecy (PFS) is set.
ii) GROUPKEY-PUSH Exchange
The GROUPKEY-PUSH message replaces a Re-key SA &/or

Data-security SA, and it can be pushed using unicast or
multicast. It is only a single message generated by the KS.
It includes new keys when the key-lifetime is about to
finish.
Sample Scenario
A Key Server is present at the Central Site. To demonstrate

unicast rekeying process with Key Server, this scenario has
Group Members GM-1 and GM-2 register with Key Server
(KS).
Key Server (KS) Configuration
1. Configuring IKE Policy on KS
The IKE Phase 1 remains exactly the same as traditional

IPSec. Authentication methods supported are pre-shared
keys or digital certificates. In this case, we will use the pre-
shared keys.
IKE Policy on KSs

crypto isakmp policy 10
authentication pre-share
!
crypto isakmp key 0 cisco address 2.2.2.2 ! Central router
crypto isakmp key 0 cisco address 11.11.11.11 ! GM-1 router
crypto isakmp key 0 cisco address 22.22.22.22 ! GM-2 router
!
2. Configuring GDOI Group

A KS must generate exportable RSA Key-pair. This key-

pair will be used for rekeying. If a redundant KS is present,
these keys (Public and Private Keys) must also be exported
to this redundant KS manually.
Generating RSA Key-pair

crypto key generate rsa general-keys label GDOI_KEYS modulus 1024
exportable
Then an access-list policy needs to be defined on the KS

which will identify the interesting traffic. This ACL Policy will
also be downloaded by all GMs for this KS. A Symmetric
ACL policy is recommended on the KS which includes all the
networks from the GMs as source and destination. In this
case, it would be as below:
Symmetric ACL Policy

ip access-list extended ACL
permit ip 192.168.0.0 0.0.255.255 192.168.0.0 0.0.255.255
Lastly, we create a GDOI group on KSs. Each group defined

on the KS has an identity that is shared among the GMs
within the group. Here, the identity is set to 123 for the
group GDOI_GROUP.
KS will be responsible for sending rekey messages. Here,

rekey messages are sent through unicast transport
mechanism with 2 retransmit messages every 60 seconds.
KS GDOI Configuration
crypto ipsec transform-set GDOI_TS esp-3des esp-md5-hmac
!
crypto ipsec profile GDOI_PROFILE
set transform-set GDOI_TS
set security-association lifetime seconds 3600 ! Indicates how long
IPSec SAs remain valid before they are renegotiated (can be set to
default)
!
crypto gdoi group GDOI_GROUP
identity number 123 ! Group SA identifier
server local ! Indicates this is a Key Server
!
! Rekey configuration
rekey retransmit 60 number 2 ! Indicates if a change is made on
KS, rekey messages will be sent in 60 seconds, twice..default is 10
seconds, 2 times.
rekey lifetime seconds 86400 ! Indicates how often to rekey (can
be set to default- 24 hours)
rekey transport unicast
rekey authentication mypubkey rsa GDOI_KEYS ! Specifies the keys to
be used for a rekey to GDOI GMs
!
! Configuring Security Policies
sa ipsec 1
profile GDOI_PROFILE ! Use IPSec Profile configured
above
match address ipv4 ACL ! Indicates interesting traffic to
be encrypted
replay time window-size 5 ! Anti-replay window-size is set to
5
!
address ipv4 1.1.1.1 ! Use this address to source rekey
packets
!
!
GM Configuration
1. Configuring IKE Policies
All GMs authenticate with the KS using pre-shared keys.
IKE Policy on GMs

crypto isakmp policy 10
authentication pre-share
!
crypto isakmp key 0 cisco address 1.1.1.1 ! KS Router
!
2. Configuring GDOI Group
A GM is configured using the same group SA identity

number as on the KS and Server IP address.
GDOI Group Configuration on GM-1 and GM-2

crypto gdoi group GDOI_GROUP
identity number 123
server address ipv4 1.1.1.1 ! Key Server KS
!
3. Configuring Crypto Map
This step involves creating a crypto-map and applying the

crypto-map to the physical interface.
Configuring and Applying Crypto Map on GMs

crypto map GETVPN local-address Loopback 0 ! Use Loopback 0 IP
address when contacting the KS
!
crypto map GETVPN 10 gdoi
set group GDOI_GROUP
!
interface serial 1/0
description Connection to PE
....
crypto map GETVPN
!
Verification
When the crypto-map is applied to the physical interface on

GM-1, it immediately sends a Register message to the KS
and downloads the policies. All GMs follow the same
process. The below output is taken from KS using debug
crypto gdoi command.
debug crypto gdoi command on KS

*Jun 28 23:46:51.247: ISAKMP (0): received packet from 11.11.11.11 dport
848 sport 848 Global (N) NEW SA
*Jun 28 23:46:51.251: ISAKMP: Created a peer struct for 11.11.11.11,
peer port 848
*Jun 28 23:46:51.251: ISAKMP: New peer created peer = 0x678DBAAC

peer_handle = 0x80000006
*Jun 28 23:46:51.255: ISAKMP: Locking peer struct 0x678DBAAC, refcount 1
for crypto_isakmp_process_block
*Jun 28 23:46:51.259: ISAKMP: local port 848, remote port 848
*Jun 28 23:46:51.263: ISAKMP:(0):insert sa successfully sa = 66CCDB50
*Jun 28 23:46:51.267: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jun 28 23:46:51.267: ISAKMP:(0):Old State = IKE_READY New State =
IKE_R_MM1 ! KS receives an IKE Proposal from GM-1
*Jun 28 23:46:51.283: ISAKMP:(0): processing SA payload. message ID = 0

*Jun 28 23:46:51.287: ISAKMP:(0):Switching to SW IKE SA: sa is 66CCDB50,
ce_id is 80000002
*Jun 28 23:46:51.291: ISAKMP:(0): processing vendor id payload
*Jun 28 23:46:51.291: ISAKMP:(0): vendor ID seems Unity/DPD but major 69
mismatch
*Jun 28 23:46:51.295: ISAKMP (0): vendor ID is NAT-T RFC 3947
*Jun 28 23:46:51.299: ISAKMP:(0): vendor ID seems Unity/DPD but major
245 mismatch
*Jun 28 23:46:51.303: ISAKMP (0): vendor ID is NAT-T v7
157 mismatch
*Jun 28 23:46:51.307: ISAKMP:(0): vendor ID is NAT-T v3
123 mismatch
*Jun 28 23:46:51.319: ISAKMP:(0):found peer pre-shared key matching
11.11.11.11
*Jun 28 23:46:51.323: ISAKMP:(0): local preshared key found
*Jun 28 23:46:51.323: ISAKMP : Scanning profiles for xauth ...
*Jun 28 23:46:51.327: ISAKMP:(0):Checking ISAKMP transform 1 against
priority 10 policy
*Jun 28 23:46:51.327: ISAKMP: encryption DES-CBC
*Jun 28 23:46:51.327: ISAKMP: hash SHA
*Jun 28 23:46:51.331: ISAKMP: default group 1
*Jun 28 23:46:51.331: ISAKMP: auth pre-share
*Jun 28 23:46:51.335: ISAKMP: life type in seconds
*Jun 28 23:46:51.335: ISAKMP: life duration (VPI) of 0x0 0x1 0x51
0x80
*Jun 28 23:46:51.339: ISAKMP:(0):atts are acceptable. Next payload is 0
*Jun 28 23:46:51.343: ISAKMP:(0):Acceptable atts:actual life: 0
*Jun 28 23:46:51.343: ISAKMP:(0):Acceptable atts:life: 0
*Jun 28 23:46:51.347: ISAKMP:(0):Fill atts in sa vpi_length:4
*Jun 28 23:46:51.347: ISAKMP:(0):Fill atts in sa life_in_seconds:86400
*Jun 28 23:46:51.351: ISAKMP:(0):Returning Actual lifetime: 86400
*Jun 28 23:46:51.355: ISAKMP:(0)::Started lifetime timer: 86400.

*Jun 28 23:46:51.359: ISAKMP:(0): vendor ID seems Unity/DPD but major 69
mismatch
*Jun 28 23:46:51.359: ISAKMP (0): vendor ID is NAT-T RFC 3947

245 mismatch
*Jun 28 23:46:51.367: ISAKMP (0): vendor ID is NAT-T v7
157 mismatch
123 mismatch
*Jun 28 23:46:51.387: ISAKMP:(0):Input = IKE_MESG_INTERNAL,
IKE_PROCESS_MAIN_MODE
*Jun 28 23:46:51.391: ISAKMP:(0):Old State = IKE_R_MM1 New State =
IKE_R_MM1
*Jun 28 23:46:51.395: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

*Jun 28 23:46:51.399: ISAKMP:(0): sending packet to 11.11.11.11 my_port
848 peer_port 848 (R) MM_SA_SETUP
*Jun 28 23:46:51.403: ISAKMP:(0):Sending an IKE IPv4 Packet.
IKE_PROCESS_COMPLETE
IKE_R_MM2 ! KS matches the IKE Proposal, and if, the attributes
matches, it sends a Policy Acceptance message to GM-1 router

848 sport 848 Global (R) MM_SA_SETUP
*Jun 28 23:46:51.675: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
IKE_R_MM3 ! KS receives a shared-secret key from GM-1 router
*Jun 28 23:46:51.687: ISAKMP:(0): processing KE payload. message ID = 0

*Jun 28 23:46:51.731: ISAKMP:(0): processing NONCE payload. message ID =
0
*Jun 28 23:46:51.739: ISAKMP:(0):found peer pre-shared key matching
11.11.11.11
*Jun 28 23:46:51.751: ISAKMP:(1003): vendor ID is DPD
*Jun 28 23:46:51.755: ISAKMP:(1003): speaking to another IOS box!
221 mismatch
*Jun 28 23:46:51.759: ISAKMP:(1003): vendor ID is XAUTH
*Jun 28 23:46:51.759: ISAKMP:received payload type 20
*Jun 28 23:46:51.759: ISAKMP (1003): His hash no match - this node
outside NAT
*Jun 28 23:46:51.759: ISAKMP:received payload type 20
*Jun 28 23:46:51.759: ISAKMP (1003): No NAT Found for self or peer
IKE_R_MM3
*Jun 28 23:46:51.759: ISAKMP:(1003): sending packet to 11.11.11.11

my_port 848 peer_port 848 (R) MM_KEY_EXCH
IKE_R_MM4 ! KS also derives the same shared-secret key and sends it
to GM-1
!--- Both peers now authenticate each other using Messages 5 and 6
!
*Jun 28 23:46:51.919: ISAKMP (1003): received packet from 11.11.11.11
dport 848 sport 848 Global (R) MM_KEY_EXCH
*Jun 28 23:46:51.923: ISAKMP:(1003):Input = IKE_MESG_FROM_PEER,
IKE_MM_EXCH
IKE_R_MM5
*Jun 28 23:46:51.939: ISAKMP:(1003): processing ID payload. message ID =

0
*Jun 28 23:46:51.939: ISAKMP (1003): ID payload
next-payload : 8
type : 1
address : 11.11.11.11
protocol : 17
port : 848
length : 12
*Jun 28 23:46:51.947: ISAKMP:(0):: peer matches *none* of the profiles
*Jun 28 23:46:51.947: ISAKMP:(1003): processing HASH payload. message ID
= 0
*Jun 28 23:46:51.955: ISAKMP:(1003): processing NOTIFY INITIAL_CONTACT
protocol 1
spi 0, message ID = 0, sa = 66CCDB50
*Jun 28 23:46:51.955: ISAKMP:(1003):SA authentication status:
authenticated
*Jun 28 23:46:51.959: ISAKMP:(1003):SA has been authenticated with
11.11.11.11
*Jun 28 23:46:51.963: ISAKMP:(1003):SA authentication status:
authenticated
*Jun 28 23:46:51.967: ISAKMP:(1003): Process initial contact,
bring down existing phase 1 and 2 SA's with local 1.1.1.1 remote
11.11.11.11 remote port 848
*Jun 28 23:46:51.971: ISAKMP: Trying to insert a peer
1.1.1.1/11.11.11.11/848/, and inserted successfully 678DBAAC.
IKE_R_MM5
*Jun 28 23:46:51.991: ISAKMP:(1003):SA is doing pre-shared key

authentication using id type ID_IPV4_ADDR
*Jun 28 23:46:51.995: ISAKMP (1003): ID payload
next-payload : 8
type : 1
address : 1.1.1.1
protocol : 17
port : 500
length : 12
*Jun 28 23:46:52.003: ISAKMP:(1003):Total payload length: 12
my_port 848 peer_port 848 (R) MM_KEY_EXCH
IKE_P1_COMPLETE

IKE_PHASE1_COMPLETE
*Jun 28 23:46:52.035: ISAKMP:(1003):Old State = IKE_P1_COMPLETE New
State = IKE_P1_COMPLETE
!---- Once IKE Phase 1 is completed, GDOI protocol starts. The GM-1
sends a Register message to KS for group-identity 123
!
dport 848 sport 848 Global (R) GDOI_IDLE
*Jun 28 23:46:52.295: ISAKMP: set new node 847121871 to GDOI_IDLE
= 847121871
*Jun 28 23:46:52.307: ISAKMP:(1003): processing NONCE payload. message
ID = 847121871
!---- The KS sends the second GDOI message- PUSH message. It carries the
policy for the group-identity, and KEK and TEK policy
my_port 848 peer_port 848 (R) GDOI_IDLE
*Jun 28 23:46:52.327: ISAKMP:(1003):Node 847121871, Input =
IKE_MESG_FROM_PEER, IKE_GDOI_EXCH
*Jun 28 23:46:52.327: ISAKMP:(1003):Old State = GDOI_KS_LISTEN New
State = GDOI_KS_AWAIT_ACK
!---- KS receives a GDOI ACK message from GM-1

dport 848 sport 848 Global (R) GDOI_IDLE
= 847121871
!---- KS now sends the Key Download GDOI message carrying the KEK and
TEK Keys for policies distributed earlier
my_port 848 peer_port 848 (R) GDOI_IDLE
*Jun 28 23:46:52.599: ISAKMP:(1003):deleting node 847121871 error TRUE
reason ""
*Jun 28 23:46:52.603: ISAKMP:(1003):Node 847121871, Input =
IKE_MESG_FROM_PEER, IKE_GDOI_EXCH
*Jun 28 23:46:52.603: ISAKMP:(1003):Old State = GDOI_KS_AWAIT_ACK New
State = GDOI_KS_AWAIT_ACK
The show crypto gdoi command displays all the basic

configuration about a GDOI group. The output vary
depending on KS or GM.
show crypto gdoi on KS

KS# show crypto gdoi group GDOI_GROUP
Group Name : GDOI_GROUP (Unicast)
Group Identity : 123
Group Members : 3
IPSec SA Direction : Both
Active Group Server : Local
Group Rekey Lifetime : 86400 secs
Group Rekey
Remaining Lifetime : 83307 secs
Rekey Retransmit Period : 60 secs
Rekey Retransmit Attempts: 2
Group Retransmit
IPSec SA Number : 1
IPSec SA Rekey Lifetime: 3600 secs
Profile Name : GDOI_PROFILE
Replay method : Time Based
Replay Window Size : 5
SA Rekey
ACL Configured : access-list ACL
Group Server list : Local
This GDOI policy is downloaded on GM. The below output

shows GDOI group on GM-1.
show crypto gdoi on GM-1

GM-1# show crypto gdoi
GROUP INFORMATION
Group Name : GDOI_GROUP

Rekeys received : 1

Active Group Server : 1.1.1.1
Group Server list : 1.1.1.1
GM Reregisters in : 2607 secs

Rekey Received(hh:mm:ss) : 00:14:18
Rekeys received
Cumulative : 1
After registration : 1
Rekey Acks sent : 1
ACL Downloaded From KS 1.1.1.1:

access-list permit ip 192.168.0.0 0.0.255.255 192.168.0.0
0.0.255.255
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 83284
Encrypt Algorithm : 3DES
Key Size : 192
Sig Hash Algorithm : HMAC_AUTH_SHA
Sig Key Length (bits) : 1024
TEK POLICY for the current KS-Policy ACEs Downloaded:

Serial1/0:
IPsec SA:
spi: 0xAA96A792(2862000018)
transform: esp-3des esp-md5-hmac
sa timing:remaining key lifetime (sec): (2741)
Anti-Replay(Time Based) : 5 sec interval
The show crypto gdoi ks command shows number of GMs

registered with the KS for a particular group.
show crypto gdoi ks on KS

KS# show crypto gdoi ks
Total group members registered to this box: 3
Key Server Information For Group GDOI_GROUP:

Group Name : GDOI_GROUP
Group Members : 3
ACL Configured:
access-list ACL
The show crypto gdoi gm command displays GDOI

information on GM.
show crypto gdoi gm on GM-1

GM-1# show crypto gdoi gm
Group Member Information For Group GDOI_GROUP:
ACL Received From KS : gdoi_group_GDOI_GROUP_temp_acl
Last rekey seq num : 1
Re-register
Remaining time : 2593 secs
Retry Timer
:NOT RUNNING
Rekey Messages
When the key lifetime is about to expire on KS, the KS

sends new keys via unicast or multicast (depending on the
mechanism configured). Here, KS sends unicast rekey
messages to all GMs (Central, GM-1 and GM-2 routers). All
GMs responds back with an ACK message to the KS.
debug crypto gdoi on KS

KS#
*Jun 28 23:59:35.927: ISAKMP:(0):insert sa successfully sa = 66CCE314
*Jun 28 23:59:35.927: ISAKMP:(0):Node 0, Input = IKE_MESG_FROM_TIMER,
IKE_GDOI_REKEY_TIMER_EXPIRED
*Jun 28 23:59:35.931: ISAKMP:(0):Old State = UNKNOWN New State =
GDOI_KS_REKEY_READY
*Jun 28 23:59:36.043: ISAKMP:(0): sending packet to my_port 848
peer_port 848 (I) GDOI_REKEY
*Jun 28 23:59:36.359: %GDOI-5-KS_SEND_UNICAST_REKEY: Sending Unicast
Rekey for group GDOI_GROUP from address 1.1.1.1 with seq # 1
!---- KS receives ACK messages from GMs

*Jun 28 23:59:36.531: ISAKMP (0): received packet from 2.2.2.2 dport 848
sport 848 Global (I) GDOI_REKEY
848 sport 848 Global (I) GDOI_REKEY

848 sport 848 Global (I) GDOI_REKEY
The following output is taken from Central router receiving

rekey messages from KS. It basically contains the Key
Download (KD) payload which contains new keys for KEK
and TEK policies.
Rekey message received on Central router

Central#
*Jun 28 23:59:45.523: GDOI:INFRA:(GDOI_GROUP:1004):Received Rekey
Message!
*Jun 28 23:59:45.551: GDOI:INFRA:(GDOI_GROUP:1004):Signature Valid!
*Jun 28 23:59:45.555: GDOI:INFRA:(1004):received payload type 18
*Jun 28 23:59:45.555: GDOI:INFRA:(1004):processing GDOI Seq Payload,
message_id 0
*Jun 28 23:59:45.559: GDOI:REPLAY:(GDOI_GROUP:0): KS PSEUDOTIME is
5265.50 (secs)
*Jun 28 23:59:45.559: GDOI:INFRA:(1004):Completed SEQ Processing for seq
1
*Jun 28 23:59:45.563: GDOI:INFRA:(1004):processing GDOI SA Payload,
message ID + 0
*Jun 28 23:59:45.563: GDOI:REKEY:(0):Received Rekey Cookies matched our
Group Info
*Jun 28 23:59:45.571: GDOI:INFRA:(1004):processing GDOI SA KEK Payload

*Jun 28 23:59:45.575: GDOI:INFRA:(1004): kek_sa->src 1.1.1.1
kek_sa->dst 2.2.2.2
*Jun 28 23:59:45.579: GDOI:INFRA:(1004): KEK_ALGORITHM 5
*Jun 28 23:59:45.583: GDOI:INFRA:(1004): KEY_LENGTH 192
*Jun 28 23:59:45.583: GDOI:INFRA:(1004): KEY_LIFETIME 83284
*Jun 28 23:59:45.587: GDOI:INFRA:(1004): UNICAST REKEY TRANSPORT
*Jun 28 23:59:45.587: GDOI:INFRA:(1004): SIG_HASH_ALG 2
*Jun 28 23:59:45.587: GDOI:INFRA:(1004): SIG_ALG 1
*Jun 28 23:59:45.591: GDOI:INFRA:(1004): SIG_KEY_LEN 1024
*Jun 28 23:59:45.591: GDOI:INFRA:(1004): Completed KEK Processing
Group Info
*Jun 28 23:59:45.599: GDOI:INFRA:(GDOI_GROUP:1004): TEK SPI is

0xB8F577EF
*Jun 28 23:59:45.603: GDOI:INFRA:(GDOI_GROUP:1004): Completed processing
GDOI SA TEK Payload - PERMIT
Group Info
*Jun 28 23:59:45.607: GDOI:INFRA:(GDOI_GROUP:1004): TEK SPI is

0xAA96A792
*Jun 28 23:59:45.611: GDOI:INFRA:(GDOI_GROUP:1004): Completed processing
GDOI SA TEK Payload - PERMIT
*Jun 28 23:59:45.611: GDOI:INFRA:(1004):processing GDOI Private

Attribute Payload
*Jun 28 23:59:45.615: GDOI:INFRA:(1004): Completed GDOI Attribute
Processing
*Jun 28 23:59:45.619: GDOI:INFRA:(GDOI_GROUP:1004):Completed processing
2 GDOI SA TEK Payloads
*Jun 28 23:59:45.619: GDOI:INFRA:(1004):received payload type 17
Group Info
*Jun 28 23:59:45.623: GDOI:INFRA:(1004):processing GDOI KD Payload,

message_id 0
*Jun 28 23:59:45.627: GDOI:INFRA:(1004):processing GDOI Key Packet,
message_id 1694900728
*Jun 28 23:59:45.627: GDOI:INFRA:(1004):processing TEK KD: spi is
0xB8F577EF
*Jun 28 23:59:45.631: GDOI:INFRA:(1004):processing LIST of TEK SA spis
*Jun 28 23:59:45.635: GDOI:INFRA:(1004): SA TEK spi is 0xB8F577EF ,
current KD TEK spi is 0xB8F577EF
*Jun 28 23:59:45.635: GDOI:INFRA:(1004): lifetime is

485 seconds
*Jun 28 23:59:45.639: GDOI:INFRA:(1004):TEK Integrity Key 16 bytes
*Jun 28 23:59:45.643: GDOI:INFRA:(1004):Completed KeyPkt Processing
*Jun 28 23:59:45.651: GDOI:INFRA:(1004):processing TEK KD: spi is
0xAA96A792
*Jun 28 23:59:45.651: GDOI:INFRA:(1004):processing LIST of TEK SA spis
*Jun 28 23:59:45.655: GDOI:INFRA:(1004): SA TEK spi is 0xB8F577EF ,
current KD TEK spi is 0xAA96A792
*Jun 28 23:59:45.659: GDOI:INFRA:(1004): SA TEK spi is 0xAA96A792 ,

current KD TEK spi is 0xAA96A792
*Jun 28 23:59:45.659: GDOI:INFRA:(1004): lifetime is

3600 seconds
*Jun 28 23:59:45.663: GDOI:INFRA:(1004):TEK Integrity Key 16 bytes
*Jun 28 23:59:45.671: GDOI:INFRA:(1004): Processing KEK KD
*Jun 28 23:59:45.679: GDOI:INFRA:(1004):Unicast Rekey from KS 1
*Jun 28 23:59:45.687: GDOI:INFRA:(GDOI_GROUP:1004):GDOI : Sending

GDOI_REKEYACK_PUSH
from 2.2.2.2 to 1.1.1.1 for seq # 1
*Jun 28 23:59:45.691: GDOI:GM_REKEY:(0):What's in the pre-hash packet?
*Jun 28 23:59:45.691: GDOI:GM_REKEY:(0):message start is : 52
*Jun 28 23:59:45.695: GDOI:GM_REKEY:(0):Length being hashed : 16
What's being sent to hash on the GM side?
*Jun 28 23:59:45.695: GDOI:GM_REKEY:(0):What's in the payload to hash?
*Jun 28 23:59:45.699: GDOI:REKEY:(0):Digest being copied into ack

payload :
*Jun 28 23:59:45.703: GDOI:GM_REKEY:(0):Total payload sent to KS 68
*Jun 28 23:59:45.711: GDOI:INFRA:(GDOI_GROUP:1004):GDOI REKEY ACK sent

successfully by GM from
2.2.2.2 to 1.1.1.1 for seq # 1 using spi B955AD0B7CD84DAB
*Jun 28 23:59:45.715: %GDOI-5-GM_RECV_REKEY: Received Rekey for group
GDOI_GROUP from 1.1.1.1 to 2.2.2.2 with seq # 1
*Jun 28 23:59:45.719: GDOI:INFRA:(GDOI_GROUP:1004): using SPI
B955AD0B7CD84DAB
Group Info
*Jun 28 23:59:45.747: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match:

ipsec identities
src addr : 192.168.0.0
dst addr : 192.168.0.0
src mask addr : 255.255.0.0
dst mask addr
ipsec identities
protocol : 0
src port : 0
dst port : 0
ks ace
ace src addr : 192.168.0.0
ace dst addr : 192.168.0.0
ace src mask addr : 0.0.255.255
ace dst mask a
ks ace
ace protocol : 256
ace src port : 0
ace dst port : 0
*Jun 28 23:59:45.763: GDOI:INFRA:(GDOI_GROUP:0):crypto exact match ace
number : 1

Group Info

ipsec identities
src addr : 192.168.0.0
dst addr : 192.168.0.0
src mask addr : 255.255.0.0
dst mask addr
ipsec identities
protocol : 0
src port : 0
dst port : 0
ks ace
ace src addr : 192.168.0.0
ace dst addr : 192.168.0.0
ace src mask addr : 0.0.255.255
ace dst mask a
ks ace
ace protocol : 256
ace src port : 0
ace dst port : 0
*Jun 28 23:59:45.795: GDOI:INFRA:(GDOI_GROUP:0):crypto exact match ace
number : 1
*Jun 28 23:59:45.803: GDOI:GM:(0):Unicast Rekey installed 1 new ipsec

SA(s) for group GDOI_GROUP.
*Jun 28 23:59:45.807: GDOI:GM:(GDOI_GROUP:0):If no rekey is received in

3482 seconds, group GDOI_GROUP will re-register to KS
Further reading:
1. http://www.securemulticast.org/msec2_ietf51_gd
2. http://www.wr-mem.com/?p=307
3. http://www.cisco.com/en/US/prod/collateral/ios
Comments
Sign in | Recent Site Activity | Report Abuse | Print Page | Powered By Google Sites

GET VPN - Knowledge Base

Uploaded by

Document Information

Original Description:

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

GET VPN - Knowledge Base

Uploaded by

Copyright:

Available Formats

1/25/2018 GET VPN - Knowledge Base

Knowledge Search this site

GDOI introduces two different types of encryption keys- the

control plane, and the Traffic Encryption Key (TEK)

RFC 3547 defines GDOI. GDOI runs on UDP port 848.

2. Key Server (KS)

A Key Server is a Cisco IOS device which is responsible for

Even if a Group Member owns a particular network or not, it

3. Co-operative Key Server (COOP KS)

GET VPN supports multiple KS if a KS fails or becomes

When COOP KSs boot, all KSs assume a "secondary" role

A GM can register with either a Primary or Secondary KS.

period of time, the Secondary KS tries to contact Primary

4. Group Member (GM)

A GM is an IOS device responsible to handle GET VPN data

A KS performs rekey process (sending new keys when

a) Unicast rekey: In this process, the KS generates a rekey

b) Multicast rekey: In this process, the KS generates a

6. Time-based Anti-Replay (TBAR)

In traditional IPSec, anti-replay capability is available using

Due to group SA in GET VPN, counter-based sliding window

GET VPN uses Tunnel mode of IPSec, but instead of using

How GDOI Works

RFC 3547 defines two new exchanges for GDOI:

This exchange is also called Registration. This Phase 2

The Group Member (Initiator) initiates and contacts the Key

acceptable Phase 1 policy. Once Phase 1 is complete, the

Upon receipt of the GDOI message, the Key Server

The GM receives the second GDOI message, validates the

Upon receipt of the third GDOI message, the KS validates

The GM receives the fourth GDOI message and validates

The ISAKMP Header is protected by IKE Phase1 while

ii) GROUPKEY-PUSH Exchange

The GROUPKEY-PUSH message replaces a Re-key SA &/or

A Key Server is present at the Central Site. To demonstrate

Key Server (KS) Configuration

1. Configuring IKE Policy on KS

The IKE Phase 1 remains exactly the same as traditional

IKE Policy on KSs

2. Configuring GDOI Group

A KS must generate exportable RSA Key-pair. This key-

Generating RSA Key-pair

Then an access-list policy needs to be defined on the KS

Symmetric ACL Policy

Lastly, we create a GDOI group on KSs. Each group defined

KS will be responsible for sending rekey messages. Here,

1. Configuring IKE Policies

All GMs authenticate with the KS using pre-shared keys.

IKE Policy on GMs

2. Configuring GDOI Group

A GM is configured using the same group SA identity

number as on the KS and Server IP address.

GDOI Group Configuration on GM-1 and GM-2

3. Configuring Crypto Map

This step involves creating a crypto-map and applying the

Configuring and Applying Crypto Map on GMs

When the crypto-map is applied to the physical interface on

debug crypto gdoi command on KS

*Jun 28 23:46:51.251: ISAKMP: New peer created peer = 0x678DBAAC

*Jun 28 23:46:51.283: ISAKMP:(0): processing SA payload. message ID = 0

*Jun 28 23:46:51.355: ISAKMP:(0): processing vendor id payload

*Jun 28 23:46:51.363: ISAKMP:(0): processing vendor id payload

*Jun 28 23:46:51.395: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID