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

From: "Henderson, Thomas R" <[email-masked]>
Date: Sat, 10 Jul 2004 12:39:45 -0700

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 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, and HITs would, in principle, only be exposed 
to HIP-aware applications.  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.

The main change in our existing implementations would be to specify
that the initial IP addresses are used for the transport checksum,
instead of HITs, and that a transport session keeps using these
same initial addresses in the checksum regardless of whether the 
addresses change.  (logically, the HIP layer would map the current
addresses in use back to the initial addresses before handing off
to transport).  I don't think that such a change would break any 
existing HIP features.

Comments?

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 11 Jul 2004 16:29:31 +0200

Hi Tom,

El 10/07/2004, a las 21:39, Henderson, Thomas R escribió:

> in the pseudoheader,

but wouldn't this expose to time shifted attacks?
I mean the ownership of the AID would only be proven by the return 
routability capabilities of the initial exchange.

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 
between the HIT and the AID, AFAICS.

>  and HITs would, in principle, only be exposed
> to HIP-aware applications.

HIP aware apps would still need to be able to obtain locator 
information from the HIT, how can they do that?

I mean, i don't see how using HIT for refferals would work even in the 
case of HIP aware applications.

>  This would solve the referral problem

i think this approach would provide the ownership proof of the AID that 
it is required, if it is considered strong enough (crypto speaking)

regards, marcelo

---

From: Julien Laganier <[email-masked]>
Date: Tue, 13 Jul 2004 19:51:00 +0200

On Saturday 10 July 2004 21:39, Henderson, Thomas R wrote:
> 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
> 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 can't see how the socket API would return a HIT to an application if 
the implementation loses context between HITs and IPs. 

AFAICS, the socket API would return HIT if and only if the HIP layer:
o Maintained a context containing the (to be) returned HIT
o Performed a DNS lookup on a FQDN, hence establishing an IP <-> HIT 
mapping.

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

In this case the application needs to be aware of HIP because it needs 
to perform a reverse + forward lookup on the IP address. 

Hence, I'd rather use a Type 2 HIT in this case, and perform a reverse 
lookup on Type 2 HIT. 

Also, I fail to see why such applications need _routable_ AIDs. In the 
scenario you describe above, the application just needs "lookupable" 
AIDs. 

One solution for this kind of application would be for the HIP stack 
to provide a tuning parameter allowing to run such applications with 
lookupable/routable AIDs (i.e., either IP addresses, or Type 2 HITs). 
This would retain the HIT-as-AID property for non-referral apps.

> HIP handshake altogether or use it selectively.

I don't see why using HITs as AIDs prevents us from establishing a HIP 
association after the transport session has started, nor why it 
mandates the use of IPsec.

Once your transport session is established with IP addresses as AIDs, 
nothing prevents you from running an opportunistic HIP exchange 
afterward. This kind of session will be bound to IP addresses instead 
of HITs, but we do not need to require such a constraint for all 
applications.

> the spirit of Erik Nordmark's CB64 proposal in the multi6 group.

This seems really similar to both CGAs and Type 2 HITs. My 
understanding is that CGA is IPR-encumbered so we should try to avoid 
it. I dunno if Type 2 are IPR-free, because (at least to me) they 
seems very similar to CGAs in their properties (e.g., both 
aggregatable and provable identifiers).

> to transport).  I don't think that such a change would break any

My (very personal) feeling is is that using HITs as AIDs is one of the 
stronger pros of using HIP, so I am in favor of keeping the current 
specification.

HITs can be either lookupable, private, long-termed, short-termed, 
randomly assigned, authority assigned, etc... They are multi-purposes 
identifiers, as opposed to IP addresses which doesn't have all these 
nice properties, apart from being routable.

Beside that, what do others HIPpies think?

Thanks,

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 16 Jul 2004 19:57:08 +0300

A very interesting proposal, Tom.  Thanks!  But perhaps we

> routable IP addresses as application IDs (AIDs) instead of HITs.

Sounds quite interesting; my first thought was that this sounds
like using routable IP addresses as LSIs.

> to HIP-aware applications.

What if we used routable IP addresses *only* in the API level,
and not even in the pseudo header? That is, what if the API layer
would have a table of "HIPed" IP addresses, and would map
an IP address returned by an application immediately, before
passing it down the stack, into a HIT, an vice versa.  There would
be a bit in the process context and/or in the socket data structure
telling whether this mapping is done or not.  It would be implementation
specific how to define the default for these bits per process.
(Side note: implementing this would be almost trivial in our FreeBSD
implementation.)

That would allow non-referral apps to interoperate between the
current style HIP implementations and the IP-addr-API style HIP
implementations, similar in nature to the current ability to allow
IPv4 API apps interoperate with IPv6 API apps.  Given that most
implementations would probably offer both modes of operation, the
market would probably pretty soon decide which mode to use.

In summary, implementations would map IP address AIDs into HITs
when processing "outgoing" system calls, and map the HIT in
received packets into the IP address AID in "incoming" system
calls.

I haven't thought about the security implications of this, yet.

--Pekka

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 20 Jul 2004 11:19:08 +0200

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?

Regards, marcelo