[Swan-dev] Proposal: Do not retransmit IKEv1 reply for initial responder states
Paul Wouters
paul at nohats.ca
Sun Mar 27 17:48:25 UTC 2016
On Sun, 13 Mar 2016, Paul Wouters wrote:
I've applied this suggestion, since no one objected. But an interesting
item was raised by Valerie for this part:
> @@ -394,7 +394,7 @@ static const struct state_microcode
> v1_state_microcode_table[] = {
> { STATE_AGGR_R0, STATE_AGGR_R1,
> SMF_PSK_AUTH | SMF_DS_AUTH | SMF_REPLY,
> P(SA) | P(KE) | P(NONCE) | P(ID), P(VID) | P(NATD_RFC), PT(NONE),
> - EVENT_v1_RETRANSMIT, aggr_inI1_outR1 },
> + EVENT_NULL, aggr_inI1_outR1 },
>
> /* STATE_AGGR_I1:
> * SMF_PSK_AUTH: HDR, SA, KE, Nr, IDir, HASH_R
Aggressive mode is really broken in that retransmission of the responder
can be needed. In this case:
initiator AggrOutI1 ----->
<----- AggrInI1OutR1 responder
initiator AggrOutI2 -----X [dropped packet]
Since the initiator is now "done", it won't retransmit. But the
responder is not "done" as it is missing the last packet. Before
this patch, it would retansmit AggrInI1OutR1 but that's exactly
what we want to avoid as that could be a spoofed packet.
If the initiator has enabled DPD, the connection will die/restart but
that might much later on (eg 30 seconds later)
Alternatively, we could add some code that checks on the initiator side
for incoming traffic after a second or two, and if it does not see that
to retransmit the AggrOutI2 packet.
Is this worth fixing or not?
Paul
More information about the Swan-dev
mailing list