[Swan-dev] problem from IRC: confusing message and action of lost final packet

Paul Wouters paul at nohats.ca
Fri Sep 28 16:03:15 UTC 2018

On Fri, 28 Sep 2018, Andrew Cagney wrote:

> with the above two applied, here's what's going wrong (other than it's
> IKEv1 and we're stuffed)?
> - since the IKEv1 initiator is in STATE_MAIN_I4 the IKE SA has been
> established - any message from an earlier part of the exchange should
> be detected and dropped

Except R3 I guess, if receiving that we need to retransmit our last

> In IKEv2, that's easy as the Message ID is a counter.
> What about IKEv1?  During these exchange the message ID seems to always be zero.

    The message ID in the ISAKMP header identifies a Quick Mode in
    progress for a particular ISAKMP SA which itself is identified by the
    cookies in the ISAKMP header.

So I assume that in Main/Aggr Mode it is indeed 0 ?

> - since the IKEv1 IKE SA is established (almost) all packets should be
> encrypted and have integrity, yet this packet fails that so why on
> earth is libreswan sending out a notification

It seems it failed to detect it as a retransmit, and started processing
the packet as if it was a fresh never before received packet?

> In IKEv2 this is easy, find the SK payload and decrypt/verify as a single step.
> What about IKEv1?  As best I can tell the process is to decrypt the
> packet and then parse the resulting white noise looking for a HASH
> et.al. payload to use as verification - until all that is done nothing
> can be trusted and everything should have been dropped.
> So by pushing 'ikev1 retransmits: only save the received packet when
> responding' I exposed the above two failings.  Reverting it wouldn't
> be sufficient.  It would likely need some special state magic to
> detect if/when that last outgoing packet should be re-transmitted; and
> would still leave libreswan exposed to the above.

If we are established and the message ID is 0, then we could retransmit
the last main/aggressive packet? Once we receive a Quick Mode packet
response (with non-zero message id) then we never need to retransmit a
msg id 0 packet anymore.


More information about the Swan-dev mailing list