In questo documento vengono descritte le modifiche al comportamento della chiave di crittografia GETVPN (KEK). Include Cisco IOS® versione 15.2(1)T) e Cisco IOS-XE 3.5 versione 15.2(1)S). Questo documento spiega i cambiamenti di comportamento e i potenziali problemi di interoperabilità causati.
Contributo di Wen Zhang, Cisco TAC Engineer.
Nelle versioni precedenti a Cisco IOS versione 15.2(1)T, la chiave viene inviata dal server chiavi (KS) quando scade la chiave corrente. Il membro del gruppo (GM) non gestisce un timer per tenere traccia della durata residua del KEK. La chiave KEK corrente viene sostituita da una nuova chiave KEK solo quando si riceve una nuova chiave KEK. Se il GM non riceve una nuova chiave KEK alla scadenza prevista del KEK, non attiva una nuova registrazione nel KS e manterrà la chiave esistente senza lasciarla scadere. Ciò potrebbe determinare l'utilizzo del KEK dopo la sua durata configurata. Inoltre, come effetto collaterale, non esiste alcun comando sull'oggetto GM che mostri la durata residua del KEK.
Il nuovo comportamento della chiave KEK include due modifiche:
Con il nuovo comportamento di reimpostazione delle chiavi, il KS avvia una reimpostazione delle chiavi KEK prima della scadenza corrente in base a questa formula.
In base a questo comportamento, un KS inizia a reimpostare la chiave di un KEK almeno 200 secondi prima della scadenza del KEK corrente. Dopo l'invio della nuova chiave, il KS inizia a utilizzare la nuova chiave per tutte le successive richiavi TEK/KEK.
Il nuovo comportamento GM comprende due modifiche:
Oltre alle modifiche funzionali, vengono modificati anche gli output del comando show GM per visualizzare la durata rimanente del KEK.
GM#show crypto gdoi
GROUP INFORMATION
Group Name : G1
Group Identity : 3333
Crypto Path : ipv4
Key Management Path : ipv4
Rekeys received : 0
IPSec SA Direction : Both
Group Server list : 10.1.11.2
Group member : 10.1.13.2 vrf: None
Version : 1.0.4
Registration status : Registered
Registered with : 10.1.11.2
Reregisters in : 81 sec <=== Reregistration due to TEK or
KEK, whichever comes first
Succeeded registration: 1
Attempted registration: 1
Last rekey from : 0.0.0.0
Last rekey seq num : 0
Unicast rekey received: 0
Rekey ACKs sent : 0
Rekey Received : never
allowable rekey cipher: any
allowable rekey hash : any
allowable transformtag: any ESP
Rekeys cumulative
Total received : 0
After latest register : 0
Rekey Acks sents : 0
ACL Downloaded From KS 10.1.11.2:
access-list deny ospf any any
access-list deny eigrp any any
access-list deny udp any port = 848 any port = 848
access-list deny icmp any any
access-list permit ip any any
KEK POLICY:
Rekey Transport Type : Unicast
Lifetime (secs) : 56 <=== Running timer for remaining KEK
lifetime
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: 0xD835DB99(3627408281)
transform: esp-3des esp-sha-hmac
sa timing:remaining key lifetime (sec): (2228)
Anti-Replay(Time Based) : 10 sec interval
Con questa modifica del comportamento di reimpostazione delle chiavi KEK, è necessario considerare il problema di interoperabilità del codice quando KS e GM potrebbero non eseguire entrambe le versioni IOS che hanno questa modifica.
Nel caso in cui il GM esegua il codice precedente e il KS esegua quello più recente, il KS invia la chiave di rigenerazione KEK prima della scadenza del KEK, ma non vi sono altri impatti funzionali degni di nota. Tuttavia, se un GM che esegue il codice più recente si registra con un KS che esegue il codice meno recente, il GM potrebbe subire due registrazioni GDOI (Group Domain of Interpretation) per ricevere la nuova chiave KEK per ciclo di rigenerazione chiavi KEK. Una sequenza di eventi si verifica quando:
%GDOI-4-GM_RE_REGISTER: The IPSec SA created for group G1 may
have expired/been cleared, or didn't go through. Re-register to KS. %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.11.2 for
group G1 using address 10.1.13.2 %GDOI-5-GM_REKEY_TRANS_2_UNI: Group G1 transitioned to Unicast Rekey. %GDOI-5-SA_KEK_UPDATED: SA KEK was updated %GDOI-5-SA_TEK_UPDATED: SA TEK was updated %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.11.2 complete
for group G1 using address 10.1.13.2 %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of
Reg/Rekey policies from KS 10.1.11.2 for group G1 & gm identity 10.1.13.2
%GDOI-5-GM_DELETE_EXPIRED_KEK: KEK expired for group G1 and was deleted
%GDOI-4-GM_RE_REGISTER: The IPSec SA created for group G1 may have expired/been cleared, or didn't go through. Re-register to KS. %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.11.2 for
group G1 using address 10.1.13.2 %GDOI-5-GM_REKEY_TRANS_2_UNI: Group G1 transitioned to Unicast Rekey. %GDOI-5-SA_KEK_UPDATED: SA KEK was updated %GDOI-5-SA_TEK_UPDATED: SA TEK was updated %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.11.2 complete for
group G1 using address 10.1.13.2 %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of
Reg/Rekey policies from KS 10.1.11.2 for group G1 & gm identity
10.1.13.2
In un'implementazione GETVPN, se uno dei codici Cisco IOS GM è stato aggiornato a una delle versioni con il nuovo comportamento di reimpostazione delle chiavi KEK, Cisco consiglia di aggiornare anche il codice KS per evitare il problema di interoperabilità.