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

["Bound, Jim" <Jim.Bound@hp.com>]

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:marcelo@it.uc3m.es] 
> Sent: Thursday, May 08, 2003 9:10 AM
> To: Bound, Jim
> Cc: Iljitsch van Beijnum; multi6@ops.ietf.org
> 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:marcelo@it.uc3m.es]
> > > Sent: Thursday, May 08, 2003 8:30 AM
> > > To: Iljitsch van Beijnum
> > > Cc: multi6@ops.ietf.org
> > > 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 <marcelo@it.uc3m.es>
> > > uc3m
> > > 
> > > 
> > > 
> -- 
> marcelo bagnulo <marcelo@it.uc3m.es>
> uc3m
> 
>