RE: How many backbones here are filtering the makelovenotspam scr eensaver site?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From: Justin Ryburn [mailto:justin@ryburn.org]
Sent: Thursday, December 02, 2004 4:18 PM
To: Chad Skidmore; nanog@merit.edu
Subject: Re: How many backbones here are filtering the
makelovenotspam scr eensaver site?

This is what scares me. Who determines the "bad guys?" I
don't know anyone over at Lycos so I have no trust (or lack
there of) in Lycos. Who is to say that Lycos won't decide
next month that Yahoo, Google, MSN, _insert your own network
here_ are "bad guys" and point the screen saver at them. Are
they likely to do it? Probably not; it would be a PR
nightmare for them. But who is to stop them? What if they
don't go so extreme and just point the screen saver at "gray
hat" hosts who are open relays or something?

I agree 100%. I believe that I get to decide what is or is not "ok"
traffic on my network. I define that in my AUP and customers agree
to and understand that when they buy service from me.

My opinion (not that anyone asked) is retaliation is childish
and unprofessional. I remember the Internet before Spam,

Also agree 100%. If there is traffic hitting my network that I don't
believe is "ok" then I can choose not to carry that traffic on my
network. It doesn't give me the right to attack the originator of
that traffic or the person that I "believe" to be the originator of
that traffic.

That's why I am a very firm believer in the power of "ip route
x.x.x.x y.y.y.y null0" command. :slight_smile: Makes the problem go away for me
(for the most part) and doesn't cause anyone else any pain as a
result except my customers, who agreed to let me use that power when
they purchased service from me.

botnets, DDOS, etc.
and dream of a day when these are "under control" again just
as much as the next geek. However, stooping to the level of
the miscreant is not the answer to the problem in my opinion.

Justin Ryburn
justin@ryburn.org

"Dance like nobody's watching; love like you've never been
hurt. Sing like nobody's listening; live like it's heaven on
earth."
  -- Mark Twain

- ----------------------------
Chad E Skidmore
One Eighty Networks, Inc.
http://www.go180.net
509-688-8180

Chad,

That's why I am a very firm believer in the power of "ip route
x.x.x.x y.y.y.y null0" command. :slight_smile: Makes the problem go away for me
(for the most part) and doesn't cause anyone else any pain as a
result except my customers, who agreed to let me use that power when
they purchased service from me.

I would rather prefer the traffic not hitting anything behind my
transit/peering machinery at all, so the "ip route" alone doesn't
make me happy, I also have to adjust ingress ACLs every once in a
while.

And while Cisco's autosecure feature looks fine in most parts (saves
a lazy overworked bum like me a lot of typing), it does not do much
good - in my opinion - when it comes to bogon filtering. I prefer
knowing what the filter looks like, and it does not seem to give me
that, nor any way of modifying the list (correct me if I'm wrong).

I like the simplicity of, e.g., the Cymru route-server project, giving
me bogon prefixes I can then blackhole, and giving me the opportunity
to filter those prefixes (and hence my filters). Unfortunately, this
only works for egress, and I still have to look after my ingress ACLs.

Oh, and of course this is only a good thing as long as the Cymru folks
can be trusted...

Cheers,
  Elmi.

See pages 9, 10 and 12 of the PDF I posted. Specifically, it
sets up: "ip access-list extended autosec_iana_reserved_block", and "ip
access-list extended autosec_complete_bogon" which you of course can
change like any other ACL.

-Hank

Hank :slight_smile:

> that, nor any way of modifying the list (correct me if I'm wrong).

See pages 9, 10 and 12 of the PDF I posted. Specifically, it
sets up: "ip access-list extended autosec_iana_reserved_block", and "ip
access-list extended autosec_complete_bogon" which you of course can
change like any other ACL.

Yup, read the last bits now, so at least that holds no more fear.
Unfortunately one still has to mop all routers every time.

Thanks for correcting that,
      Elmi.

Hank Nussbacher wrote:

And while Cisco's autosecure feature looks fine in most parts (saves
a lazy overworked bum like me a lot of typing), it does not do much
good - in my opinion - when it comes to bogon filtering. I prefer
knowing what the filter looks like, and it does not seem to give me
that, nor any way of modifying the list (correct me if I'm wrong).

See pages 9, 10 and 12 of the PDF I posted. Specifically, it
sets up: "ip access-list extended autosec_iana_reserved_block", and "ip
access-list extended autosec_complete_bogon" which you of course can
change like any other ACL.

This is broken by design.

Routers would ship with the iana_reserved_block list of when they were
manufactured. If the user is stoopid enough not to be able to get his
filters from Cymru directly then he should not have any filtering at all
because he is never going to update it anyway in the future. Ergo lots
of black holes for newly allocated address spaces to the RIR's.

The cure will be far worse than the disease if routers would come with
pre-configured bogon lists.

And you are missing a big point; What bogons are bogons? In an enterprise
setup the RFC1918 space (10/8, 172.16/12, 192.168/16) is most likely not
a bogon while it most likely is for an ISP. Breaks right here.

On top of that it is solving a non-problem. There is only little junk
coming from the non-iana allocated ranges. And that is easily taken
care of by filtering inbound traffic at the customer edges (ie. allow
customers to send only traffic with source IP's out of the assigned
IP range).

If you do any bogon filtering at all then do it with some automatically
updating system like an BGP bogon feed from Cymru.

Routers would ship with the iana_reserved_block list of when they were
manufactured. If the user is stoopid enough not to be able to get his
filters from Cymru directly then he should not have any filtering at all
because he is never going to update it anyway in the future. Ergo lots
of black holes for newly allocated address spaces to the RIR's.

Exactly. (Unless "IANA reserved" != "unallocated" but IANA does call unallocated space "reserved".)

The cure will be far worse than the disease if routers would come with
pre-configured bogon lists.

Indeed. In fact, the whole bogon filtering thing is more harmful than useful.

If you do any bogon filtering at all then do it with some automatically
updating system like an BGP bogon feed from Cymru.

What exactly does this feed do for me? Wouldn't bogons be everything that isn't in the global routing table?

How does the BGP bogon feed from cymru protect against more-specific
bogons ?