[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]
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
On Thu, 2003-05-08 at 15:47, Bound, Jim wrote:
> 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
> >
> >
--
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m