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

From: Erik Nordmark <[email-masked]> (Erik Nordmark)
Date: Thu Jul 29 05:05:01 2004

> I don't really know how I would distinguish between referral aps 
> and non-referral apps from within the kernel, or how to wrap them 
> as you mentioned.  Perhaps I don't fully understand.

I have the same concern.

A conservative approach would be to assume that all unmodified
applications need an IP address as the AID and then have sevarel
mechanisms by which one can specify that a HIT as the AID is fine:
 - an API that the application can invoke
 - mechanisms external to the application that a system admin can
   use e.g. to say that the applications which use a particular TCP port 
   number, where the application has a particular name, etc
   can use a HIT as the AID.

This way one can incrementally try running different unmodified applications
with AID=HIT and see if they work.

Separately presumably it is desirable for add new APIs for modified
applications to extract lower level information:
 - get the HIT for the peer (which might be useful even when AID=IP address)
 - get the current set of known locators for the peer (for referrals using
   HIT+set of locators)

What isn't clear to me though are the tradeoffs between having the transports
use the HIT vs. the IP address in the pseudo-header; it would be good to
try to enumerate those.

   Erik

---

From: [email-masked] (marcelo bagnulo braun)
Date: Thu Jul 29 05:23:01 2004

El 29/07/2004, a las 12:05, Erik Nordmark escribi=F3:

>    use e.g. to say that the applications which use a particular TCP=20
> port
> This way one can incrementally try running different unmodified=20
> applications
> with AID=3DHIT and see if they work.
>
>  - get the HIT for the peer (which might be useful even when AID=3DIP=20=

> address)
>  - get the current set of known locators for the peer (for referrals=20=

> using

Yes, this could be not only useful for referrals apps, but also for=20
those which have long term communications that may be inactive for long=20=

periods. If the apps knows that it may have problems with garbage=20
collection mechanism, it can choose to store the HIP and locators in=20
the app level, so that if that info is no longer available in the HIP=20
layer, it is still available in the app. (the other option is always=20
use FQDN instead, but i guess this may provide not provide proper=20
performance for certain apps)

regards, marcelo

>
> What isn't clear to me though are the tradeoffs between having the=20
> transports
> use the HIT vs. the IP address in the pseudo-header; it would be good=20=

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

---

From: [email-masked] (Jukka Ylitalo)
Date: Thu Jul 29 06:01:01 2004

>use the HIT vs. the IP address in the pseudo-header; it would be good to
Using HITs instead of application layer identifiers AIDs (e.g. IPv4/IPv6 
addresses)
in the pseudo-header makes it possible to make IPv4 applications to talk 
with
IPv6 applications. The pseudo-header checksum is computed with the HIT in
both IPv4 and IPv6 application cases. However, this a bit advanced case, 
e.g., from the
Multi6 point of view.

I believe that it is better to have HITs in the pseudo header than IP 
address.
However, the resolver library could return either IP address or HIT for 
the application
(as mentioned earlier).

br, Jukka

---

From: [email-masked] (Pekka Nikander)
Date: Thu Jul 29 08:18:00 2004

>> use the HIT vs. the IP address in the pseudo-header...
>>
>>
> Using HITs instead of application layer identifiers AIDs (e.g. 
> IPv4/IPv6 addresses)
> in the pseudo-header makes it possible to make IPv4 applications to 
> talk with
> both IPv4 and IPv6 application cases.

As far as I can understood, that is the main difference.  When
you use EIDs (i.e. HITs) in the pseudo header, you construct the
pseudo header in an API-independent way.  That way you can, if the
app is well behaving, use different APIs at the different ends of
the communication.

Implementing dual rewriting, i.e. both at the API level above transport
and at the wedge layer below transport, is slightly more complicated
than just rewriting once, at the wedge layer.

Using IP addresses in the TCP header allow for easier opportunistic
operations, but that is really only needed for TCP SYN (or the first
UDP packet), and can be taken care as a special case.

--Pekka