Hi Tony, In: Re: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000266.html
you wrote, in part: > - 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. You are not alone in finding the MTU problems caused by map-encap a concern. There is a solution, I think, for Ivip at least: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ but it requires considerable complexity in the ITR and some complexity in the ETR. The two forwarding approaches: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ resemble map-encap, but have no encapsulation overhead and no PMTUD problems. These require upgrades to the FIBs of DFZ routers. From what I know about the FIBs of modern routers likely to be used in the DFZ from 2011 onwards, the exact method of forwarding the packet is not fixed in silicon, but is defined in the firmware. So AFAIK, these two upgrades to DFZ routers could feasibly be introduced over a period of a few years, if Cisco, Juniper (anyone else?) created suitably modified firmware. The changes to forwarding are not complex, and this would probably be a much lower total effort than designing and deploying the more complex ITRs which are needed to handle the PMTUD problems. Creating such firmware, or stating that it could be done, would also enable the router manufacturers to demonstrate the inherent flexibility of their products. :) > - 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. This is true for map-encap or any router-based core-edge separation scheme with something like ITRs, ETRs and mapping system. So it also applies to Six/One Router and Ivip with forwarding, rather than encapsulation. ITR caches could be overloaded with this stuff. It would be up to the ITR, and caching query servers in Ivip, to flush their cache in a way which made most sense. At least with Ivip, the mapping is a much simpler body of information than with the other schemes, since it is simply a single IP address, while the others use multiple IP addresses, priorities etc. > 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. Not with Ivip's encapsulation approach, in which the outer header's source address is the same as the inner packet's source address. The ETRs drop any packet where these do not match. So the ISP's existing border router filtering on packets arriving from other networks continues to work fine and is automatically applied to the source address of encapsulated packets arriving from external ITRs (or from attackers): dropping packets with source address matching an internal address of the ISP's network. Ivip's forwarding approaches have no such problem either - there is no encapsulation header. The ITR and DFZ routers forwards the packet according to extra bits in the existing header. The ISP border routers see the source address directly and continue their current filtering arrangements. > There are probably ways to address this, but they would seem to > come with Even More Mechanisms. With LISP, APT and TRRP, yes - filtering in each ETR, which is expensive and unwieldy. > - 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. Something needs to be added to the Internet's architecture. I think the best approach would be core-edge separation along the lines of Ivip's two forwarding approaches. My objections to pushing responsibility for multihoming etc. to all hosts are mentioned in recent messages. The second best approach would be map-encap along the lines of Ivip, with it being constructed for migration to forwarding whenever the DFZ routers are suitably upgraded. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
