[Swan-dev] Question on get_cookie() code

[Andrew Cagney]

>> 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
bits.

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:
   get_rnd_bytes(spi, spi_size)
   DBG_log("XXX: really generate SPI");
is much easier for now.  Once SPI exchanges work I can see about using
those functions.

>> 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
> numbers.

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?