Hi Tony, >-----Original Message----- >From: Tony Li [mailto:[EMAIL PROTECTED] >Sent: Monday, November 24, 2008 6:27 PM >To: Fleischman, Eric; 'Brian E Carpenter' >Cc: [email protected]; 'Noel Chiappa' >Subject: Re: [rrg] Fundamental objections to a host-based scalableroutingsolution > > > >Eric, > >|My personal belief is that I'd like us to converge soon on a >|routing-only solution. I think that it is time to begin to wrap the >|theoretical discussions up and proceed to modeling and simulation and >|limited deployment experimentation. >| >|Failing that, I would like to better understand why the RRG community >|hasn't yet converged on the desirability of map-and-encaps as a >|desirable RRG vector. > > >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. > >- 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.
I haven't been tracking the host-based discussions all that closely, but AFAICT they should be compatible with map/encap. For example, we have talked about end systems using HIP while the routers (even those within the innermost recursive instance) use map/encap. (I'm sure the scenario holds for any of the other host-based schemes also.) >- 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. The Internet today is entering a transition phase in which links with 1500 byte or smaller MTUs may soon be considered legacy equipment in need of replacement - especially within the core. Even at 1500 bytes, adding an extra 20 byte IPv4 header only adds ~1% per-packet overhead and moving out to Gigabit Ethernet jumboframe sizes (9KB) the overhead is further amortized. The idea of the MTU handling mechanisms then is to detect and provide short term interoperability for degenerate links. For example, the mechanism can automatically activate itself when an MTU-challenged link is on the path while at the same time providing feedback to the operator that a specific link is in need of replacement. As more and more degenerate links are replaced, the mechanism is used less and less. >- 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. But, the mapping system gives the ETR a means for determining the set of RLOCs from which packets that use specific EIDs may originate. This could be termed EGRESS filtering and provides a measure not available in some of the other approaches. Using egress filtering, an ETR can always consult the mapping system to determine whether an EID came from behind an acceptable RLOC. When there is spoofing, the ETR then has a way to determine which ITRs are not correctly implementing INGRESS filtering and, if corrective actions are not taken, expose the violators to the censorship of the greater community. Notice the similarities with the MTU mechanism discussed above. When the map/encaps solutions are deployed, there is incentive for everyone to "play nice" together and an incremental migration path toward the greater good. >- 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. I'm not sure I get this; one of the key features of map/encap is to arrest (and preferably reduce) routing table sizes which AFAICT it does very nicely. Is that what you mean? Thanks - Fred [EMAIL PROTECTED] > >There are probably many other issues, but these are some of the ones that >have been raised. > >Regards, >Tony > >_______________________________________________ >rrg mailing list >[email protected] >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
