Subject: Re: old GSE idea

From: David Conrad <[email-masked]>
Date: Wed, 30 Apr 2003 20:45:21 -0700

Going back through some old unanswered (sorry 'bout that) email...

On Thursday, April 17, 2003, at 04:59  AM, Iljitsch van Beijnum wrote:
>>>> I think the simplest solution is to make the lower 64 bits globally 
>>>> unique.
>>> This breaks autoconfiguration.
> MAC address collisions are not uncommon.
...
> The problem is that on a LAN, you can do DAD, but doing that world 
> wide each time you connect to the network is no fun.

Understood.  Seems to me this is one of the tradeoffs.  Globally unique 
identifiers in the lower 64 bits allows for a very simple mapping 
mechanism to map that identifier into one or more locators giving you 
both site and host multi- and re-homing.  If you cannot guarantee 
global uniqueness of those identifiers, then to get the same 
functionality, you increase the complexity of the mapping mechanism.

>> Why put location back into identity?  In my view, endpoint 
>> identifiers are 'names'.  They are a flat, undifferentiated (from the 
>> network perspective, administratively, you may want some hierarchy) 
>> identifier space.
> This is going to be a problem if you want to look these up in a 
> distributed database. We really need a hierarchy for something like 
> this.

I do not disagree that you want hierarchy.  What I am saying is that 
you do not want is to tie that hierarchy into network topology such 
that if the object changes its location in the network topology, you 
must change the identifier.  You want an administrative hierarchy 
disjoint from network topology.

>> Assuming you are asking about the multi-homed destination case,the 
>> naive approach would be to have the source core/edge boundary 
>> forwarder notice the link is down via 'traditional' methods (BGP 
>> re-convergence, ICMP network unreachable, whatever)
> Obviously this stuff isn't going to be in BGP.  :-)

Yes it can.  A locator, if we want them to scale, is part of an 
aggregate.  If an aggregate is withdrawn, a boundary forwarder 
listening (but not contributing) to a BGP feed could then choose an 
alternate locator.

> A large percentage of network problems don't generate unreachables.

For those problems a router doesn't notice, you pretty much lose, 
regardless of approach taken, unless you add the complexity of 
pseudo-connection management or somesuch.

For those problems a router does notice, it should back send 
unreachables.

> If an attacker gets to reroute your traffic, then they presumably also 
> get to route in into oblivion. So IPsec doesn't solve problems in the 
> routing system.

Right.  Placing control of a router in the hands of an attacker is 
generally a bad idea.

> This helps but doesn't really solve the problem of dead layer 2 
> networks where the IP-speaking boxes at both ends don't see there is 
> something wrong.

There are many Byzantine failure modes that are difficult to create 
solutions for.  I'm of the opinion (actually more than that, I believe 
we have empirical evidence) that if we try to solve all the problems 
we'll get nowhere.

> What I mean is that you need to implement GSE on both ends before it 
> will do you any good.

Yes.  This is, I believe, a fundamental issue that is caused by the 
layering violations created by letting applications (et al) know 
address bit structures.  As far as I can tell, there are exactly two 
solutions to this:

1) NAT, which doesn't need to be at both ends
2) map on transmit, remap back to original on receive, which needs to 
be on both ends.

I'd be ecstatic to hear of alternative solutions.

> I think hooks forward are possible by not hardcoding the exact 83 bits 
> we look at into the modified stacks but by making this more generic so 
> we can support 160 bits or 64 bits out of 128 or whatever at some 
> later date.

Yet more complexity.

> I'm not saying we should implement huge steps, but it would be good if 
> the small steps we implement get us closer to a long term goal.

We have been struggling with this issue for about a decade.  I think it 
is past time to start with a simple solution instead of trying to find 
the generic, infinitely extensible, end-all be-all solution.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 30 Apr 2003 21:22:21 -0700

Mostly just thinking out loud here (if this is still permitted)...

On Thursday, April 17, 2003, at 10:58  AM, Christian Huitema wrote:
> Even if we solved MAC address collision on a single link, you have to
> remember that a host can be multi-homed to several interfaces. Whatever
> we do to support the survival of TCP connections should also work when
> the traffic moves from interface A to interface B, e.g. from 802.11 to
> GPRS. In such cases, the two interfaces are likely to belong to
> different sites, and are like to use different interface identifiers
> (since they indeed are different interfaces). The solution of "just
> using 64 bits" will not work there.
>
> -- Christian Huitema
>

If you define the multi-homed 'site' to be the host then I think it 
will.

and

On Thursday, April 17, 2003, at 12:35  PM, Christian Huitema wrote:
> Sure. Another issue is privacy. I don't necessarily want different ISP
> to be able to correlate that two traffic flows do in fact originate 
> from
> the same hosts. In fact, privacy advocates would go ballistic if we
> mandated that.

No reason (other than efficiency) that a globally unique ID must be 
permanently assigned to an interface.  If you can verify global 
uniqueness in a reasonably rapid fashion, you just auto-generate a new 
globally unique ID per 'session'.

Rgds,
-drc