Embedded Files
GET VPN
GET (Group Encrypted Transport) VPN is a VPN technology which introduces the concept to eliminate point-to-point tunnels (site-to-site VPN) and associated overlay routing (DMVPN) since it relies on WAN routing. It enables any-to-any VPN connectivity using a group IPSec security paradigm.
In addition to IPSec, the following are the building blocks for GET VPN solution:
1. Group Domain Of Interpretation (GDOI)
GDOI is a group key management protocol used to provide a set of IPSec keys to a group of IOS devices called Group Members (GM) that wish to communicate securely i.e. GDOI is run between a GM and a Key Server (KS). These keys are periodically refreshed on all devices using a process called rekey.
GDOI is a "Phase 2" protocol which is protected by "Phase 1 Security Association (SA)". IKE Phase 1 remains the same as in traditional IPSec. All Group Members authenticate themselves using IKE to the device providing keys (called a Key Server) which is statically configured for all Group Members. All IKE authentication methods are supported - Pre-Shared Keys (PSK) or RSA-Signature (PKI) or RSA-Encryption.
GDOI introduces two different types of encryption keys- the Key Encryption Key (KEK) is used to secure GET VPN 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 routercrypto isakmp key 0 cisco address 11.11.11.11 ! GM-1 routercrypto 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 exportableThen 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.255Lastly, 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.295: ISAKMP:(0): processing vendor id payload*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*Jun 28 23:46:51.303: ISAKMP:(0): processing vendor id payload*Jun 28 23:46:51.307: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch*Jun 28 23:46:51.307: ISAKMP:(0): vendor ID is NAT-T v3*Jun 28 23:46:51.311: ISAKMP:(0): processing vendor id payload*Jun 28 23:46:51.315: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch*Jun 28 23:46:51.315: ISAKMP:(0): vendor ID is NAT-T v2*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.355: ISAKMP:(0): processing vendor id payload*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*Jun 28 23:46:51.363: ISAKMP:(0): processing vendor id payload*Jun 28 23:46:51.367: ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch*Jun 28 23:46:51.367: ISAKMP (0): vendor ID is NAT-T v7*Jun 28 23:46:51.371: ISAKMP:(0): processing vendor id payload*Jun 28 23:46:51.375: ISAKMP:(0): vendor ID seems Unity/DPD but major 157 mismatch*Jun 28 23:46:51.375: ISAKMP:(0): vendor ID is NAT-T v3*Jun 28 23:46:51.379: ISAKMP:(0): processing vendor id payload*Jun 28 23:46:51.383: ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch*Jun 28 23:46:51.383: ISAKMP:(0): vendor ID is NAT-T v2*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.*Jun 28 23:46:51.407: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE*Jun 28 23:46:51.407: ISAKMP:(0):Old State = IKE_R_MM1 New State = IKE_R_MM2 ! KS matches the IKE Proposal, and if, the attributes matches, it sends a Policy Acceptance message to GM-1 router*Jun 28 23:46:51.667: ISAKMP (0): received packet from 11.11.11.11 dport 848 sport 848 Global (R) MM_SA_SETUP*Jun 28 23:46:51.675: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH*Jun 28 23:46:51.675: ISAKMP:(0):Old State = IKE_R_MM2 New State = 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.747: ISAKMP:(1003): processing vendor id payload*Jun 28 23:46:51.751: ISAKMP:(1003): vendor ID is DPD*Jun 28 23:46:51.755: ISAKMP:(1003): processing vendor id payload*Jun 28 23:46:51.755: ISAKMP:(1003): speaking to another IOS box!*Jun 28 23:46:51.759: ISAKMP:(1003): processing vendor id payload*Jun 28 23:46:51.759: ISAKMP:(1003): vendor ID seems Unity/DPD but major 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*Jun 28 23:46:51.759: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE*Jun 28 23:46:51.759: ISAKMP:(1003):Old State = IKE_R_MM3 New State = 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*Jun 28 23:46:51.759: ISAKMP:(1003):Sending an IKE IPv4 Packet.*Jun 28 23:46:51.759: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE*Jun 28 23:46:51.763: ISAKMP:(1003):Old State = IKE_R_MM3 New State = 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*Jun 28 23:46:51.927: ISAKMP:(1003):Old State = IKE_R_MM4 New State = 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.*Jun 28 23:46:51.975: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE*Jun 28 23:46:51.979: ISAKMP:(1003):Old State = IKE_R_MM5 New State = 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*Jun 28 23:46:52.007: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) MM_KEY_EXCH*Jun 28 23:46:52.011: ISAKMP:(1003):Sending an IKE IPv4 Packet.*Jun 28 23:46:52.015: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE*Jun 28 23:46:52.019: ISAKMP:(1003):Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE*Jun 28 23:46:52.031: ISAKMP:(1003):Input = IKE_MESG_INTERNAL, 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!*Jun 28 23:46:52.291: ISAKMP (1003): received packet from 11.11.11.11 dport 848 sport 848 Global (R) GDOI_IDLE*Jun 28 23:46:52.295: ISAKMP: set new node 847121871 to GDOI_IDLE*Jun 28 23:46:52.303: ISAKMP:(1003): processing HASH payload. message ID = 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*Jun 28 23:46:52.319: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) GDOI_IDLE*Jun 28 23:46:52.323: ISAKMP:(1003):Sending an IKE IPv4 Packet.*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*Jun 28 23:46:52.571: ISAKMP (1003): received packet from 11.11.11.11 dport 848 sport 848 Global (R) GDOI_IDLE*Jun 28 23:46:52.579: ISAKMP:(1003): processing HASH payload. message ID = 847121871!---- KS now sends the Key Download GDOI message carrying the KEK and TEK Keys for policies distributed earlier*Jun 28 23:46:52.591: ISAKMP:(1003): sending packet to 11.11.11.11 my_port 848 peer_port 848 (R) GDOI_IDLE*Jun 28 23:46:52.595: ISAKMP:(1003):Sending an IKE IPv4 Packet.*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 Remaining Lifetime : 0 secs IPSec SA Number : 1 IPSec SA Rekey Lifetime: 3600 secs Profile Name : GDOI_PROFILE Replay method : Time Based Replay Window Size : 5 SA Rekey Remaining Lifetime : 508 secs ACL Configured : access-list ACL Group Server list : LocalThis 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 gdoiGROUP INFORMATION Group Name : GDOI_GROUP Group Identity : 123 Rekeys received : 1 IPSec SA Direction : Both 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.255KEK POLICY: Rekey Transport Type : Unicast Lifetime (secs) : 83284 Encrypt Algorithm : 3DES Key Size : 192 Sig Hash Algorithm : HMAC_AUTH_SHA Sig Key Length (bits) : 1024TEK 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 intervalThe 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 ksTotal group members registered to this box: 3Key Server Information For Group GDOI_GROUP: Group Name : GDOI_GROUP Group Identity : 123 Group Members : 3 IPSec SA Direction : Both ACL Configured: access-list ACLThe show crypto gdoi gm command displays GDOI information on GM.
show crypto gdoi gm on GM-1
GM-1# show crypto gdoi gmGroup Member Information For Group GDOI_GROUP: IPSec SA Direction : Both ACL Received From KS : gdoi_group_GDOI_GROUP_temp_acl Last rekey seq num : 1 Re-register Remaining time : 2593 secs Retry Timer :NOT RUNNINGRekey 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.043: ISAKMP:(0):Sending an IKE IPv4 Packet.*Jun 28 23:59:36.191: ISAKMP:(0): sending packet to my_port 848 peer_port 848 (I) GDOI_REKEY*Jun 28 23:59:36.191: ISAKMP:(0):Sending an IKE IPv4 Packet.*Jun 28 23:59:36.351: ISAKMP:(0): sending packet to my_port 848 peer_port 848 (I) GDOI_REKEY*Jun 28 23:59:36.355: ISAKMP:(0):Sending an IKE IPv4 Packet.*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*Jun 28 23:59:36.971: ISAKMP (0): received packet from 11.11.11.11 dport 848 sport 848 Global (I) GDOI_REKEY*Jun 28 23:59:37.059: ISAKMP (0): received packet from 22.22.22.22 dport 848 sport 848 Global (I) GDOI_REKEYThe 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*Jun 28 23:59:45.595: GDOI:REKEY:(0):Received Rekey Cookies matched our 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*Jun 28 23:59:45.607: GDOI:REKEY:(0):Received Rekey Cookies matched our 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*Jun 28 23:59:45.623: GDOI:REKEY:(0):Received Rekey Cookies matched our 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.647: GDOI:INFRA:(1004):processing GDOI Key Packet, message_id 1694900728*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.667: GDOI:INFRA:(1004):Completed KeyPkt Processing*Jun 28 23:59:45.671: GDOI:INFRA:(1004):processing GDOI Key Packet, message_id 1694900728*Jun 28 23:59:45.671: GDOI:INFRA:(1004): Processing KEK KD*Jun 28 23:59:45.675: GDOI:INFRA:(1004):Completed KeyPkt Processing*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 : 16What'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 from2.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*Jun 28 23:59:45.743: GDOI:REKEY:(0):Received Rekey Cookies matched our 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*Jun 28 23:59:45.751: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: ipsec identities protocol : 0 src port : 0 dst port : 0*Jun 28 23:59:45.755: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: 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*Jun 28 23:59:45.759: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: 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*Jun 28 23:59:45.775: GDOI:REKEY:(0):Received Rekey Cookies matched our Group Info*Jun 28 23:59:45.779: 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*Jun 28 23:59:45.783: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: ipsec identities protocol : 0 src port : 0 dst port : 0*Jun 28 23:59:45.787: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: 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*Jun 28 23:59:45.791: GDOI:INFRA:(GDOI_GROUP:0):Crypto gdoi exact match: 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 KSFurther reading:
Page updated
Google Sites
Report abuse