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

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jul 21 13:50:11 2004

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> 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
>=20
>=20
> Hi Tom,
>=20
> El 21/07/2004, a las 4:25, Henderson, Thomas R escribi=F3:
>=20
> >
> >
> >> -----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=20
> with a HIT.
> >>
> >> I mean, how does a node knows that a given AID (routable=20
> 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=20
> to the AID=20
> > is
> > another.
> >
>=20
> I agree that those mechanism can provide the security features, but=20
> 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=20
> mechanisms as those you describe above in order to provide=20
> the required=20
> security for those identifiers, then why do you need to map=20
> to the HIP,=20
> for instance in the pseudo header, in other words, who would=20
> deal with=20
> the HIT in this case?
>=20

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=20
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=20
that the apps eventually deal with the more secure names available=20
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=20
architecturally cleaner in my view, but it seems to have possible=20
downside in being able to delay HIP exchange.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Thu Jul 22 11:18:01 2004

>> I agree that those mechanism can provide the security features, but
> I view the proposed routable AID more as a
> transition mechanism to support both referrals to non-HIP-aware hosts 
> and

And I fully concur with this view.

> In the future, were HIP to become useful and deployed, I would expect
> that the apps eventually deal with the more secure names available

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