[Swan-dev] Proposal: Do not retransmit IKEv1 reply for initial responder states

[Paul Wouters]

Hi,

Unlike IKEv2, in IKEv1 both ends retransmit. This leads to an
amplification attack, since a single spoofed packet can trigger
multiple retransmited packets. I believe the default case for
libreswan would cause 6 packets to be sent. The initial packet,
and retransmist at 0.5s, 1s, 2s, 4s, 8s and 16s, at which point
we delete the failed state.

I propose that the initial responder states for main mode and aggressive
mode no longer retransmits, leaving retransmit responsibility for the
initial packet at the initiator:


diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c
index 67734df..329aac8 100644
--- a/programs/pluto/ikev1.c
+++ b/programs/pluto/ikev1.c
@@ -245,7 +245,7 @@ static const struct state_microcode v1_state_microcode_table[] = {
  	{ STATE_MAIN_R0, STATE_MAIN_R1,
  	  SMF_ALL_AUTH | SMF_REPLY,
  	  P(SA), P(VID) | P(CR), PT(NONE),
-	  EVENT_v1_RETRANSMIT, main_inI1_outR1 },
+	  EVENT_NULL, main_inI1_outR1 },

  	/* STATE_MAIN_I1: R1 --> I2
  	 * HDR, SA --> auth dependent
@@ -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


I don't think this would break any legitimate IKEv1 clients, since the
initiator also will retransmit its initial packet.

It would prevent libreswan from being abused to amplify an attack based
on spoofed IKEv1 packets.

Paul