[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: old GSE idea
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