"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.
You need to learn to read. I said "malicious content", not 'used in a malicious fashion'. Packets that could have legitimate meaning should be passed on. Packets that _cannot_ have legitimate meaning should not be.
not at all. You're either ignorant of network architecture, or trying to pick fights. I was talking about a situation where a customer machine of a network that uses RFC1918 addresses internally starts sending malicious packets with a RFC1918 source address that _matches_ that of one of the *in*use* addresses on the service-provider network. AND the service-provider does not do ingress (from the customer) or egress (to the customer) filtering of RFC1918 address-space. Customer A's machine starts attacking Customer B, C, D, E, F ...; those ill-informed customers don't null-route outbound RFC1918 addresses; you get an 'inadvertent' smurf attack on the NSP resource. It's comical, because the ISP's 'bad practice' facilitated the attack on the ISP. "Traceroute", by the way, *is* one of those 'legitimate' cases for which RFC1918 source-address packets should be allowed across network boundaries. Proper "good net neighbor" egress filtering of RFC1918 source addresses takes a number of separate rules. Several 'allows', followed by a default 'deny'.
Not sure to what degree it's the NSP's fault vs. the router vendors', but yes.
Can't imagine why you think it might be the fault of the router vendor. Can't imagine why think it is somebody's "fault".
If everybody did _egress_ filtering of 'cannot possibly be legitimate' traffic, ingress filtering of that traffic would not be necessary. Unfortunately, not everybody does, so ingress filtering _is_ necessary. 'ingress' filtering is self-defense. 'egress' filtering is about 'being a good net neighbor'.
Robert Bonomi wrote:
I guess this means that providers who utilize rfc1918 along their hops should make an effort to ensure these addresses are not used for icmp messages or translate these addresses when they source icmp. Understandably, translation on providers networks is not always feasible. A feature on routers that sourced icmp packets to be told specificaly which address of the router to source it from would also help.
Folks are sounding as if they'd never 'traceroute'd THROUGH a set of unroutable IP addresses. I have seen cases where my 'traceroute' looked like this [when I've had the patience to not hit Interrupt at the first sign of stars]: 1 1 ms 1 ms 1 ms router.here 2 10 ms 10 ms 10 ms router.there 3 * * * 4 * * * 5 * * * 6 * * * 7 80 ms 80 ms 80 ms router.over.yonder 8 90 ms 90 ms 90 ms host.over.yonder It works! -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
On Tue, May 23, 2006 at 11:55:56AM -0400, Joe Maimon wrote: ...
Its also quite annoying to wait for each hop to timeout.
Well, yes. ;-} But as someone hinted, that's purely a problem with my own psyche, which I do [to some degree] control. OBTW, the 'ad hominem' attacks starting up in this thread should really be deprecated [speaking of which]. -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Really? Do you have those rules on your network? Any reason why you didn't post the operational details on this operational list? Have you ever read your peering agreements or service contracts to see if filtering of RFC 1918 sourced traffic is specifically covered by them? If it is not covered by the contract, then why should your peers/upstreams filter it? Another good question is whether or not every service contract and peering agreement should contain unique text or whether there should be some community-developed best practices statement that could be plugged in by reference. For instance, software publishers can publish their software under the terms of the GPL without including the full text of the GPL verbatim in their software license. Does NANOG have a role in developing some best practices text that could be easily imcorporated into peering agreements and service contracts? --Michael Dillon
On Tue, May 23, 2006 at 04:22:26PM +0100, Michael.Dillon@btradianz.com wrote: ...
RFC 2267 -> RFC 2827 == Best Current Practice (BCP) 38 RFC 3013 == BCP 46 RFC 3704 == BCP 84 Are these followed? -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
No, the IETF BCP's are not followed and part of the reason is that they are not written by network operators but often by vendors and academics. The fact is that the collective of network operations people (in North America at least) does not have any agreed set of BEST OPERATIONAL PRACTICES. There are various camps that promote various sets of rules which are often overly simplistic and cannot be 100% adhered to in practice. What we really need is a forum to discuss best operational practices and resolve all these various differences in opinion systematically. The end result should be a set of best practices that people really can follow with no exceptions. Of course this means that the best practices must incorporate various exceptions to the simple rules and explain when those exceptions are and are not appropriate. So again, I ask the question: Is NANOG an appropriate forum to develop some best practices text that could be incorporated into service agreements and peering agreements by reference in the same way that a software licence incorporates the GPL by referring to it? --Michael Dillon
On May 24, 2006, at 2:05 AM, Michael.Dillon@btradianz.com wrote: <snip>
Ah, I think we all assumed you were kidding when you asked that! While I think NANOG *should* be the appropriate forum, I don't really think it will be -- there are too many personal agendas -- getting the community to agree on *anything* these days appears to be a losing proposition.... I suspect that a post suggesting we replace IP with a piece of wet spaghetti would: a: Get n replies agreeing b: Get n replies disagreeing c: Possibly generate a post that is trying to be useful. d: A fish (not a fish anything, just a random posting not related to anything on topic) e: Spawn a thread screaming "Troll" f: Get 2n replies asking if that will run on vendor X g: Get 2n replies suggesting that an alternate root / better SPAM detection / would fix all our woes h: Generate n^2 ad hominem attack threads. i: Be sidetracked into a request for a contact for company Y j: Get misinterpreted [supporting | blasting] someone's pet theory / idea / etc Even the fairly simple question of whether a network should emit packets with RFC1918 sourced packets (a topic I am declining to comment on) exhibited many of the above. While I think having "some best practices text that could be incorporated into service agreements and peering agreements" would be great I suspect this isn't the forum to generate such a thing -- unless it looks like: Best Common Practices (please circle appropriate field): 1: Interconnecting networks (agree to always) / (agree to never) / (agree to sometimes) emit packets with RFC1918 addresses 2: Interconnecting networks ( shall) / (shall not ) run some form of RPF 3: Interconnecting networks (will) / (won't) / (might) randomly depeer ... etc. Having "some best practices text that could be incorporated into service agreements and peering agreements" would be great -- lets how about setting up a forum for this? Warren (who is feeling very grumpy and cynical this morning -- and might take all the above back once the coffee sinks in)
--Michael Dillon
-- "Real children don't go hoppity-skip unless they are on drugs." -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)
Date: Wed, 24 May 2006 15:26:15 -0400 From: Valdis.Kletnieks
...at which point someone interjects that an octopus is a mollusk... Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On May 23, 2006, at 10:47 AM, Robert Bonomi wrote:
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
participants (9)
-
Brian Johnson
-
Edward B. DREGER
-
Joe Maimon
-
Joseph S D Yao
-
Michael.Dillon@btradianz.com
-
Patrick W. Gilmore
-
Robert Bonomi
-
Valdis.Kletnieks@vt.edu
-
Warren Kumari