Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Patrick W. Gilmore
  • Date: Mon Sep 25 09:29:06 2006

On Sep 25, 2006, at 9:06 AM, Ian Mason wrote:

ICMP packets will, by design, originate from the incoming interface used by the packet that triggers the ICMP packet. Thus giving an interface an address is implicitly giving that interface the ability to source packets with that address to potential anywhere in the Internet. If you don't legitimately announce address space then sourcing packets with addresses in that space is (one definition of) spoofing.
Who thinks it would be a "good idea" to have a knob such that ICMP error messages are always source from a certain IP address on a router?

For instance, you could have a "loopback99" which is in an announced block, but filtered at all your borders. Then set "ip icmp error source-interface loopback99" or something. All error messages from a router would come from this address, regardless of the incoming or outgoing interface. Things like PMTUD would still work, and your / 30s could be in private space or non-announced space or even imaginary^Wv6 space. :)

Note I said "error messages", so things like TTL Expired, Port Unreachable, and Can't Fragment would come from here, but things like ICMP Echo Request / Reply pairs would not. Perhaps that should be considered as well, but it is not what I am suggesting here.

Obviously there's lots of side effects, and probably unintended consequences I have not considered, but I think the good might out- weigh the bad. Or not. Which is why I'm offering it up for suggestion.

(Unless, of course, I get 726384 "you are off-topic" replies, in which case I withdraw the suggestion.)

--
TTFN,
patrick





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.