Created attachment 916986 [details]
Description of problem:
RFC 4306 Section 2.21:
If a node receives a message on UDP port 500 or 4500 outside the
context of an IKE_SA known to it (and not a request to start one), it
may be the result of a recent crash of the node. If the message is
marked as a response, the node MAY audit the suspicious event but MUST
Version-Release number of selected component (if applicable):
Steps to Reproduce:
|<-------------------| IKE_SA_INIT request (HDR, SAi1, KEi, Ni)
| | (Judgement #1)
|---------X | IKE_SA_INIT Response (HDR, SAr1, KEr, Nr)
| | (Packet #1)
Packet #1 See Common Packet #1
Response bit is set to one.
Part A (BASIC)
1. TN starts to negotiate with NUT by sending IKE_SA_INIT request whose Response bit is
set to one.
2. Observe the messages transmitted on Link A.
The NUT responds an IKE_SA_INIT response to an IKE_SA_INIT request from the TN1.
The NUT never responds with an IKE_SA_INIT response to an IKE_SA_INIT request from the TN1.
There was a logic bug in version before libreswan-3.10 that could cause responding to a packet with the Response flag set. Is it possible to re-run this test against libreswan-3.10-3 ?
(In reply to Paul Wouters from comment #1)
> There was a logic bug in version before libreswan-3.10 that could cause
> responding to a packet with the Response flag set. Is it possible to re-run
> this test against libreswan-3.10-3 ?
Sure, no problem. I will let you know the result after re-run.
Rerun with libreswan-3.10-2.el7 and test passed now, no response found.