[Swan-dev] Question on get_cookie() code

[Paul Wouters]

On Thu, 7 Jan 2016, Andrew Cagney wrote:

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

I see.

> Speaking of which, for an initial IKE, I believe, when there is no
> match, the SPI is generated and then discarded?

If we are responder and send back NO_PROPOSAL_CHOSEN in response to the
first IKE message, our SPI should be 0. If the error happens later in
the exchange, then we have commited to a SPI (and they might resend with
different proposal values although very unlikely)

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

Ok.

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

I'm very much aware of the confusion. I probably have a tshirt somewhere :)

>  In fact, if we
> suspect we're under some sort of crypto pool attack then isn't the
> defence to use strong-random cookies?

We use a hash so it does not use randomness/entropy while providing
strong pseudorandom.

Paul