New router feature - icmp error source-interface [was: icmp rpf]
Richard A Steenbergen
ras at e-gerbil.net
Mon Sep 25 23:40:43 UTC 2006
On Mon, Sep 25, 2006 at 04:33:18PM -0700, David Temkin wrote:
> C and J both already have a similar feature, however I'm not sure
> whether or not they apply to ICMP. They both support PBR for locally
> originated packets - which, should include if the thought process is
> correct, ICMP. Perhaps someone with some time to waste can verify this
> in a lab.
The actual path taken for the ICMP generated by the router does not
matter, we're just talking about the source address selected by the
router. The only reasons that the source address (which reveals a real IP
address on a router) matters at all for ICMP error responses are:
* So traceroute works (current industry standard behavior is to use the
ingress interface IP so you see the forward path in traceroute, not the
reverse path, which may be asymmetric.
* So your replies don't get thwacked by people doing uRPF strict (i.e.
they must come from announced IPs or people doing strict strict with no
exception filtering capabilities will block the traceroute responses).
* Optionally, allowing naive tools like MTR to ping the IP they discover
via traceroute, lest weenies flood your noc with "I'm pinging 10lolz!"
Revealing your interface IPs carries all kinds of DoS/security risks with
it, since there are a great many routers out there without good control
plane policing functionality (and even some of those that have it, don't
really have it :P). Since there is really no legitimate need for people
from the outside world to ever communicate with your real interface IPs at
all (with the exception of some rate limited ICMP echo/reply due to
aforementioned mtr weenies), having the option to hide those real
addresses completely in ICMP source address selection is a very good thing
for enhancing network security.
As I said you can accomplish part of this hack with primary/secondary IPs
on interfaces. You can also accomplish some level of filtering by
numbering your interfaces out of common blocks which are filtered at your
various borders/edges. It's still a pain in the !(*#&*, especially if you
number your links out of any "regional blocks" to cut down on asymmetric
routing confusion, or have any number of peers who provide /30s from
their own IP space.
Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
More information about the NANOG