Re: old GSE idea

[Iljitsch van Beijnum <iljitsch@muada.com>]

On woensdag, apr 16, 2003, at 20:28 Europe/Amsterdam, David Conrad 
wrote:

> I think the simplest solution is to make the lower 64 bits globally 
> unique.
This breaks autoconfiguration. I think we need at least 40 bits for the 
organization ID so that leaves just 24 bits for link-local use, which 
isn't enough to make it possible for hosts to select a fixed address 
without significant risk of address collisions. Not a fatal flaw I 
guess, but not great either.

> Treat the endpoint ID as a key into a distributed database of one or 
> more locators associated with that endpoint ID.  The endpoint need not 
> (ever) know the full destination address, that is, the DNS lookup of 
> the end point host name would only return (top 3, lower 80).
Why not simply have the full addresses in the DNS?

> The core/edge boundary packet forwarder takes the destination end 
> point identifier of the outgoing packet, looks up (simple hash would 
> work) the locators associated with that end point, picks one of the 
> locators based on some administrative policy (e.g., AS hop count), 
> rewrites the locator into the destination address and sends the packet 
> on its way.
So what happens when a link goes down?

Also we probably want this to happen either in the host or at the edge 
(not the core, that would be another explosion of state) as per site 
policy and not just at the edge.

> > As long as we're flying up levels, why not go up one more and compare 
> > different multiple-PA approaches?
> One reason I like the GSE concept is that it removes the topology 
> change induced renumbering problem from end sites, providing (in 
> addition to multi-homing), number portability, at least from the 
> perspective of end users
Other solutions in this area provide the same benefit without breaking 
link local behavior, and I would (eventually) like to go even further 
and completely remove the addresses from the user experience: just use 
names.

> The other approaches that do not separate locator from identifier 
> don't address this problem (to my knowledge, pointers to documents 
> where they do greatly appreciated).
See Michel Py's MHAP draft. There are some difficult areas there, but 
the basic idea is worthwhile. One thing that is very attractive is that 
it moves standard IPv6 hosts behind a middlebox that handles all 
multihoming processing. The downside is that it requires this, but I'm 
confident that we can move MHAP or MHAP-like processing to hosts if 
desired.

> From my perspective, the "real" problems with the GSE concept, at 
> least historically, have been dealing with the distributed endpoint 
> ID/locator map and the fear that GSE would make insertion attacks 
> easier.  Given the state of routing security (that is, the ability to 
> insert pretty much any prefix into the routing system) I personally do 
> not believe the latter concern is significantly worsened by something 
> like GSE and, in any event, this issue would be addressed by 
> deployment of IPSEC.
How is IPsec going to help you if the packets are rerouted over the 
null0 interface?

> With respect to dealing with a distributed database, there are two 
> broad approaches, pushing the data out (e.g., the way routiing tables 
> are propagated) or pulling the data in (e.g., the way the DNS works).  
> Both have advantages and disadvantages, but this given existence of 
> solutions to this problem, this part seems solvable to me.
Don't forget about the actual failover. Also quite solvable, but not a 
trivial problem.

The problem I have with GSE and its derivatives is that it is 
self-contained and doesn't provide hooks either forward or backward. It 
would be great if it could be part of a bigger picture, where we can 
upgrade from what we have today, to something a bit better, to GSE++, 
to a clean architecture where we really get to drop in new protocols 
for each layer like the OSI guys always promised we could.