Excerpts from Tony Li on Mon, Nov 24, 2008 06:27:00PM -0800: > There is a portion of the community (significant, IMHO) that feels that > there are significant drawbacks to the map-&-encap strategy. While I can't > claim to represent all of them or even a significant breadth of their > opinions, there are some issues that have been raised.
I think you've raised some good ones but could have filtered them by how significant they are. > - Map-&-encap doesn't solve the problem where it truly occurs: at > the host. The convolution of locator and identifier happens > precisely because the transport layer has reused the address as part > of the connection identifier. Until we change this, we're simply > band-aiding around the problem. And band-aids really aren't the way > to create a lasting architecture. Please note that this also > implies that routing-only solutions aren't the correct direction. That problem is the need to have an identifier, usable by session control, that is independent of topological location. That is a different problem from routing and addressing scaling in the core. Some approaches to endpoint-based loc/id separation also indirectly reduce the routing scaling problem, but that doesn't mean that something that attacks routing scaling directly is not attacking "the problem". You can run a network-based solution for routing scaling and a host-based solution for separate session-usable identifiers separately. Architecturally that could be cleaner. Yes we should ask if host-based approaches to loc/id separation, or maybe NAT-based ones, make map-and-encap irrelevant. No, we shouldn't say that attacking routing scaling directly is attacking the "wrong" problem. > - Map-&-encap comes with significant overhead. It adds another > network layer header, and some additional per packet overhead. In > changing the MTU, it requires additional mechanisms that some (tho I > appear to be alone in this ;-) find concerning. Yes. > - Map-&-encap creates some attack vectors. If an attacker sends you > a packet from a forged (and possibly random) EID, and that causes > you to respond and perform a mapping lookup on the forged EID, then > the attacker can cause you to fill your mapping cache and thus > create a significant performance issue. While it's already > difficult in the Internet today to trace forged source addresses, it > would seem like tracking forged EIDs will be even harder, as they > are likely to come with addresses from forged ITR addresses. There > are probably ways to address this, but they would seem to come with > Even More Mechanisms. I owe you a response on that. Some ideas have been floating around. As you can see I'm somewhat behind. :-p > - Is virtualization really the right approach? It's been noted that > map-&-encap is basically equivalent to running the entire Internet > inside of a VPN, where the mapping function conveys the edge of the > 'primary' infrastructure that terminates the VPN tunnels. Some find > it architecturally disquieting to run our most essential function > virtually when we find that we cannot run it natively. Map-and-encap is not a VPN by any means, nor is there anything virtual about it. Routing, forwarding, and addressing are all common. There is only one kind of packet crossing the core. This isn't about "overlay", it's about "separation". _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
