Subject: [Hipsec] Indicating Reply Requested and renaming NES?

From: [email-masked] (Henderson, Thomas R)
Date: Fri Dec 19 21:32:00 2003

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Friday, December 19, 2003 3:46 AM
> To: Henderson, Thomas R
> Cc: Julien Laganier; [email-masked]
> Subject: Re: [Hipsec] Indicating Reply Requested and renaming NES?
>=20
>=20
> Tom,
>=20
> > In thinking about this and Pekka's posts some more, this
> > option appeals to me if it is made a parameter or part of
> > an existing parameter rather than base header.
>=20
> I'm, on the other hand, inclined to think that we most
> probably should have sequence numbers in the base header.
> That would make the protocol more future proof, i.e.,
> I would foresee less complications with future extensions.

OK, I am willing to concede this point for the sake of
potential extension.  But can we put it in 8-bits in the=20
existing control field?  And I assume that it
monotonically increases with each packet sent (such
as I1 =3D 0, R1=3D 0, I2=3D1, R2=3D1, ...)?

>=20
> Remember that Bob's original design used ESP sequence
> numbers as replay protection in NES.  We removed it
> since it would have been very cumbersome to implement
> in many cases.

we found this to be true-- requires PF_KEY extensions

>=20
> > But RESYNCH might also be a candidate for
> > "avoidance of replay".
>=20
> Resynch would need birthday protection.  As far as
> I understand, resynching was the reason why the
> birthday value was added to the protocol in the first
> place.
>=20

I am thinking that birthday may not be needed if we
make Resynch a variant of I1 and I2 and if we have the=20
host generate new R1s upon every successful Resynch. =20
By variant, I mean that it turns on a "resynch" bit
in the control field.

Can you elaborate an attack on Resynch if it follows
the below procedures, *not* using birthday? =20

Resynch I1 ->
<- R1
Resynch I2 ->
<- R2
   (responder regenerates R1s)

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Mon Dec 29 06:59:02 2003

> potential extension.

Good.

> But can we put it in 8-bits in the
> existing control field?

Well, that is a tricky question.  We certainly need to
have a much longer sequence number counter internally,
and that longer count MUST be covered by the HMAC in
the packets.  On the other hand, I can't foresee how
we could have more than a few HIP packets on the fly
at the same time.  Hence, including only 8 low order
bits of the counter to the packet is probably enough.
 From that point of view, yes, we can put it into 8-bits
of the control field.  For replies, there could be a
separate parameter that contains the sender's full
sequence number.

(IMHO, 24-bit sequence number would be long enough
-- I can't easily imagine HIP associations with more 
than 2^24-1 packets.  Even 16 might do.)

The problem is to define where to put the rest of
the sequence number bits while computing and verifying
HMACs and SIGNATURES.  We could use the checksum
field (since it is currently zeroed), but the bytes
would then be in an awkward order, resulting in
pretty silly code.  OTOH, we can't exchange the locations
of control bits and checksum if we want to retain the
possibility of using UDP hardware to compute and check
the checksum.

Opinions?

>  And I assume that it
> as I1 = 0, R1= 0, I2=1, R2=1, ...)?

Yes.

>> Resynch would need birthday protection. ...

> the below procedures, *not* using birthday?
>
> Resynch I1 ->
> <- R1
> Resynch I2 ->
> <- R2

You have to explain your thoughts in more detail before
I can say anything about it.

--Pekka