New router feature - icmp error source-interface [was: icmp rpf]

Richard A Steenbergen ras at
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.  
> _configuration_guide_chapter09186a00800ca590.html#5406

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>
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

More information about the NANOG mailing list