|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: RFC 1918
[ On Tuesday, July 18, 2000 at 20:24:58 (-0400), Richard A. Steenbergen wrote: ] > Subject: Re: RFC 1918 > > Unroutable means you can't reach where the packets came from, not that the > packets can't reach you. Just because you can't reply doesn't mean someone > shouldn't be allowed to send you an informative piece of information, like > a traceroute ttl-exceed. Uh huh, and since that packet contains a source address that's *PRIVATE* and replicated a zillion times over in many unfortunately visible nooks and crannies of the Internet, not to mention probably replicated on the privately visible parts of the network you're doing the traceroute from, the information it contains is, at the very least, confusing. Furthermore if indeed you are using that number on your localy *private* network, and if it's any of several ICMP types, it can affect not only the connection it's reporting on, but perhaps other unrelated connections within your *private* network if it is malicious and sufficiently knowledgeable about your network architecture. > Obviously its not prefered by anyone to have RFC1918 sourced packets out > there, mainly because they're not all that useful. But IMHO your belief > that these are "Illegal bad wrong packets which should never appear on > that interface" is incorrect. Come again!?!?!? Since by the dubious virtues of RFC1918 I'm allowed to use such numbers on my internal *private* network(s), having them appear in any form on any of my external interfaces is definitely 100% illegal in my operations, just as it is illegal for any packet to appear on any of my external interfaces when it claims to have come from one of my internal networks > As for the DoS issue, as I explained to someone in private email, there > are three distinctions you can break a filter into: > > 1) It provides security > 2) It stops an attack > 3) It reduces an attack > > RFC1918 filters obviously do not provide security. Lack of RFC1918 filters open many vulnerabilities for anyone who might choose to use those numbers internally, so they do in fact provide security just as all anti-spoof filters do. > RFC1918 filters obviously do not "stop" any attacks outright. > RFC1918 filters reduce the impact of attacks which can spoof by 3.19% Exactly, which is why RFC1918 packets are only one part of the necessary anti-spoof filters that all good network neighbours *must* learn to deploy these days. > I really don't see why you're wasting your time on it. Actually I really > don't see why we're waiting our time argueing, this thread has long > outlived its usefulness. But IMHO the RFC1918-nazi is not needed. :P Sad to see you feel that way.... -- Greg A. Woods +1 416 218-0098 VE3TCP <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|