GET VPN: Rekey using Multicast

GET VPN: Rekey using Multicast

When a Group Member (GM) registers with a Key Server (KS) in GET VPN, the KS pushes two IKE SAs - GDOI_IDLE and GDOI_REKEY to the GMs. GDOI_IDLE is used to push initial IPSec SAs and GDOI_REKEY is used to download new group IPSec SAs (rekey SAs). The advantage of enabling GDOI rekey is that the GMs do not need to re-register with the KS every time the group IPSec SA lifetime expires. New group IPSec SAs are downloaded even before the existing IPSec SAs expire.

The KS can either unicast these rekey SAs to all GMs or just multicast to a pre-configured multicast group address. Using multicast transport greatly enhances the usability and is very efficient in medium-to-large networks.

However, using multicast transport requires entire network to be multicast enabled. This is could be an issue when the part of the network belongs to the Service Provider. Even with GDOI-based DMVPN, it is not possible as the Customer routers are directly connected to the Service Provider routers.

The best way is to enable multicasting on the mGRE tunnel itself. This article demonstrates the approach of GET VPN rekeying using multicast over DMVPN network. The underlying Service Provider network could be either IP or MPLS VPN; it merely provides connectivity between Customer sites.

There are 3 considerations for this to work-

1. Tunnel interface(s) must support Multicast. This is required as tunnel interfaces will be carrying multicast rekey SAs across DMVPN network. This allows us to have multicast-free SP network.

2. Tunnel interface(s) must join multicast group for which rekey SAs are sent. This is required, otherwise, rekey SAs will not be received if no interfaces join the IGMP group. This can be achieved using ip igmp join-group <multicast-address> command under the tunnel interface.

3. On all Spoke routers (if the KS is directly connected to the Hub), the multicast source (KS) must be reachable through the tunnel interface. This is required as all Spoke routers will do Reverse Path Forwarding check when a multicast packet is received to see if the multicast packets are received on the correct interface or not. By default, the multicast source address (KS) will be reachable through the physical interface rather than the tunnel interface, and hence, RPF check will fail. To overcome this, a static multicast entry is created to trick the router into thinking that the source address is reachable through the tunnel interface. This can be done using ip mroute command.

Sample Scenario

This scenario demonstrates rekey using multicast. RP election is based on Cisco Auto-RP, however, only KS is configured as the Candidate-RP. The KS is also the Mapping Agent (MA). The Mapping Agent is responsible to send Group-to-RP mappings to the PIM routers.

It is very essential that the MA is located at the Hub site otherwise the Cisco-RP-Discovery messages would not be sent across to other Spoke routers if the MA was located behind a Spoke router, for example.

KS Configuration

The KS configuration is as follows:

KS Configuration

ip multicast-routing

interface Loopback 0

 ip address 1.1.1.1 255.255.255.255

 ip pim sparse-mode

interface Fastethernet 1/0

 description Connection to Central router

 ip address 10.1.1.2 255.255.255.0

 ip pim sparse-mode

crypto key generate rsa general-keys label GDOI_KEYS modulus 1024 exportable

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 12.12.12.12     ! GM-2 router

crypto ipsec transform-set GDOI_TS esp-3des esp-md5-hmac

crypto ipsec profile GDOI_PROFILE

 set transform-set GDOI_TS

crypto gdoi group GDOI_GROUP

 identity number 123

 server local

  rekey address ipv4 MULTICAST_REKEY            ! Indicates multicast address to which Rekey SAs must be sent

  rekey lifetime seconds 300                    ! Rekeys will be sent after 300 seconds

  rekey retransmit 60 number 2

  rekey authentication mypubkey rsa GDOI_KEYS

  sa ipsec 1

   profile GDOI_PROFILE

   match address ipv4 ACL

   replay time window-size 5

  address ipv4 1.1.1.1

ip access-list extended MULTICAST_REKEY

 remark Multicast address to which Rekey SAs will be sent

 permit ip any host 239.10.10.1

ip access-list extended ACL

 remark Interesting traffic to be encrypted

 permit gre any any

ip pim send-rp-announce Loopback 0 scope 10 group-list 1    ! Advertise this router as Candidate-RP for the range defined in ACL 1

ip pim send-rp-discovery Loopback 0 scope 10        ! Indicates this router is the RP Mapping Agent

access-list 1 permit 239.0.0.0 0.255.255.255

DMVPN Configuration

The Central router is the Hub for DMVPN network. The configuration is as below:

Central Router Configuration

ip multicast-routing

interface Loopback 0

 ip address 2.2.2.2 255.255.255.255

 ip pim sparse-mode

crypto isakmp policy 10

 authentication pre-share

crypto isakmp key 0 cisco address 1.1.1.1

crypto gdoi group GDOI_GM

 identity number 123

 server address ipv4 1.1.1.1

crypto map DMVPN local-address Loopback 0

crypto map DMVPN 10 gdoi

 set group GDOI_GM

interface Serial 2/0

 ip address 172.17.1.1 255.255.255.0

 crypto map DMVPN

interface Tunnel 10

 ip address 192.168.100.1 255.255.255.0

 tunnel mode gre multipoint

 tunnel source serial 2/0

 tunnel key 123

 ip nhrp map multicast dynamic

 ip nhrp network-id 123

 ip pim dr-priority 100

 ip pim sparse-mode

 ip pim nbma-mode

 ip igmp join-group 239.10.10.1

router eigrp 10

! Routing instance for DMVPN network

 no auto-summary

 network 192.168.1.0

 network 192.168.100.0

Some important commands worth knowing about:

1. ip pim dr-priority <priority-value> : This command sets the priority on the interface connected to multi-access network. As the tunnel is a mGRE interface which is essentially a non-broadcast multi-access network, it is important that the Central router is elected as the DR for the network. The DR is responsible for sending Join/ Prune messages to the RP for the group. The router with the highest priority becomes the DR. By default, the priority is set to 1. In case of a tie, the router with the highest IP address becomes the DR.

2. ip pim nbma-mode : This command allows the router to send packets to only those neighbors that want to receive them on an NBMA network. A router in PIM NBMA mode treats each neighbor as if it were connected to the router through a point-to-point link. The reason this is important is that if a Spoke router sends a Prune message back to the Hub, the Hub router will set the Prune flag for that interface, and so it wont send any multicast packets for the group over that interface. This will cause other Spoke router to not receive any multicast packets for that group either. This command allows the router to track the IP address of each neighbor when a PIM Join message is received from that neighbor. This information allows the router to forward data destined for a multicast group to only those neighbors that have joined that particular group.

The configuration on the GM-1 and GM-2 routers is as below:

GM-1 Router Configuration

ip multicast-routing

interface Loopback 0

 ip address 11.11.11.11 255.255.255.255

 ip pim sparse-mode

crypto isakmp policy 10

 authentication pre-share

crypto isakmp key 0 cisco address 1.1.1.1

crypto gdoi group GDOI_GM

 identity number 123

 server address ipv4 1.1.1.1

crypto map DMVPN local-address Loopback 0

crypto map DMVPN 10 gdoi

 set group GDOI_GM

interface Serial 1/0

 ip address 172.27.1.1 255.255.255.0

 crypto map DMVPN

interface Tunnel 10

 ip address 192.168.100.2 255.255.255.0

 tunnel mode gre multipoint

 tunnel source serial 0/0

 tunnel key 123

 ip nhrp nhs 192.168.100.1

 ip nhrp map 192.168.100.1 172.17.1.1

 ip nhrp map multicast 172.17.1.1

 ip nhrp network-id 123

 ip pim sparse-mode

 ip igmp join-group 239.10.10.1

router eigrp 10

 no auto-summary

 network 192.168.11.0

 network 192.168.100.0

ip mroute 1.1.1.1 255.255.255.255 192.168.100.1

GM-2 Router Configuration

ip multicast-routing

interface Loopback 0

 ip address 12.12.12.12 255.255.255.255

 ip pim sparse-mode

crypto isakmp policy 10

 authentication pre-share

crypto isakmp key 0 cisco address 1.1.1.1

crypto gdoi group GDOI_GM

 identity number 123

 server address ipv4 1.1.1.1

crypto map DMVPN local-address Loopback 0

crypto map DMVPN 10 gdoi

 set group GDOI_GM

interface Serial 1/0

ip address 172.37.1.1 255.255.255.0

 crypto map DMVPN

interface Tunnel 10

 ip address 192.168.100.3 255.255.255.0

 tunnel mode gre multipoint

 tunnel source serial 1/0

 tunnel key 123

 ip nhrp nhs 192.168.100.1

 ip nhrp map 192.168.100.1 172.17.1.1

 ip nhrp map multicast 172.17.1.1

 ip nhrp network-id 123

 ip pim sparse-mode

 ip igmp join-group 239.10.10.1

router eigrp 10

 no auto-summary

 network 192.168.12.0

 network 192.168.100.0

ip mroute 1.1.1.1 255.255.255.255 192.168.100.1

Verification

When the ip mroute 1.1.1.1 255.255.255.255 192.168.100.1 command is not applied to GM-2 router, all the PIM packets received on its Tunnel interface will be dropped due to RPF check failure.

RPF Check Failure

GM-2#

*Jul  7 22:57:13.167: PIM(0): Received RP-Reachable on Tunnel10 from 1.1.1.1

*Jul  7 22:57:13.171: PIM(0): Received RP-Reachable on Tunnel10 from 1.1.1.1

*Jul  7 22:57:13.171:      for group 239.10.10.1

*Jul  7 22:57:13.175: PIM(0): RP not known, or mismatch

GM-2#

*Jul  7 22:57:43.127: PIM(0): Prune Tunnel10/239.10.10.1 from (*, 239.10.10.1) - deleted

*Jul  7 22:57:43.131: PIM(0): Prune Tunnel10/224.0.1.40 from (*, 224.0.1.40) - deleted

GM-2#

*Jul  7 22:58:03.727: PIM(0): Prune Tunnel10/224.0.1.40 from (1.1.1.1/32, 224.0.1.40) - deleted

RP Election

In this case, the KS is configured as the Candidate-RP. So, the KS starts sending out RP-Discovery messages on multicast address 224.0.1.39 to the RP Mapping Agent. Since, it is setup as the RP Mapping Agent as well, it elects the RP based on the available information. The KS becomes the RP for the range 239.0.0.0/8. It starts advertising itself as the RP for the range in RP-Announce messages to multicast address 224.0.1.40 to other PIM routers. All PIM enabled routers receive this Group-to-RP mapping.

Group-to-RP mapping

KS# show ip pim rp mapping

PIM Group-to-RP Mappings

This system is an RP (Auto-RP)

This system is an RP-mapping agent (Loopback0)

Group(s) 239.0.0.0/8

  RP 1.1.1.1 (?), v2v1

    Info source: 1.1.1.1 (?), elected via Auto-RP

         Uptime: 00:06:03, expires: 00:02:54

Central# show ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8

  RP 1.1.1.1 (?), v2v1

    Info source: 1.1.1.1 (?), elected via Auto-RP

         Uptime: 00:00:57, expires: 00:01:58

GM-1# show ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8

  RP 1.1.1.1 (?), v2v1

    Info source: 1.1.1.1 (?), elected via Auto-RP

         Uptime: 00:00:43, expires: 00:02:14

GM-2# show ip pim rp mapping

PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8

  RP 1.1.1.1 (?), v2v1

    Info source: 1.1.1.1 (?), elected via Auto-RP

         Uptime: 00:01:28, expires: 00:02:30

When all GMs register with the KS, they download the KEK and TEK policies using GDOI. The KS is setup as below:

KS Policy

KS# show crypto gdoi

GROUP INFORMATION

    Group Name               : GDOI_GROUP (Multicast)

    Group Identity           : 123

    Group Members            : 3

    IPSec SA Direction       : Both

    Active Group Server      : Local

    Group Rekey Lifetime     : 300 secs

    Group Rekey

        Remaining Lifetime   : 71 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  : 3072 secs

      ACL Configured         : access-list ACL

    Group Server list        : Local

KS# show crypto gdoi ks rekey

Group GDOI_GROUP (Multicast)

    Number of Rekeys sent               : 4

    Number of Rekeys retransmitted      : 8

    KEK rekey lifetime (sec)            : 300

        Remaining lifetime (sec)        : 22

    Retransmit period                   : 60

    Number of retransmissions           : 2

    IPSec SA 1  lifetime (sec)          : 3600

        Remaining lifetime (sec)        : 2123

    Number of registrations after rekey : 0

    Multicast destination address       : 239.10.10.1

All the GMs download this policy and can be displayed as below on Central router:

Policy on Central router

Central# show crypto gdoi

GROUP INFORMATION

    Group Name               : GDOI_GM

    Group Identity           : 123

    Rekeys received          : 0

    IPSec SA Direction       : Both

    Active Group Server      : 1.1.1.1

    Group Server list        : 1.1.1.1

    GM Reregisters in        : 3436 secs

    Rekey Received           : never

    Rekeys received

         Cumulative          : 0

         After registration  : 0

 ACL Downloaded From KS 1.1.1.1:

   access-list  permit gre any any

KEK POLICY:

    Rekey Transport Type     : Multicast

    Lifetime (secs)          : 299

    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:

    IPsec SA:

        spi: 0xF25434BF(4065604799)

        transform: esp-3des esp-md5-hmac

        sa timing:remaining key lifetime (sec): (3594)

        Anti-Replay(Time Based) : 5 sec interval

Multicast Rekeying

When the rekey lifetime is about to expire, the KS sends new rekey messages. In this case, it will be sent to multicast address 239.10.10.1 configured on the KS router. Since the GMs are tuned to this multicast address, they will also receive this message via Tunnel 10.

Multicast Rekey message

KS#

*Jul  7 23:23:36.355: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey for group GDOI_GROUP from address 1.1.1.1 to 239.10.10.1  with seq # 1

GM-1# debug crypto gdoi ks rekey

*Jul  7 23:23:36.975: GDOI:INFRA:(GDOI_GM:1004):Received Rekey Message!

*Jul  7 23:23:37.019: GDOI:INFRA:(GDOI_GM:1004):Signature Valid!

*Jul  7 23:23:37.023: GDOI:INFRA:(1004):received payload type 18

*Jul  7 23:23:37.023: GDOI:INFRA:(1004):processing GDOI Seq Payload, message_id  0

*Jul  7 23:23:37.027: GDOI:INFRA:(1004):Completed SEQ Processing for seq 1

*Jul  7 23:23:37.027: GDOI:INFRA:(1004):processing GDOI SA Payload, message ID + 0

*Jul  7 23:23:37.035: GDOI:INFRA:(1004):processing GDOI SA KEK Payload

*Jul  7 23:23:37.039: GDOI:INFRA:(0): kek_sa->src 1.1.1.1 kek_sa->dst 239.10.10.1

*Jul  7 23:23:37.043: GDOI:INFRA:(0):    KEK_ALGORITHM 5

*Jul  7 23:23:37.043: GDOI:INFRA:(0):    KEY_LENGTH 192

*Jul  7 23:23:37.047: GDOI:INFRA:(0):    KEY_LIFETIME 299

*Jul  7 23:23:37.047: GDOI:INFRA:(0):    SIG_HASH_ALG 2

*Jul  7 23:23:37.051: GDOI:INFRA:(0):    SIG_ALG 1

*Jul  7 23:23:37.051: GDOI:INFRA:(0):    SIG_KEY_LEN 1024

*Jul  7 23:23:37.055: GDOI:INFRA:(0): New Kek is received, reset last_seq_num to 0

*Jul  7 23:23:37.055: GDOI:INFRA:(0): Completed KEK Processing

*Jul  7 23:23:37.063: GDOI:INFRA:(1004):processing GDOI Private Attribute Payload

*Jul  7 23:23:37.063: GDOI:INFRA:(1004): Completed GDOI Attribute Processing

*Jul  7 23:23:37.067: GDOI:INFRA:(GDOI_GM:1004):Completed processing 1 GDOI SA TEK Payloads

*Jul  7 23:23:37.067: GDOI:INFRA:(1004):received payload type 17

*Jul  7 23:23:37.071: GDOI:INFRA:(1004):processing GDOI KD Payload, message_id  0

*Jul  7 23:23:37.075: GDOI:INFRA:(1004):processing GDOI Key Packet, message_id  1694874040

*Jul  7 23:23:37.075: GDOI:INFRA:(1004):processing TEK KD: spi is 0xDE2B7089

*Jul  7 23:23:37.079: GDOI:INFRA:(1004):                   lifetime is 3300 seconds

*Jul  7 23:23:37.079: GDOI:INFRA:(1004):TEK Integrity Key 16 bytes

*Jul  7 23:23:37.087: GDOI:INFRA:(1004):Completed KeyPkt Processing

*Jul  7 23:23:37.091: GDOI:INFRA:(1004):processing GDOI Key Packet, message_id  1694874040

*Jul  7 23:23:37.091: GDOI:INFRA:(1004): Processing KEK KD

*Jul  7 23:23:37.095: GDOI:INFRA:(1004):KEK Alg Key 32 bytes

*Jul  7 23:23:37.095: GDOI:INFRA:(1004):KEK Sig Key 162 bytes

*Jul  7 23:23:37.107: GDOI:INFRA:(1004):Completed KeyPkt Processing

*Jul  7 23:23:37.107: GDOI:INFRA:(1004):Multicast Rekey from KS 2

*Jul  7 23:23:37.115: %GDOI-5-GM_RECV_REKEY: Received Rekey for group GDOI_GM from 1.1.1.1 to 239.10.10.1 with seq # 1

*Jul  7 23:23:37.119: GDOI:INFRA:(GDOI_GM:1004): using SPI 8D8385D6C8FF4A10

*Jul  7 23:23:37.151: GDOI:INFRA:(GDOI_GM:0):crypto exact match ace number : 1