[Swan-dev] fixing Windows rekeying

Antony Antony antony at phenome.org
Wed Apr 29 16:21:02 UTC 2020


On Wed, Apr 29, 2020 at 10:44:36AM -0400, Paul Wouters wrote:
> On Wed, 29 Apr 2020, Antony Antony wrote:
> 
> > Here is my attempt to fix it. I guess there more attempts Paul and Andrew
> > has their own?
> 
> You didn't guess, you replied and you you would read it later. But it
> seems you forgot. 
> 
> > I didnt commit because there more happening around. May be
> > combine and take the best.
> 
> The code is not combinable.
> 
> > During rekey on the responder this patch validate TS before the crypto
> > starts.  Which I think is way better. I have been thinking of the same for
> > initiator; when get the response to.  May be that should be later fix, first
> > commmit the responder side clean up.
> 
> Moving TS checking to before crypto is good. However, the rest of the
> patch is not as I had earlier described. The whole bestbit/score code
> from the Initial Exchanges cannot be re-used because for rekeying, you
> cannot switch to a better connection, which is required for use in the

I feel ther is serious mis interpretation here. Score code does not switch 
connections.  It only score. Show me test case during rekey connection would 
switch. Then it would be interesting to talk:)

I think score code will take care of the whole TS in one go. If we write 
something else it is re-inventing the wheel for a complex logic.


> Initial Exchanges. Also, calculating a score is overkill when all we
> want to do is check if their proposal, which we are going to ignore for
> our existing IPsec SA and only needs to be matchable onto our existing
> IPsec SA, can be narrowed to that. The bestfit/scoring code is meant to
> find the _best_ matching new connection in the initial exchange.
> 
> Additionally, as I pointed out there is the issue of addresspool without
> narrowing=yes working in the Initial Exchanges, and the reason I did not
> push my patch yet was that we were still talking about whether having
> an addresspool should imply narroing or not. For rekey, this issue comes
> back. I assume your bestfit/scoring code also looks at the NARROWING
> policy to determine if only an exact match is allowed or a narrowed
> one is also allowed, so existing deployments with 3.30 or older that
> do not use narrowing=yes with an addresspool would break clients on rekey.

I will check this one I guess testcase has responder narrowing yes.
If you have test case please point me.

I invite your code to run 4 test cases I mentioned earlier.

-antony


More information about the Swan-dev mailing list