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

From: [email-masked] (Henderson, Thomas R)
Date: Tue Jul 13 13:25:01 2004

Julien, thanks for your comments, response inline below:

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]=20
> Sent: Tuesday, July 13, 2004 10:51 AM
> To: [email-masked]
> Cc: Henderson, Thomas R
> Subject: Re: [Hipsec] (not) using HITs as an application identifier
>=20
>=20
> On Saturday 10 July 2004 21:39, Henderson, Thomas R wrote:
> > 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. =20
>=20
> > Another potential problem=20
> > 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.
>=20
> I can't see how the socket API would return a HIT to an=20
> application if=20
> the implementation loses context between HITs and IPs.=20

Here is the example I have in mind:  long-running application does=20
some DNS query at some time, and caches the result.  Kernel eventually
garbage collects HIT/IP address bindings that are not used for some=20
time.  Then the application eventually provides the HIT again.

>=20
> 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=20
> mapping.
>=20
> > 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.
>=20
> In this case the application needs to be aware of HIP because=20
> it needs=20
> to perform a reverse + forward lookup on the IP address.=20

I am not following this point.  I am not suggesting that the apps
have to do anything other than provide the address that they
want to talk to.  It is the kernel that would need to do the
reverse + forward lookup to get the HITs.

>=20
> Hence, I'd rather use a Type 2 HIT in this case, and perform=20
> a reverse=20
> lookup on Type 2 HIT.=20
>=20
> Also, I fail to see why such applications need _routable_=20
> AIDs. In the=20
> scenario you describe above, the application just needs "lookupable"=20
> AIDs.=20

In the referral case, when an non-HIP-aware app gives a HIT to a=20
non-HIP aware host, what does the host do with it?   It doesn't know=20
about any HIP lookup service.  It puts it into the IP header.

>=20
> One solution for this kind of application would be for the HIP stack=20
> to provide a tuning parameter allowing to run such applications with=20
> lookupable/routable AIDs (i.e., either IP addresses, or Type 2 HITs).=20
> This would retain the HIT-as-AID property for non-referral apps.
>=20
> > 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.
>=20
> I don't see why using HITs as AIDs prevents us from=20
> establishing a HIP=20
> association after the transport session has started, nor why it=20
> mandates the use of IPsec.
>=20
> Once your transport session is established with IP addresses as AIDs,=20
> nothing prevents you from running an opportunistic HIP exchange=20
> afterward. This kind of session will be bound to IP addresses instead=20
> of HITs, but we do not need to require such a constraint for all=20
> applications.
>=20

I agree that it doesn't mandate use of IPsec-- LHIP proves that.

As for establishing a HIP association after transport session, then
you have a different kind of session as you discuss above-- one not
covered by the present spec.  So I think you are agreeing on this point?

> > 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
> This seems really similar to both CGAs and Type 2 HITs. My=20
> understanding is that CGA is IPR-encumbered so we should try to avoid=20
> it. I dunno if Type 2 are IPR-free, because (at least to me) they=20
> seems very similar to CGAs in their properties (e.g., both=20
> aggregatable and provable identifiers).
>=20
> > 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?
>=20
> My (very personal) feeling is is that using HITs as AIDs is=20
> one of the=20
> stronger pros of using HIP, so I am in favor of keeping the current=20
> specification.
>=20
> HITs can be either lookupable, private, long-termed, short-termed,=20
> randomly assigned, authority assigned, etc... They are multi-purposes=20
> identifiers, as opposed to IP addresses which doesn't have all these=20
> nice properties, apart from being routable.
>=20
> Beside that, what do others HIPpies think?
>=20
> Thanks,
>=20
> --julien
>=20

---

From: [email-masked] (marcelo bagnulo braun)
Date: Wed Jul 14 08:33:01 2004

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

Perhaps we need to distinguish hip-aware-host from 
hip-aware-application here?

regards, marcelo

---

From: [email-masked] (Julien Laganier)
Date: Thu Jul 15 08:07:01 2004

Hi Thomas,

Please find my response inlined below:

On Tuesday 13 July 2004 20:23, Henderson, Thomas R wrote:
> > From: Julien Laganier [mailto:[email-masked]]
> > > 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 can't see how the socket API would return a HIT to an
> > application if
> > the implementation loses context between HITs and IPs.
>
> Here is the example I have in mind:  long-running application does
> some DNS query at some time, and caches the result.  Kernel
> eventually garbage collects HIT/IP address bindings that are not
> used for some time.  Then the application eventually provides the
> HIT again.

I agree that unless the app cached a lookupable Type 2 HIT this is an 
issue with the current spec. 

At best we can hope that having the HIP stack return EHOSTUNREACH will  
trigger the application to lookup again the corresponding FQDN. 

This appears to me a bit similar to the case where a host has multiple 
NICs with multiple IP addresses, which are stored in the DNS.

If one of these NICs (or its network of attachment) goes down while a 
long running application (e.g., email client) has cached only its IP 
address (the first one for example), the app will have problem until 
it query again the DNS and retries to connect to each of the 
addresses in the returned set.

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

Ok now I understand.

> > 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.
>
> In the referral case, when an non-HIP-aware app gives a HIT to a
> non-HIP aware host, what does the host do with it?   It doesn't
> know about any HIP lookup service.  It puts it into the IP header.

Ok. 

I think that we sould have a way to run such applications 
( "non-HIP-aware & referral-based") on a "pure IP legacy API", which 
would expose only IP addresses to applications, the HIT being only 
used in the HIP protocol itself, as per your proposal. 

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

I think we mostly agree. My main disagreement was on the scope of the 
change. You are proposing a HIP-wide change whereas I propose a 
referral-application-wide change.

While it's true that having a single usage model is simpler, and less 
error-prone while specifying the protocol, I would really like to 
retain HITs as AIDs for all the applications which works well with 
non-routable (and possibly non-lookupable, i.e. Type 1 HIT) AIDs.

The rationale behind my support for HIT-as-AID is that:
- I am (perhaps wrongly) asumming that this kind of application is the 
majority of networked applications.
- I think it is cleaner (architecturally speaking).
- I believe we can craft a support for referral apps (by using IP 
addresses, or type 2 HIT, as AIDs, as per your proposal).

Thanks,

--julien

---

From: [email-masked] (marcelo bagnulo braun)
Date: Thu Jul 15 09:07:00 2004

> referral-application-wide change.

But, how do you know if the app is planning to do a refferal or not?

I mean, in order to make a refferal application wide change the hip 
layer need to know which are the apps that will make refferals and 
which wno't.
So how do you recognize the refferal apps, i.e. how does the hip layer 
knows whether to use refferal capable AID or the regular hits?

Regards, marcelo

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

---

From: [email-masked] (Julien Laganier)
Date: Thu Jul 15 10:07:00 2004

Hi Marcelo,

On Thursday 15 July 2004 16:07, marcelo bagnulo braun wrote:
>
>
> > I think we mostly agree. My main disagreement was on the scope of
> > the change. You are proposing a HIP-wide change whereas I propose
> > a referral-application-wide change.
>

The administrator knows. 

For example I know that FTP uses referrals. 

An heuristic for finding them might be: Does it breaks with NATs? 

> So how do you recognize the refferal apps, i.e. how does the hip
> layer knows whether to use refferal capable AID or the regular
> hits?

It's not the HIP layer, it is the administrator who is determining 
which app makes referral, and which does not. Thus, the HIP layer 
will know because this functionnality is activated for each such 
application. 

How this functionnality is activated for an application (or a group of 
apps) is implementation-dependent, but one might think to a wrapper 
telling the HIP layer which PID (and childs) is about to make 
referrals, or a Jail (as in FreeBSD) within which all processes uses 
only IP addresses as AIDs, etc.

On my (kludge :) implementation, an application might use 
indiferrently a HIT, an IPv6 or an IPv4 address in the socket API. If 
I jail some of them within a HIT-addressed Jail, they'll use only a 
HIT. If I Jail some of them within an IP-addressed Jail, they'll use 
only IP addresses, thus allowing for referrals.

But this is not automatic, you need to know in advance which 
applications will make referrals.

Thanks,

--julien