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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Sep 2004 16:47:35 -0700

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

> 
> > 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.
> > 
> 
> My preferred approach for middle boxes (some prefer evil-boxes) is to
> let the protocol break in its presence. Clearly, I'm in a 
> minority here! :-)

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

> 
> 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.

> 
> 
> >>    The draft needs to motivate the need for a new key exchange
> >>    protocol.
> > 
> > 
> > Actually, that is the task of the architecture draft.  If 
> it doesn't,
> > or does the job poorly, please indicate which parts of the 
> 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.)
> 
> 
> Well, I didn't find any discussion in 
> 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.
> 
> Also, I am not clear why HIP has lower policy granularity. 
> 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.
> 

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 
> some text on
> why? IESG might as well ask the same question.
> 

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.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 14 Sep 2004 13:18:39 -0400

At 07:47 PM 9/13/2004, Henderson, Thomas R wrote:

> > some text on why? IESG might as well ask the same question.
> >
>

Becuase I was told to take it all out.

For those of you that do not have a history of HIP, I started it right 
after the Orlando IETF (dec 1998), only months after the IPsec specs were out.

In my not so humble opinion, the concepts in HIP have been borrowed by 
other efforts, and someone not knowing who's on first and what's on second, 
things can get confusing.

And the reason I was told to take any references out was very 
sensible:  Let HIP stand on its own merits, and not be faced with a 
competition with IKE (HIP concepts were done before IKEv2 started).

The parties that instructed me on this shall remain nameless, but they 
included many of the IETF heavies.

If someone wants to compare HIP and IKE, they are welcomed to write an 
Internet Draft.