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

From: [email-masked] (Henderson, Thomas R)
Date: Sun Jul 11 17:49:00 2004

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Sunday, July 11, 2004 7:30 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] (not) using HITs as an application identifier
>=20
>=20
> Hi Tom,
>=20
> El 10/07/2004, a las 21:39, Henderson, Thomas R escribi=F3:
>=20
> > One objection that has been raised to HIP in the multi6 context is
> > that it uses HITs as so-called "application IDs"-- i.e., the 128-bit
> > quantity passed to applications.  We have debated before the merits
> > of passing HITs off as IP addresses to applications, but it is clear
> > that such a practice will break applications that pass HITs around
> > to other applications (the "referral" problem), especially non
> > HIP-aware hosts and apps.  Another potential problem is if/when
> > the implementation loses (garbage collects?) the context=20
> between HITs
> > and IP addresses, and then receives a HIT via socket API-- there is
> > no way (presently) to do a reverse lookup to get the address.
> >
> > I am offering up for discussion the proposal that we use
> > routable IP addresses as application IDs (AIDs) instead of HITs.
> > This means that HIP would use IP addresses (namely, the addresses
> > used in the base exchange) as constant, non-changing addresses
> > in the pseudoheader,
>=20
> but wouldn't this expose to time shifted attacks?
> I mean the ownership of the AID would only be proven by the return=20
> routability capabilities of the initial exchange.

If AID has no crypto properties, yes.  If AID has some crypto =
properties,
it might be a bit stronger than return routability.

But just in case this wasn't clear, I am suggesting that the minimal AID
is the routable IP address (which may or may not have part of the=20
HIT embedded in it), but in the long run, applications may handle
HITs, addresses, (and maybe even HIs), and the original HIP properties
are not lost.

In some sense, I'm suggesting that the IP address again be used as a =
name
for the host, for the deployment benefit of those stacks and =
applications
that are not equipped to handle HIP.  On the surface, this seems to take =

us back to the same problems that we want HIP to solve.  But consider
that:
i) until a reverse mapping from HIT to IP address is available,=20
HITs will be a pain for both applications and stacks to deal with,
ii) a HIP-aware app can provide the system with a HIT plus an address=20
and get all of the benefits of HIP
iii) eventually, if a HIT reverse lookup service is available, apps
can start dealing only with HITs
iv) with parts of the HIT as the identifier ID in the address,
maybe some crypto strength even is retained for non-HIP-aware apps

>=20
> I mean, if you use the HIT as an AID, the identifier ownership is=20
> proven by the crypto features of the HIt, however, if you use the=20
> initial address as AID, the ownership of the AID cannot be=20
> proven using=20
> the crypto capabilties of the HIT, since there is no secure binding=20
> between the HIT and the AID, AFAICS.
>=20
> >  and HITs would, in principle, only be exposed
> > to HIP-aware applications.
>=20
> HIP aware apps would still need to be able to obtain locator=20
> information from the HIT, how can they do that?
>=20
> I mean, i don't see how using HIT for refferals would work=20
> even in the=20
> case of HIP aware applications.
>=20

It would work in either of two cases:
- reverse lookup service for HITs is available
- HIT + FQDN is passed as a referral (or HIT + address, with the
reverse DNS tree populated)

> >  This would solve the referral problem
> > and also the lost context problem if DNS records are present--
> > a host could do a reverse lookup on IP address and then do a forward
> > lookup to get the HIP records.  HITs would still be used in the base
> > exchange and for HIP-aware applications and APIs.
> >
> > Besides solving the referral problem, routable AIDs could have a
> > second potential benefit:  flexibility.  Specifically, now in
> > HIP, it is required to perform a context establishment handshake
> > before the first transport packets are received, since each host
> > needs to know the HITs that it is dealing with (e.g., for checksum
> > computation).  If AIDs were routable, it opens the door for
> > some options in establishing HIP state.  One example would be
> > the opportunistic use of HIP *after* the transport session had
> > started, and without IPsec.  That is, a session could start up
> > by using normal communications, then transition to HIP and do
> > a base exchange if it decided to go mobile.  Pekka has previously
> > suggested a "Lightweight HIP" that runs without IPsec, but
> > by using routable AIDs, we might also be able to defer the
> > HIP handshake altogether or use it selectively.
> >
> > In addition, it might be possible to retain some (weaker) crypto
> > properties of these AIDs by allowing the low-order bits of
> > the HIT to be used as the interface ID in the IPv6 address, in
> > the spirit of Erik Nordmark's CB64 proposal in the multi6 group.
> >
>=20
> i think this approach would provide the ownership proof of=20
> the AID that=20
> it is required, if it is considered strong enough (crypto speaking)
>=20

I think that in many cases it would, but several people have objected
to the crypto strength of 64 or 48 bits, so in the long run, it=20
would be good to back this up with (or provide transition path to)
the stronger 128 bits of a HIT.
=20
Tom

---

From: [email-masked] (marcelo bagnulo braun)
Date: Mon Jul 12 05:50:01 2004

>
>
> If AID has no crypto properties, yes.  If AID has some crypto 
> properties,

imho, return routability is not good enough, not even for a transition 
mechanism.
The minimum required imho would be the second option where some part of 
the AID contains is crypto based, as in cgas

for the rest, i agree with your proposal

regards, marcelo

> is the routable IP address (which may or may not have part of the
> In some sense, I'm suggesting that the IP address again be used as a 
> name
> for the host, for the deployment benefit of those stacks and 
> applications
> that are not equipped to handle HIP.  On the surface, this seems to 
> take
> i) until a reverse mapping from HIT to IP address is available,
> ii) a HIP-aware app can provide the system with a HIT plus an address
>> I mean, if you use the HIT as an AID, the identifier ownership is
>> proven by the crypto features of the HIt, however, if you use the
>> initial address as AID, the ownership of the AID cannot be
>> proven using
>> the crypto capabilties of the HIT, since there is no secure binding
>> HIP aware apps would still need to be able to obtain locator
>> I mean, i don't see how using HIT for refferals would work
>> even in the
>> i think this approach would provide the ownership proof of
>> the AID that
> to the crypto strength of 64 or 48 bits, so in the long run, it