Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

From: "Bound, Jim" <[email-masked]>
Date: Thu, 8 May 2003 09:47:12 -0400

Hi Marcelo,

Yes the HIP SPI could use the low order 64 bits but I want to read
updates from Pekka N. just sent out for arch-03.  I am also unclear the
HIP code changes to our transport layers or at the IP layers will be
done by what time frame.

As far as GSE I am very behind in mail and have to read a few things and
being quite now. But if we can change the high end 64 bits then I am
naievly unclear why MHAP architecture is not valid for solution instead
of hardline differentiation for 8+8 (my preferred term for GSE).

I am also not clear on rewrite of headers in transit is going to fly in
some cases I can think of as use case and one example is the military
tactical operations case, which for me is one area I work on and care
about as one of my roles working with users. But, in many cases they are
their own Internet and can do things that cannot be done on the public
Internet as easily simply from total network operations control.  I
believe if we rewrite headers we need to swap them into new routing
header type for IPv6 too, which will remove going to the DNS, LDAP, or
MPLS database to get back to the end node.  I view this feature as
keeping a history of location that is important.  Off the top of my I
would think we have to assume location will not change for 300
milliseconds (use this as that is what is needed for RTT for VoIP to be
successful), but we probably need to define some time_t variables for
the solution as best guess or derived time_t for when location can
change.
Probably also need to think about identity changing from say system
crash, neighbor discovery DAD collision (after the fact of solicited
node multicast which I have seen in the real world).

I know I am going far to down in details sorry :--)

/jim

> -----Original Message-----
> From: marcelo bagnulo [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 9:10 AM
> To: Bound, Jim
> Cc: Iljitsch van Beijnum; [email-masked]
> Subject: RE: GSE IDs [Re: IETF multihoming powder: just add 
> IPv6 and stir]
> 
> 
> Hi Jim,
> 
> I was not aware of this, thanks for pointing it out.
> 
> Perhaps if i rephrase it in the following way it would be acceptable?
> 
> Instead of including the HIP's HIT in the SPI, we could 
> include it in the lower 64 bits of the IP addresses. This 
> would imply that the 64 lower bits could be used as 
> identifiers and the 64 higher bits can be changed for routing 
> purposes. Perhaps this would provide the security features 
> needed for GSE to work in a stateless fashion.
> 
> Regards, marcelo 
> 
> On Thu, 2003-05-08 at 14:59, Bound, Jim wrote:
> > CGA's have to many IPR issues lets not go there here for this work 
> > please. /jim
> > 
> > > -----Original Message-----
> > > From: marcelo bagnulo [mailto:[email-masked]]
> > > Sent: Thursday, May 08, 2003 8:30 AM
> > > To: Iljitsch van Beijnum
> > > Cc: [email-masked]
> > > Subject: Re: GSE IDs [Re: IETF multihoming powder: just add 
> > > IPv6 and stir]
> > > 
> > > 
> > > On Thu, 2003-05-08 at 13:30, Iljitsch van Beijnum wrote:
> > > > On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam,
> > > marcelo bagnulo
> > > > wrote:
> > > > 
> > > > > I guess that what Brian means is that this (what you are
> > > describing)
> > > > > is not GSE anymore, since it is not stateless (which is a
> > > > > fundamental feature of GSE, as i see it)
> > > > 
> > > > No disagreement there.
> > > > 
> > > > > what you are describing sounds more like MHAP...
> > > > 
> > > > Originally, I wanted to write something that encompasses
> > > both MHAP and
> > > > GSE. But:
> > > > 
> > > >    "The original GSE and 8+8 drafts split the IPv6 address
> > > in two 64-bit
> > > >     parts. The lower part is used within the site or
> > > subnet. Routers add
> > > >     the higher 64 bits as packets leave the site. Since
> > > hosts don't know
> > > >     the higher 64 bits their correspondent will see, they
> > > must disregard
> > > >     these bits, which has the relatively minor consequence
> > > that the TCP
> > > >     and UDP pseudo header used in checksum calculations
> > > must be changed.
> > > >     A more severe consequence is that the lower 64 bits 
> must now be
> > > >     globally unique. This in turn makes it very easy to
> > > perform spoofing
> > > >     attacks, as an attacker can simply present 
> arbitrary lower bits,
> > > >     thereby assuming any desired identity, while setting
> > > the higher bits
> > > >     such that the packets are routed back to the attacker
> > > and not to the
> > > >     host identified by the lower 64 bits. This
> > > vulnerability, breaking
> > > >     autoconfiguration and, to a lesser degree, the 
> transport layer
> > > >     checksums, make adopting GSE or 8+8 unfeasible and 
> > > > undesirable."
> > > > 
> > > > Is there anyone who disagrees and feels stateless GSE is
> > > still viable?
> > > > 
> > > 
> > > I think that the statless condition of GSE is really valuable
> > > and perhaps we can come up with a solution that can preserve it. 
> > > 
> > > As you mention, security issues need to be solved somehow in
> > > order to enable this solution.
> > > 
> > > A possibility would be to use crypto identifiers such as in
> > > HIP but included in the 64 lower bits of the address (CGAs)
> > > 
> > > I guess that this could provide the security needed and it
> > > would also preserve middle boxes stateless as in GSE.
> > > 
> > > 
> > > Regards, marcelo
> > >  
> > > 
> > > > The letter combination "GSE" will not appear in the title. The 
> > > > preliminary title is "Multihoming in IPv6 by Rewriting 
> Addresses".
> > > --
> > > marcelo bagnulo <[email-masked]>
> > > uc3m
> > > 
> > > 
> > > 
> -- 
> marcelo bagnulo <[email-masked]>
> uc3m
> 
>

---

From: marcelo bagnulo <[email-masked]>
Date: 08 May 2003 19:14:49 +0200

Jim, i share all your doubts.

However, i think that the 64 lower bits of IPv6 addresses are currently
reserved for an identifier, and they are already carried in all packets
so why not just use it? (just as GSE)

I guess you can carry the identifier somewhere else, but i would say
that if we can save some bits it would be interesting

One of the problems is security, which (with my little knowledge about
the subject) can be solved usdign HIP like techniques, so just include
the HIT as the 64 lower bits of the IPv6 address

This could preserve the nice feature of GSE that the state is only
maintained in the end hosts and routers could make a stateless
translation.

But probably there are thousands things that i am missing here...

Regards, marcelo

---

From: David Conrad <[email-masked]>
Date: Thu, 8 May 2003 11:37:20 -0700

Jim,

On Thursday, May 8, 2003, at 06:47  AM, Bound, Jim wrote:
> about as one of my roles working with users.

I'd be interested in understanding these cases better.  From my 
perspective, what happens to my packet headers after they leave my 
machine is completely irrelevant as long as they get put back together 
into something that will pass the checksum on the destination host.

> I believe if we rewrite headers we need to swap them into new routing
> keeping a history of location that is important.

Why?

> node multicast which I have seen in the real world).

The appoach I've been thinking about does not touch the identity of the 
end system as determined via DAD or any other mechanism -- a packet has 
a site identity value in the top 48 bits of the destination address 
that maps into an aggregatable locator when the packet leaves the 
source site and gets remapped from the locator back into the site 
identity when it arrives at the destination site.

> I know I am going far to down in details sorry :--)

I like details when trying to figure out if a particular (arguably 
radical) approach will fly.

Rgds,
-drc

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 09 May 2003 14:10:36 +0300

Jim,

> HIP code changes to our transport layers or at the IP layers will be

HIP, in the way we implement it today, does not require any
changes to the transport layers at all, or to the IP layer
in anywhere else but at the end-hosts.  That is, of course,
not the only way to implement HIP, and it is probably also
possible to "distribute" HIP between an end-host and a
middle box, resulting in something that resembles MHAP.

In our current implementation, the only changes in the
kernel are in IPsec ESP code.  All the rest is in user
level, and the user level deamon dynamically modifies the
IPsec SPD and SA entries to implement mobility.

Implementing multi-homing will require more extensive changes
to IPsec or elsewhere in the kernel.  We are still thinking
on how to do that.  Basically, we need to implement destination
address selection somewhere in the kernel.  (At this stage
we will be ignoring the actual selection algorithm, and concentrate
on the architecture:  Where to "rewrite" the HIT into an IP
address, and how to select the right destination (and source)
address(es).)

--Pekka Nikander