[Swan-dev] Question on get_cookie() code
andrew.cagney at gmail.com
Thu Jan 7 18:00:54 UTC 2016
>> For IKEv2, they need to be non-zero, given the odds of that are low,
>> I've been using an initial hack:
> Why are you looking at spi cookies at all?
Unfortunately, Pluto's old SA proposal matcher for ESP/AH, has code
generating SPIs embedded within it (and if we ever rekey ike, it
likely should but doesn't). I suspect the reason (which seems sound),
is to delay the RND call until after a proposal is matched. I'm,
well, replicating the behaviour and sketching in the missing rekey-ike
Speaking of which, for an initial IKE, I believe, when there is no
match, the SPI is generated and then discarded?
>> I've been working on the assumption that IKEv2 will have its own SPI
>> generators (at least for AH/ESP / CHILD_SA).
> Why does it need a different one?
For the moment because the way it interfaces is weird - its like IKE
vs ESP vs AH there's duplicated code with no clear rationale. This:
DBG_log("XXX: really generate SPI");
is much easier for now. Once SPI exchanges work I can see about using
>> And please consider going further, and s/icookie/initiator_spi/ et.al.
>> so that it makes reading the code from an IKEv2 much easier.
> Agreed but its weird because these appear in the IKE header, so are
> shared between IKEv1 and IKEv2, and IKEv1 calls it cookies not SPI
Yea IKEv2 has real cookies and these are not it. In fact, if we
suspect we're under some sort of crypto pool attack then isn't the
defence to use strong-random cookies?
More information about the Swan-dev