Subject: [Hipsec] Splitting the COOKIE parameters

From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 20 12:13:00 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Tuesday, April 20, 2004 4:05 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] Splitting the COOKIE parameters
>=20
> >=20
> > However, could you explain why Birthday is 96 bits?  This is likely
> > cumbersome data type to support on the native system.  Incrementing
> > once per second, a 32 bit counter takes over 100 years to roll over.
>=20
> Just alignment.  32 bits may not be enough for busy servers and
> such, otherwise it might be sufficient.
>=20
> If we want to save some bytes, maybe we could combine BIRTHDAY
> to the DIFFIE_HELLMAN parameter?

It is fine with me to keep it in a separate TLV-- my main objection
was 96 bits, which seemed excessive and more difficult to implement
and handle.  I still don't see a requirement for larger than 32 bits,
but I see that this was originally 64 bits in draft-moskowitz-hip-05.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Wed Apr 21 00:33:00 2004

>>> However, could you explain why Birthday is 96 bits? ..
>>
>> Just alignment.  32 bits may not be enough for busy servers ..
>>

I'm fine with reducing birthday back to 64 bits, making the 32 bits
reserved:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Type              |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Reserved, 4 bytes                                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Birthday, 8 bytes                                             |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--Pekka

---

From: [email-masked] (Mika Kousa)
Date: Wed Apr 21 04:01:00 2004

On Tue, 20 Apr 2004, Henderson, Thomas R wrote:

-> > -----Original Message-----
-> > From: Pekka Nikander [mailto:[email-masked]]
-> > Sent: Tuesday, April 20, 2004 4:05 AM
-> > To: Henderson, Thomas R
-> > Cc: [email-masked]
-> > Subject: Re: [Hipsec] Splitting the COOKIE parameters
-> >
-> > >
-> > > However, could you explain why Birthday is 96 bits?  This is likely
-> > > cumbersome data type to support on the native system.  Incrementing
-> > > once per second, a 32 bit counter takes over 100 years to roll over.
-> >
-> > Just alignment.  32 bits may not be enough for busy servers and
-> > such, otherwise it might be sufficient.
-> >
-> > If we want to save some bytes, maybe we could combine BIRTHDAY
-> > to the DIFFIE_HELLMAN parameter?
->
-> It is fine with me to keep it in a separate TLV-- my main objection
-> was 96 bits, which seemed excessive and more difficult to implement
-> and handle.  I still don't see a requirement for larger than 32 bits,
-> but I see that this was originally 64 bits in draft-moskowitz-hip-05.

I would also like if it would be some more common type than a 96 bit
number, eg. a 64 bit number.

By the way, why is Update ID now a 24 bit number as you proposed in your
mail "hip-mm proposed revisions" a couple of days ago ? Why it should be
changed from 16 bit to 24 bit ? This has the same issue as previous 96 bit
vs. 64 bit. I wouldn't be so surprised if different handling of 24 bit
number would cause some problems during the interops. Do you really see
that there will be 2^96 UPDATEs in a short period of time or what was the
reasoning behind moving to 24 bits ?