[RFC PATCH] Increase GTK/PTK rekey retries

[Jouni Malinen]

On Mon, Dec 19, 2016 at 05:06:11PM +0100, Günther Kelleter wrote:
> We are experiencing frequent deauthentication of Android stations due to
> GTK rekey failures: EAPOL frames are not answered during the total timeout
> peroid of 3.5 s. Increase retries to cover a bigger timeout period.

That's quite unfortunate, but I'm not going to accept this change to
hardcode a larger dot11RSNAConfig*UpdateCount value. We'll need to find
a better way of addressing this.

> IMHO a proper fix for this issue would be to implement retransmit timeouts as
> mandated by 802.11-2012 Ch. 11.6.7.4:
> "The retransmit timeout value shall be 100 ms for the first timeout, half the
> listen interval for the second timeout, and the listen interval for subsequent
> timeouts. If there is no listen interval or the listen interval is zero, then
> 100 ms shall be used for all timeout values."

The parts here about 100 ms are not practical in real world and because
of that, I have not implement this exact behavior. Nor do I think we
should implement that either. However, it would be reasonable to think
about the listen interval part here while ignoring the 100 ms part.

> But 802.11 doesn't give any hints about the number of retries in
> dot11RSNAConfigGroupUpdateCount.

It does.. That's a configurable MIB variable with range of 1..4294967295
and default value of 3. hostapd is currently hardcoded to 4 because of
this type of timeout issues. If someone wants to increase this above 4,
I'd like to do that as a properly configurable parameter rather than
hardcoded value since increasing the rekeying times unconditionally can
be harmful for some use cases.

> In our test case with Galaxy S6 the station announces a listen interval of
> 10 beacon periods corresponding in 1.024 seconds. But it remains in power
> save mode for about 5 seconds.

That's not really nice behavior if that does indeed mean it fails to
receive a unicast EAPOL-Key frames for five seconds when connected to an
AP using 100 TU beacon interval. That would sound like something that
would constantly fail the default IEEE 802.11 behavior for group
rekeying..

> Isn't that a bug in Android which violates 802.11-2012 Ch. 10.2.1.8.a?
> "The STA shall wake up early enough to be able to receive the first Beacon
> frame scheduled for transmission at the time corresponding to the last TBTT
> plus the ListenInterval."

This is driver specific functionality, so I would not consider it as a
generic Android issue, but anyway, this is an area where various vendors
do various things to save power regardless of what the standard says..
So yes, it might be noncompliant with the standard, but a compromise may
be needed here.. It would be nicer to advertise a larger Listen Interval
value in that case, though. Some APs might reject the association if a
larger value is used there which may make it less convenient for vendors
to advertise the accurate value.

> This Android bug would still require dot11RSNAConfigGroupUpdateCount to be at
> least 6 for successful GTK rekeying.

That or using longer retry time based on not receiving an ACK from the
STA. As noted above, I don't really want to increase the hardcoded value
for all cases, but conditionally allowing larger number of TX tries or
longer wait for a response when the STA does not ACK any of the frames
could be a reasonable compromise to address the case where a STA is
indeed in sleep and not receive any of the frames. If the frame remains
in local TX queue waiting for the STA to wake up, there would be no TX
status events at all. If the driver is known to support TX status events
for EAPOL frames, local timeout could be adjusted based on not having
received the event to detect this case.

> Obviously the same applies to PTK rekeying, where 802.11 mandates the same
> interval specification.

PTK rekeying has somewhat different requirements since it does not block
key changes for every other STA in the BSS. As such, it might be easier
to justify larger number of retries or longer timeouts there.

> Is there a reason that hostapd does not implement retransmit timeouts as
> mandated by 802.11?

Yes, the standard behavior is not ideal in real world and does not take
into account the possibility of using TX status (ACK frames) to adjust
behavior.

-- 
Jouni Malinen                                            PGP id EFC895FA