DGNum/hostapd
6
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

mka: Fix re-establishment by resetting MI

Browse source 
The key server may be removed due to the ingress packets delay. In this
situation, the endpoint of the key server may not be aware of this
participant who has removed the key server from the peer list. Because
the egress traffic is normal, the key server will not remove this
participant from the peer list of the key server. So in the next MKA
message, the key server will not dispatch a new SAK to this participant.
And this participant cannot be aware of that that is a new round of
communication so that it will not update its MI at re-adding the key
server to its peer list. So we need to update MI to avoid the failure of
re-establishment MKA session.

Signed-off-by: Ze Gan <ganze718@gmail.com>
This commit is contained in:
Ze Gan 2023-04-24 00:50:09 +08:00 • committed by Jouni Malinen
parent 61f0e19b86
commit 750403f3ad
1 changed files with 22 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
src/pae/ieee802_1x_kay.c
View file

@ -2562,6 +2562,7 @@ static void ieee802_1x_participant_timer(void *eloop_ctx, void *timeout_ctx)
struct ieee802_1x_kay_peer *peer, *pre_peer;
time_t now = time(NULL);
bool lp_changed;
bool key_server_removed;
struct receive_sc *rxsc, *pre_rxsc;
struct transmit_sa *txsa, *pre_txsa;
@ -2586,6 +2587,7 @@ static void ieee802_1x_participant_timer(void *eloop_ctx, void *timeout_ctx)
}
lp_changed = false;
key_server_removed = false;
dl_list_for_each_safe(peer, pre_peer, &participant->live_peers,
struct ieee802_1x_kay_peer, list) {
if (now > peer->expire) {
@ -2601,12 +2603,32 @@ static void ieee802_1x_participant_timer(void *eloop_ctx, void *timeout_ctx)
participant, rxsc);
}
}
key_server_removed |= peer->is_key_server;
dl_list_del(&peer->list);
os_free(peer);
lp_changed = true;
}
}
/* The key server may be removed due to the ingress packets delay.
* In this situation, the endpoint of the key server may not be aware
* of this participant who has removed the key server from the peer
* list. Because the egress traffic is normal, the key server will not
* remove this participant from the peer list of the key server. So in
* the next MKA message, the key server will not dispatch a new SAK to
* this participant. And this participant cannot be aware that that is
* a new round of communication so it will not update its MI at
* re-adding the key server to its peer list. So we need to update MI
* to avoid the failure of the re-establishment MKA session. */
if (key_server_removed) {
if (!reset_participant_mi(participant))
wpa_printf(MSG_WARNING,
"KaY: Could not update mi on key server removal");
else
wpa_printf(MSG_DEBUG,
"KaY: Update mi on key server removal");
}
if (lp_changed) {
if (dl_list_empty(&participant->live_peers)) {
participant->advised_desired = false;