Subject: [Hipsec] Issue 3: NES and REA

From: [email-masked] (Henderson, Thomas R)
Date: Mon Sep 15 16:14:01 2003

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Monday, September 15, 2003 1:07 AM
> To: Andrew McGregor
> Cc: [email-masked]
> Subject: Re: [Hipsec] Issue 3: NES and REA
>=20
>=20
> Andrew McGregor wrote:
>=20
> >>   1. Is the new NES scheme, described at the end,
> >>      acceptable?  If yes, no more questions.
> >=20
> > It looks fine to me.
>=20
> Good.  I am still waiting for replies from others.

We havent implemented NES so we can't offer insight in that regard,
but your basic proposal looks fine.

>=20
> > May I suggest a generic HIP ACK with a field indicating=20
> what packet type is=20
> > being ACKed? =20
>=20

I don't see much savings in having a generic ACK packet type because the =

concatenation of ACK field and packet type field essentially becomes=20
a larger packet type field-- we don't have many packet types and we
have fewer still that require ACKs.

> In this light, I don't think it would be good to have a generic
> ack.  While such practise might be good from a basic protocol
> design point of view, there might be security complications.
> It looks like that in most cases where you would benefit from
> a simple ACK, you can do the same by changing your SPI and wait
> for data to start appearing on the new SPI.
>=20
NES might occur asynchronously from data transfer (e.g. telnet), in
which case without explicit ACK you might be hanging in an ambiguous
substate for a while.