[Swan-dev] retry/re-transmit controls

[Paul Wouters]

On Wed, 15 Nov 2017, Andrew Cagney wrote:

> - because of a post-increment, the delay (r_interval * 2^^nr_retransmits) grows:
> 
>       r_interval, r_interval, r_interval*2, r_interval*4, ...
> 
>   I think this is a bug; it should be:
> 
>       r_interval, r_interval*2, r_interval*4, ...

I think that was done on purpose to get (per default): 0.5, 0.5, 1, 2, 4

> - pluto can also auto-reply receives a "duplicate"; and that is sometimes capped:
> 
>     - IKEv2 normally unlimited; and plays no part in in the retransmit code; but ...

Because IKEv2 is always one request, one response. responder never
retransmits on a timer.

>     - IKEv2 invalid KE; limited to MAXIMUM_INVALID_KE_RETRANS 3, because it is also re-transmitting

This was mostly to avoid pingponging the IKE_INIT between a (malicious/bad) server, eg:

 	DHx ?	---->
 		<----  Try DHy instead
 	DHy ?	---->
 		<----  Try DHx instead
 	?

>     - IKEv1 limited to MAXIMUM_v1_ACCEPTED_DUPLICATES 2 which seems very low
> 
>   I suspect the IKEv1 case should be unlimited (like IKEv1) when re-transmits are not happening.  For instance when in MAIN_R1.

Agreed. We should always reply in response to a packet (unless our timer
exceeds and we delete the state)

> - since duplicate replies are counted as re-transmits they feed into the re-transmit delay calculation - r_interval * 2^^nr_retransmits - the effect is two fold:
> 
>     - future re-transmits are more spaced out
> 
>     - the total time is shortened (because of how the timeout test is performed) and can (I suspect) result in waiting for less than r_timeout?
> 
>   puzzling; I suspect the second effect is unintended; and can be fixed by computing timeout properly.

Yes.

Paul