North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: private ip addresses from ISP

  • From: Patrick W. Gilmore
  • Date: Tue May 23 12:29:13 2006 
On May 23, 2006, at 10:47 AM, Robert Bonomi wrote:


Really? You really want TTL-E messages with RFC1918 source addr? Even
if they're used as part of a denial of service attack? Even though
you can't tell where they actually came from?
"Can be" is not sufficient (in and of itself, that is) reason to block.
_Anything_ "can be" used as part of a DOS attack.

TTL-E messages _do_ have legitimate function in network management.
TTL-E messages _can_ originate from RFC1918 space, addressed to 'public
internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'?
Ever use it where packets went across a network using RFC1918 internally?
Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses
network?

If you don't like that example, substitute "host/network unreachable", or
'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet. If you
don't get those messages back, you can't communicate.
Robert, to quote your own words: "You're either ignorant of network architecture, or trying to pick fights."

TTL-E messages "can" originate from any IP address. They should not. And allowing packets with RFC1918 source addresses to leave your administrative domain is bad network administration (not to mention going against the RFC). There are no loopholes here, you are being a bad 'Netizen if you pass packets with bogon source addresses to your peers. Period.

If you have issues where you need to send DNF or other messages to peers, it is incumbent upon _you_ to ensure those messages originate with valid source addresses.

It is perfectly acceptable - even good network hygiene - for other networks to drop any packets with bad source addresses at their boarder. You cannot expect them to accept your packets just because you don't know how to architect a network properly. If that breaks traceroute or PMTU-D or anything else, that is your fault, not theirs.

Please read RFC1918 again, as well as BCP38. And perhaps a book on networking.

--
TTFN,
patrick