Subject: [Hipsec] Comments on draft-nikander-hip-mm

From: [email-masked] (Henderson, Thomas R)
Date: Mon Apr 19 00:35:03 2004

> > Currently the RR request doubles as an ack for the REA.
>=20
> This was (and still is) an important optimisation, IMHO.
> Of course, as Tom described, you don't need to initiate
> RR at the same time, you can just ack REA.
>=20
> Adding to the five scenarios Tom described, I still think
> that it is OK to implicitly finish RR with new traffic to
> a new SPI.  However, I haven't had time to carefully
> read -02-pre1 to see what the text says, and if any
> changes are needed there.  Hence, the reply UPDATEs
> in Tom's scenarions #3, #4 and #5 *MAY* be replaced
> with implicit traffic.  In fact, IMHO in scenario #4
> where a new SPI is created the reply update is really
> unnecessary.  But apparently people's opinions
> differ on this.

This optimization (skipping UPDATE response by sending
data on new SPI) is not contained in the text that I proposed. =20
Currently, UPDATE packet always causes an UPDATE reply.

Conceptually, I like to save packets when possible, but
I wonder whether we can get by with the implicit ACK if
middleboxes are along the way.  I think that you are=20
suggesting that we can't in all cases (you don't suggest=20
implicit ack in scenario 2, perhaps for this reason), but in
the other cases, we probably need to think more about
the packet processing rules as for when a host is allowed
to make that optimization.  But I'm in favor of trying
to make that optimization work as long as it doesn't make
the state machine logic too ugly.

Overall, the text that I proposed needs an iteration to=20
check for middlebox-friendliness of the potential
exchanges.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 27 06:30:03 2004

> data on new SPI) is not contained in the text that I proposed.
> middleboxes are along the way.  I think that you are
> suggesting that we can't in all cases (you don't suggest
> Overall, the text that I proposed needs an iteration to

I've assigned this separately issue #3, as allowing
ESP data to ack is an issue separate from middle box
friendliness.

--Pekka