[Hipsec-rg] comments on draft-heer-hip-middle-auth-01

thomas.r.henderson at boeing.com (Henderson, Thomas R) Tue, 30 September 2008 23:11 UTC

From: "thomas.r.henderson at boeing.com"
Date: Tue, 30 Sep 2008 16:11:37 -0700
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <48E28FF4.4090806@nomadiclab.com>
References: <77F357662F8BFA4CA7074B0410171B6D07B0B7D7@XCH-NW-5V1.nw.nos.boeing.com> <2898C925-ADDB-4838-8213-6A93670712D6@cs.rwth-aachen.de> <48E28FF4.4090806@nomadiclab.com>
Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0B8E5@XCH-NW-5V1.nw.nos.boeing.com>

Jan,

I have a few follow-ups below on your observations.

> -----Original Message-----
> From: Jan Mikael Melen [mailto:Jan.Melen at nomadiclab.com] 
> Sent: Tuesday, September 30, 2008 1:46 PM
> To: Tobias Heer
> Cc: hipsec-rg at honor.trusecure.com; Henderson, Thomas R
> Subject: Re: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
> 
> Hi Tobias,
> 
> I think that no one can give you a definitive answer whether 
> HIP aware 
> middleboxes will ever exist or not. The thing is that it is really 
> dependent on the fact whether HIP ever gets deployed in large 
> scale or 
> not? 

(co-chair hat off)

I do not think that HIP-aware middleboxes are on the critical path to
deploying HIP, so I can't personally prioritize spending cycles on it,
at this time, over working on the NAT traversal draft or on
implementations or other deployment-related things.

That being said, I have heard of some interest in being able to use HIP
to support security use cases where there is path-coupled signaling for
authentication, for certain security-conscious environments.  This
includes interest from within my own company.  A competing architecture,
however, is OpenFlow/Ethane, which operates at L2 and arguably provides
more security.

> I personally am still betting on the fact that HIP will 
> eventually 
> be deployed due to fact that it still has a lot of good 
> features nicely 
> packaged into a single protocol so from that perspective I do support 
> the work you are doing. 
> It even seems that a lot of people in 
> the IETF 
> are looking into HIP and HIP kind of solutions. In the last 
> IETF I heard 
> HIP mentioned several times but still in the same comments 
> there was a 
> lot of hesitation on the deployment issue. 

To me, there seems to be continual and renewable interest in finding one
or more names to use as stable identifiers above the forwarding layer in
the architecture, but there never is a convergence on what this name (or
names) should be, or the degree of transparency/exposure to
applications.  I think that if you explain HIP to people, they
immediately get the concept, but there are so many variations possible,
and tradeoffs among them, and even disagreement on the problems or
priorities being addressed, that it is hard to agree on a unifying
solution.

> But as you 
> probably have also 
> noted from the previous meetings, the HIP-RG and WG discussion are 
> really dead and we really must find a user for HIP (meaning 
> new people 
> in to RG and WG meetings) otherwise I think that the 
> collaboration you 
> are expecting is not going to be as fruitful as you would 
> like it to be.

I agree with this comment; I think that this draft (or any other
feature) needs to find use cases and deployment scenarios to spark some
interest and urgency from possible users.  I think that Tobias has
outlined a few such cases, but there needs to be some pull from users
who want to architect security in this manner.

> 
> Btw. Latest twist on the ID/Loc issue began from Dublin where 
> in the RRG 
> meeting during the Joe Halperns Id/Loc split presentation a 
> question was 
> raised why not push down the FQDN in to the stack. This is 
> not really a 
> new idea but first time I've heard some serious discussion on 
> the topic 
> if you want to know more go and see the mailing archive of RRG.

Along these lines (of using FQDN as the stable identifier), I would
recommend to read over the slides from Dave Thaler's Mobiarch keynote,
available at:
http://conferences.sigcomm.org/sigcomm/2008/workshops/mobiarch/

- Tom