Subject: RE: [Hipsec] (not) using HITs as an application identifier

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 21 Jul 2004 09:32:52 -0700

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Wednesday, July 21, 2004 7:15 AM
> To: Henderson, Thomas R
> Cc: [email-masked]; Pekka Nikander
> Subject: Re: [Hipsec] (not) using HITs as an application identifier
> 
> 
> Hi Tom,
> 
> El 21/07/2004, a las 4:25, Henderson, Thomas R escribió:
> 
> >
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:[email-masked]]
> >> Sent: Tuesday, July 20, 2004 2:19 AM
> >> To: Pekka Nikander
> >> Cc: Henderson, Thomas R; [email-masked]
> >> Subject: Re: [Hipsec] (not) using HITs as an application identifier
> >>
> >>
> >> Hi Pekka,
> >>
> >>
> >>> I haven't thought about the security implications of this, yet.
> >>>
> >>
> >> i guess that the problem is how to (securely) link an AID 
> with a HIT.
> >>
> >> I mean, how does a node knows that a given AID (routable 
> IP address)
> >> actually corresponds to a given HIT?
> >>
> >
> > What scenario are you worried about?
> >
> > If a system is only provided with a routable AID, there are some
> > limits to the security of being able to link it to a HIT.  However,
> > trusted DNS with reverse lookup is one way.  CB64 approach 
> to the AID 
> > is
> > another.
> >
> 
> I agree that those mechanism can provide the security features, but 
> then i wonder what do you use the HIT for?
> I guess i am not understanding Pekka's suggestion...
> I mean if the apps uses the routable AID and you build the security 
> mechanisms as those you describe above in order to provide 
> the required 
> security for those identifiers, then why do you need to map 
> to the HIP, 
> for instance in the pseudo header, in other words, who would 
> deal with 
> the HIT in this case?
> 

I still think that HIT is useful as a fixed length identifier with
strong cryptographic properties and less odds of collision than
64 bits, for example.  I view the proposed routable AID more as a 
transition mechanism to support both referrals to non-HIP-aware hosts and
to help deployment before there is a reverse lookup service for HITs.
In the future, were HIP to become useful and deployed, I would expect 
that the apps eventually deal with the more secure names available 
such as HITs, and use a HIP-aware API.

As far as I understand it, the difference with Pekka's suggestion
is mainly what goes into the pseudoheader.  Using HITs is 
architecturally cleaner in my view, but it seems to have possible 
downside in being able to delay HIP exchange.

Tom
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 22 Jul 2004 19:17:48 +0300

> I view the proposed routable AID more as a

And I fully concur with this view.

> such as HITs, and use a HIP-aware API.

Again, I fully agree.  Furthermore, my personal guess is that most
people would configure their stack to return HIT by default, and
use IP-address-AIDs only for some odd apps that would not work with
HITs.  But that's a question where we can get the answer from ther
market, I guess.

> is mainly what goes into the pseudoheader.

Yes, at the protocol level the difference between your and my 
suggestions
is exactly this.

> Using HITs is architecturally cleaner in my view, but it seems to
> have possible downside in being able to delay HIP exchange.

My gut feeling is that the problem with delaying the HIP exchange
can be solved, at least to a degree.  Furthermore, for some reason
which I can't quite express yet, I dislike the idea of starting a
session without any extra signalling, and then "upgrading" later
to HIP.  IMHO, at minimum there should be a single bit saying that
"I support this extension", negotiated during the initial handshake.
And if so, I don't see exchanging 2 16 byte words that much more
than a single bit :-)

--Pekka