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

[marcelo bagnulo <marcelo@it.uc3m.es>]

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