GETVPN TBAR - pseudotime is not synced between Key Servers

[n.oneill]

I have been playing with GETVPN in VIRL and I have noticed there is pretty bad clock skew in the Virtual Environment which is not the problem.  What I have noticed is that pseudotime is not synced between Key Servers and this could lead to TBAR (Time Based Anti Replay) issues.  I have 2x Key Servers configured with COOP KS and 2x Group Members.  I have enabled dataplane recovery (GETVPN Resiliency GM - Error Detection) on the network.  Each GM registers with different Key Servers so GM1 registers with KS1 (the Primary KS) and GM2 registers with KS2.  When pseudotime drift is larger than the Anti Replay window the GM attempts to re-register but because the pseudotime on each KS has also drifted each GM is syncing to a different pseudotime source so it never recovers until a rekey is sent by the Primary KS.  I don't know if there is a reason for it or it was just an oversight but it would make sense if all Key Servers synced pseudotime to the primary as part of the COOP KS protocol creating a single source of truth.

[Rahul Govindan · Accepted solution]

The secondary KS should update its own pseudotime when it receives the COOP ANN message that is not in line with the acceptable window. Do you see it syncing and going off sync from time to time?

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_getvpn/configuration/xe-3s/sec-get-vpn-xe-3s-book/sec-get-vpn.html

If this is not happening, you might need to check the ANN messages between the KS to see if there are drops there. Some of these messages can get pretty large so there could fragmentation or interface buffers dropping it. I have not used GETVPN in VIRL so can't speak of its behavior.

[n.oneill]

Thanks Rahul

I read about Cooperative Key Server Announcement Messages in the link that you posted. 

"Antireplay functionalities and incorporated Cooperative announcement messages are supported. The primary key server updates the pseudotime value, sending it to all secondary key servers in the group. The secondary key servers should synchronize their SAR clocks to this updated value."

My simulation has been terminated since starting this thread.  I have restarted it and I will monitor time sync between the Key Servers to see if it goes out of sync again.  It should start to happen with a day as the drift in VIRL is quite bad.

Edit: Testing complete

I set up debugs and  a python script to monitor psuedotimes on both Key Servers and everything working as intended (as you pointed out).  Not sure what broke my original lab.

.Feb  4 08:25:54.587: GDOI:KS REPLAY:EVT:(GETVPN-GDOI:0:39097):Update ks pseudotime, new time is 78500.56 (secs)
.Feb  4 08:26:14.346: GDOI:KS REPLAY:EVT:(GETVPN-GDOI:0:39097):Update ks pseudotime, new time is 78520.57 (secs)
.Feb  4 08:26:34.023: GDOI:KS REPLAY:EVT:(GETVPN-GDOI:0:39097):Update ks pseudotime, new time is 78540.58 (secs)
.Feb  4 08:26:53.377: GDOI:KS REPLAY:EVT:(GETVPN-GDOI:0:39097):Update ks pseudotime, new time is 78560.59 (secs)
.Feb  4 08:27:13.230: GDOI:KS REPLAY:EVT:(GETVPN-GDOI:0:39097):Update ks pseudotime, new time is 78580.60 (secs)

ANN (announcement message) sent every 20 seconds from the Primary to all Secondaries.  This debug output was recorded on the Secondary.

[Rahul Govindan]

Awesome! Thanks for reverting back with your testing results.