HIP and IKE -- was -- Re: [Hipsec] Moving the base spec forward

[[e-mail] (Henderson, Thomas R)]

Yogesh, thanks for your discussions, I have a few responses inline:

>=20
> > One bigger issue is relationship to middlex boxes, though.  HIP
> > has been designed to be middle box friendly, explicitly keeping
> > fields that middle boxes might inspect, including SPIs, in clear
> > text.  IKE favours confidentiality and secrecy here, HIP doesn't.
> >=20
>=20
> My preferred approach for middle boxes (some prefer evil-boxes) is to
> let the protocol break in its presence. Clearly, I'm in a=20
> minority here! :-)

There was a recent position paper in Sigcomm conference that argues that
middleboxes can be your friend :)

>=20
> But I see your point. Although, I won't keep the SPI in clear, I can
> still live with it. Without SPI encryption, USER_ID encryption alone
> looses a few of its of benefits.

One application of HIP that my company is quite interested in is the
ability to do access controls on a HIP-enabled data connection, for
which the middleboxes need to know the mapping from HITs to SPIs that
are generated by the HIP exchange.  I have been told many times that
large corporations are not going to throw away their middleboxes once
IPv6 comes around.

>=20
>=20
> >>    The draft needs to motivate the need for a new key exchange
> >>    protocol.
> >=20
> >=20
> > Actually, that is the task of the architecture draft.  If=20
> it doesn't,
> > or does the job poorly, please indicate which parts of the=20
> architecture
> > draft you would like to see improved.  (-06 is malformated, I'm
> > in the process of issuing -07.  -05 may be easier to read, if you
> > can find it.)
>=20
>=20
> Well, I didn't find any discussion in=20
> draft-moskowitz-hip-arch-06.txt on
> why someone will choose a "low policy granularity" based key-exchange
> (i.e., present HIP) when another one already exists.
>=20
> Also, I am not clear why HIP has lower policy granularity.=20
> Isn't policy
> based on the USER_ID (e-mail. FQDN etc.) -- which HIP already has? Do
> you mean fancy ways of  authenticating hosts, by policy granularity? I
> must be missing something here.
>=20

I have always understood this phrasing to mean that HIP exchange does
not offer as many negotiation options for the SA attributes, and does
not enable things like setting up multiple SAs between hosts that
match on various different header values in the data packets.

> Not saying we should not have HIP key exchange. But do add=20
> some text on
> why? IESG might as well ask the same question.
>=20

I agree with you that the architecture draft does not really talk
about why HIP is different from IKE.  It seems to be nowhere written
down.