[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