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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 8 May 2003 08:59:40 -0400

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
> 
> 
>

---

From: marcelo bagnulo <[email-masked]>
Date: 08 May 2003 15:10:21 +0200

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

---

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

Marcelo,

> features needed for GSE to work in a stateless fashion.

I am afraid such a practice would fall within the
claims of the patent I know about.  Basically, the
widest claim cover anything that effectively does

   interface id = hash(public key | anything)

where | is concatenation (in any order).  Thus, to
circumvent that you both have to split the IPv6 address
into something else but 64+64, and call the right hand
(identifier) part something else but interface id.  And
even then I am not sure if you would be done.

But IANAL, so go and check the patent.  It can be found in
the British patent database fairly easily.

Then there is another problem.  64 bits is not quite enough
to be secure in the future.  See draft-aura-cga-00.txt for
the detailed analysis and a suggestion on how to work around
that limitation.

--Pekka Nikander