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

[D. Hugh Redelmeier]

<mcp> since libreswan 3.26 + 83e33a69b27f6c5d5f4aff2fc94a1357d5126ed1 I 
get these syslog messages very often: 
http://paste.debian.net/hidden/a99f6aa9/ - that's annoying ;)

<DHR-x> I've just pushed fa004e7d4b83fbeaa8d0f6d8430a96aed97a97b9 
to log the state name

<mcp> DHR-x, LetoTo, LetoThinkpad: message ignored because it contains a 
payload type (ISAKMP_NEXT_HASH) unexpected by state STATE_QUICK_R2

<mcp> DHR-x, LetoTo, LetoThinkpad: message ignored because it contains a 
payload type (ISAKMP_NEXT_ID) unexpected by state STATE_MAIN_I4

<mcp> with fa004e7d4b83fbeaa8d0f6d8430a96aed97a97b9 applied

<DHR-x> STATE_QUICK_R2 is after responder has negotiated an IPSec SA.  So 
no messages are expected.  But perhaps your side is retransmitting (due to 
loss of packet).

<DHR-x> This should be detected and dealt with.  But I think someone 
recently hacked on the previous-received-packet-retention code and may 
have broken this.  Andrew?

<DHR-x> STATE_MAIN_I4 is a similar situation, but for Main Mode 
(negotiating an IKE SA).

<DHR-x> Cagney?

<cagney_> DHR-x, ikev2?

[no longer IRC]

The failure is not just a confusing message.  Pluto also sends a
complaining notification to its peer.  The correct action is to
- discard the repeated inbound IKE packet
- take it as a trigger to resend the last outbound IKE packet

Cagney:

No. STATE_MAIN* and STATE_QUICK* are IKEv1

Did you not delete the retained packets in these states?  This is my
vague recollection.  Also that I questioned whether this would cause
problems.

Of course it could be that:

- my recollections are wrong

- the cause of these problems is elsewhere