Subject: [rrg] Tony's critique of map-encap - or of router-based core-edge separation

From: Robin Whittle <[email-masked]>
Date: Tue, 25 Nov 2008 15:46:11 +1100

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-masked]
https://www.irtf.org/mailman/listinfo/rrg