My opinion is fairly clear on this topic. If I can't return it, I'm not going to accept it.

AMEN! I get these with frequency also on my edge logs. I just let my own filters catch them. It differs each month also on the ammount of traffic I get from these address blocks. G. Jared Mauch writes:

On Thu, Sep 04, 2003 at 06:37:57AM +0000, Christopher L. Morrow wrote:

...

On Thu, 4 Sep 2003, Matthew Sullivan wrote:

...

More whining and bitching from me ... sorry...

So who thinks allowing anyone to route to or from IANA Reserved blocks (Bogons) is acceptable?

Technically these packets are 'routed' correctly, they are perhaps not filtered, but thats another story entirely.

...

A few captured packets....

15:42:41.434384 1.6.145.24.1116 > 203.101.254.254.53: S -- snip --

Is there any need to route bogons? Is there any reason why it cannot be filtered (I appreciate 224-239 is a different story)....?

At the edge, very near the originating host there is no reason not to filter these, if you find the sources you might consider asking them why they didn't filter these for you...

I would ask your upstreams to filter out such "worthless" traffic. My opinion is fairly clear on this topic. If I can't return it, I'm not going to accept it.

Fairly simple policy.

- jared

...

...

These packets were all originated on the other side of the Pacific to Telecom NZ.

and they travelled well apparently.

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

Gerardo A. Gregory Manager Network Administration and Security 402-970-1463 (Direct) 402-850-4008 (Cell) ------------------------------------------------ Affinitas - Latin for "Relationship" Helping Businesses Acquire, Retain, and Cultivate Customers Visit us at http://www.affinitas.net

(i know i said i wouldn't comment on this, but that was yesterday.)

...

At the edge, very near the originating host there is no reason not to filter these, if you find the sources you might consider asking them why they didn't filter these for you...

i've asked. answers are usually of the form "huh? what's that?" unless it's a relatively smart person with the misfortune to be working at a bankrupt backbone with short staff and no equipment budget in which case the answer is some variation of "well that's fine at the edge but not in the core". in fact, see above :-).

And what is the reason to not filter these in the backbone? Full spoof protection at some levels is near impossible. However, bogon filtering is not.

loose-rpf is a start. none of the packets shown below came to me from a peer or transit who runs loose-rpf in their backbone. however, loose-rpf only solves a small part of the source address ambiguity problem, since the niks can still source their zwil from (other people's) routed cidr blocks. with respect to the trace below, this is one f-root out of about 25, and while we normally have to sanitize the source addresses of our traces before we make them public, as you can see it's really not nec'y for this one: #sfo2a.f:i386# tcpdump -n src net \( 10 or 172.16/12 or 192.168/16 \) tcpdump: listening on fxp0 16:34:44.982330 172.20.1.1.3436 > 192.5.5.241.53: 4072[|domain] 16:34:45.027735 172.16.1.13.53 > 192.5.5.241.53: 21659 A? updatekeepalive.mcafee.com. (44) 16:34:45.053542 10.10.220.10.32769 > 192.5.5.241.53: 52143 NS? . (17) (DF) 16:34:45.084594 10.23.1.40.1024 > 192.5.5.241.53: 7932 NS? . (17) 16:34:45.832620 192.168.0.2.1133 > 192.5.5.241.53: 8690 A? g-images.amazon.com. (37) 16:34:45.837360 192.168.0.2.1133 > 192.5.5.241.53: 12795 A? g-images.amazon.com. (37) 16:34:45.841734 192.168.0.2.1133 > 192.5.5.241.53: 512 A? g-images.amazon.com. (37) 16:34:45.846085 192.168.0.2.1133 > 192.5.5.241.53: 6665 A? g-images.amazon.com. (37) 16:34:45.850969 192.168.0.2.1133 > 192.5.5.241.53: 12820 A? g-images.amazon.com. (37) 16:34:45.871451 192.168.0.63.1105 > 192.5.5.241.53: 84 PTR? 8.0.168.192.in-addr.arpa. (42) 16:34:45.924779 10.2.3.39.1030 > 192.5.5.241.53: 57 A? www.symantec.com. (34) 16:34:45.926582 10.2.3.39.1030 > 192.5.5.241.53: 6208 A? time-a.timefreq.bldrdoc.gov. (45) 16:34:45.931745 10.2.3.39.1030 > 192.5.5.241.53: 12361 A? time-a.timefreq.bldrdoc.gov. (45) 16:34:46.096376 192.168.1.113.32830 > 192.5.5.241.53: 18162 [1au] MX? networkoptservices.net. OPT UDPsize=4096 (51) (DF) 16:34:46.098370 192.168.1.113.32830 > 192.5.5.241.53: 9520 MX? activision.info. (33) (DF) 16:34:46.801114 172.30.60.229.53 > 192.5.5.241.53: 1400 SOA? 150.118.162.in-addr.arpa. (42) 16:34:46.828786 192.168.104.10.1097 > 192.5.5.241.53: 1290 A? images.daemon.sh. (34) 16:34:46.830733 192.168.104.10.1097 > 192.5.5.241.53: 11542 A? images.daemon.sh. (34) 16:34:46.832704 192.168.104.10.1097 > 192.5.5.241.53: 1305 A? images.daemon.sh. (34) 16:34:46.833516 192.168.104.10.1097 > 192.5.5.241.53: 13600 A? images.daemon.sh. (34) 16:34:46.834898 192.168.0.2.1133 > 192.5.5.241.53: 10777 A? g-images.amazon.com. (37) 16:34:46.834905 192.168.104.10.1097 > 192.5.5.241.53: 15659 A? images.daemon.sh. (34) 16:34:46.839097 192.168.0.2.1133 > 192.5.5.241.53: 544 A? g-images.amazon.com. (37) 16:34:46.843399 192.168.0.2.1133 > 192.5.5.241.53: 552 A? g-images.amazon.com. (37) 16:34:46.848108 192.168.0.2.1133 > 192.5.5.241.53: 14902 A? g-images.amazon.com. (37) 16:34:46.853027 192.168.0.2.1133 > 192.5.5.241.53: 6718 A? g-images.amazon.com. (37) 16:34:46.898737 192.168.203.7.1111 > 192.5.5.241.53: 3150 A? microsoft.com.mailwell.com. (44) 16:34:46.900221 192.168.203.7.1111 > 192.5.5.241.53: 5206 A? microsoft.com.mailwell.com. (44) 16:34:46.926334 10.2.3.39.1030 > 192.5.5.241.53: 4182 A? www.symantec.com. (34) 16:34:46.926721 10.2.3.39.1030 > 192.5.5.241.53: 2143 A? www.symantec.com. (34) 16:34:47.018181 192.168.100.24.1102 > 192.5.5.241.53: 16356 A? sbasupport. (28) 16:34:47.828700 192.168.104.10.1097 > 192.5.5.241.53: 15668 A? rsthost1.ods.org. (34) 16:34:47.829026 192.168.104.10.1097 > 192.5.5.241.53: 5439 A? rsthost1.ods.org. (34) 16:34:47.892288 10.81.0.22.1069 > 192.5.5.241.53: 6014 SOA? 0.81.10.in-addr.arpa. (38) 16:34:47.905254 192.168.128.4.53 > 192.5.5.241.53: 614 PTR? 30.128.168.192.in-addr.arpa. (45) 16:34:47.919143 10.1.0.3.53 > 192.5.5.241.53: 26579 A? www.symantec.com. (34) 16:34:47.926353 10.2.3.39.1030 > 192.5.5.241.53: 12388 SOA? 12.2.10.in-addr.arpa. (38) 16:34:47.981405 172.20.1.1.3436 > 192.5.5.241.53: 8189[|domain] ^C 3205 packets received by filter 0 packets dropped by kernel -- Paul Vixie

On donderdag, sep 4, 2003, at 18:51 Europe/Amsterdam, Owen DeLong wrote:

Source address-based filtering in the backbone is expensive and, in many cases, non-feasible.

And, of course, unnecessary. Everything in the core must have gotten there over a border towards some external network or an edge towards a customer (counting own servers and stuff as "customer" too) so if filtering is done there, no need to repeat it in the core. BTW, from what I can tell on a pretty old/slow Cisco box, uRPF makes packet forwarding take about 10% more CPU, which is the same as a short standard access list (which can only look at source addresses). A short extended access list takes around 20% more CPU.

] I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there ] was some lesson learned from this, no? Yep, and the lesson is: Lots of folks do a poor job of network management. :( Keeping up with the bogons can be automated, see: <http://www.cymru.com/BGP/bogon-rs.html> -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

Do you have a reference page as to what platforms/releases/release trains that is being applied to? Seems like it might be a handy list to have bookmarked. :) Thanks, Adam Debus Linux Certified Professional, Linux Certified Administrator #447641 Network Engineer, ReachONE Internet adam@reachone.com ----- Original Message ----- From: "Sean Donelan" <sean@donelan.com> To: "Rob Thomas" <robt@cymru.com> Cc: "Christopher L. Morrow" <chris@UU.NET>; "NANOG" <nanog@merit.edu> Sent: Thursday, September 04, 2003 10:14 AM Subject: Re: What were we saying about edge filtering?

On Thu, 4 Sep 2003, Rob Thomas wrote:

...

] I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly

there

...

] was some lesson learned from this, no?

Yep, and the lesson is: Lots of folks do a poor job of network management. :(

Keeping up with the bogons can be automated, see:

<http://www.cymru.com/BGP/bogon-rs.html>

It gets even worse. Cisco has hard-coded the list of Bogons into some of its latest low-end IOS versions as part of its "auto-secure" feature. Yes, Cisco includes warnings in the manual the user should check the official list at IANA; but I also know the power of defaults. People upgrade their IOS versions even less often then they update their Windows boxes. So we're going to see chunks of the net blocked depending on the release date of versions of IOS.

Terry Baranski wrote:

Is this progress? Or is this something that "seemed like a good idea at the time"?

I would like to refer to my previous statement on this matter. "The road to hell is paved with good intentions." The other favourite which applies; "Ignorance often translates to increased sales." Pete

[multiple response] Christopher L. Morrow wrote:

I'm going to take a stab at: The next 69.0.0.0/8 release? Certainly there was some lesson learned from this, no?

I don't buy it, Chris. Are you saying that a large backbone provider can't maintain up-to-date bogon filters? In fact, I'd say they would be better at it, and if they were using the filters, then there would be less need for their customers to apply the filters and we'd have less bogon issues in the future. Owen DeLong wrote:

Source address-based filtering in the backbone is expensive and, in many cases, non-feasible.

Most vendor equipment is easily capable of handling bogon filtering using any number of methods. This is particular true when filtering packets that are not announced bogons (such as most dDOS spoof attacks), even if announced bogon packets are allowed through. -Jack