[Swan-dev] fixing Windows rekeying

[Antony Antony]

On Wed, Apr 29, 2020 at 01:35:42PM -0400, Paul Wouters wrote:
> On Wed, 29 Apr 2020, Tuomo Soini wrote:
> 
> > > An earlier version of the patch needed that then I relaized that
> > > whole logic different. And fixed it.
> > 
> > I also note that my initial suggestion as a fix was to remove the check
> > because it's quite meaningless - whatever remote suggests we ignore
> > anyway on rekey.
> 
> The reason this came up was a bug on our end where we as initiator of a
> rekey send a bogus proposal that was not rejected. The desire is to do
> the checks so we can fail properly instead of continuing, responding
> to the initiator and then the initiator finding out it got something
> bad that is not within its set of allowed TS. It then would have to
> create a new informational message to delete, or ignore our response
> and retransmit.

I thought same when fixing that bug, however, I was cautious not to add 
validation checks without test cases. Now with impairs and testcases I am 
realizing revert is a good option.

I am a +1 to revert 7be41582a340. It is not bringing much value.  Though, a 
simple revert may not work at this point on master due to changes following 
it. It is bit complicated to revert, but doable.

> I think the desire to fail cleaner is good.

Windows behavior seems ok as per the old IKEv2 RFC, 5996. The
7296 updated rekey and ts behavior. The RFC is not clear and use 
complicated terms.  So I do not see a need to fail clear as a responder. If 
the rekey initiator do not like what responder send the initiator will fail.
That is what I discovered using test cases.