[Swan-dev] COOKIE_SIZE is IKEv1!

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| - COOKIE_SIZE is IKEv1 so should not appear in IKEv2 code at all!
| IKEv2 has cookies but they are completely different, having nothing to
| do with this value.

COOKIE_SIZE is the size of the fields in the header that hold v2 IKE
SPIs.  This is by protocol design, not an accident.  So this usage is
correct.

We call the fields isa_rcookie and isa_icookie.  They end up in
st_icookie and st_rcookie.

If we want to give the size a v2 name, that's fine.  It should be
defined as COOKIE_SIZE, not 8, to make the relationship manifest.
I'd prefer one name that shows both meanings but
SIZE_IKEv1_COOKIE_IKEv2_IKE_SPI is unwieldy.

I'm would be much less happy about about giving the fields two names.
Aliasing a mutable thing is a really horrible trap.

The current definition looks like this:

/* COOKIE_SIZE is also IKEv2 IKE SPI size */
#define COOKIE_SIZE 8

So if someone is puzzled about a reference to COOKIE_SIZE in V2 code,
they can look at the definition and discover this explanation.

COOKIE_SIZE was already widely used in v2 code before my change.  Many
of those uses could be replaced by sizeofs.

| - I suspect IPSEC_DOI_SPI_SIZE is equally dubious

No, it is the size that is used in the kernel for ESP and AH SPIs.
Nothing to do with the version of IKE.  There might be another
existing name for this, I haven't looked.  If there is, it might be
better.  Good luck grepping for 4.

| and by using magic macros we've just burried what should be simple numbers.

This I completely disagree with.  8 means many things.  COOKIE_SIZE
shows what the heck the number is.  And the name helps you find
related uses.  Good luck grepping for 8.

We do not drop magic numbers into our code.  I'm surprised you think
that we should.