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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
