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

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 29 Jul 2004 09:42:07 -0700

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]
> Sent: Thursday, July 29, 2004 6:18 AM
> To: Erik Nordmark
> Cc: Jukka Ylitalo; [email-masked]
> Subject: Re: [Hipsec] (not) using HITs as an application identifier
> 
> 
> >> 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...
> >>
> >>
> > 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.
> 
> 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.
> 

The use case I am thinking of is migrating an existing flow onto
HIP protection (maybe for mobility or multihoming reasons that
manifest themselves later).  For example, I pack up my laptop to
go home, and my suspend operation triggers exchange with my
peers to establish the (L)HIP context that allows me to resume
later from a different location.  Pekka's hesitation to this
use case is noted:
http://honor.trusecure.com/pipermail/hipsec/2004-July/000879.html
I don't know if this scenario is a strong requirement or goal
of the multi6 group, but I have seen it expressed in mailing
list discussion (don't have a reference handy).

There doesn't seem to be any advantage (only slight disadvantage?) 
to using IP addresses instead of HITs in the pseudoheader checksum,
in the following two cases:
i) full-blown HIP
ii) LHIP case, in which we are willing to wait for a single 
packet exchange to establish the context identifier tags (HITs)
to use in the pseudoheaders

The case that I think we are debating is some kind of LHIP case
for which context establishment is deferred until after some time.
That is not relevant to the scenario of IPv4 API on one side
and IPv6 API on another, since that cannot work without a wedge.
But let's assume that we start out with a normal IPv6 connection
using addresses in the pseudoheader, then we establish the wedge
context later.  After that point, I think it is not important
whether HITs or addresses are used in pseudoheader, as long as
consistency is maintained; it doesn't impact one of these
hosts' ability to migrate to another IPv6 or even IPv4 address--
the pseudoheader manipulation is simple and about the same
in either case.

Maybe the solution is to keep HIP pseudoheader unchanged, but
consider a mode of (to be defined) LHIP operation that keeps 
pseudoheader based on IP addresses, if multi6 group wants a
solution that does not require context exchange up front.
And avoid providing non-routable HITs posing as IP addresses to 
non-HIP-aware apps:
http://honor.trusecure.com/pipermail/hipsec/2004-July/000869.html

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