RE: 69/8...this sucks -- Centralizing filtering..

Mailman List Mirror (Read Only)
1

What surprises me most about this entire thread is the lack of centralized
filtering.

Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the packets to a bit bucket..
Which is better than an access list since, now we are forwarding packets
instead of sending them to a CPU to increase router load.

I don't think ARIN can help the situation. ISPs just need to remove the
access lists from each router in the network and centralize them.

Regards,
mark

2

Date: Mon, 10 Mar 2003 10:27:35 -0500
From: Mark Segal

Since most service providers should be thinking about a sink
hole network for security auditing (and backscatter), why
not have ONE place where you advertise all unreachable, or
better yet -- a default (ie everything NOT learned through
BGP peers), and just forward the packets to a bit bucket..
Which is better than an access list since, now we are
forwarding packets instead of sending them to a CPU to
increase router load.

Chris Morrow and Brian Gemberling (a.k.a. dies) have some fine
instructions on how to do just that. Rob Thomas has a bogon
route server that comes in handy.

The problem with only a default: Think when a rogue ISP decides
to advertise an unused netblock and utilize that IP space for
malicious purposes. A route exists... do we trust it?

I don't think ARIN can help the situation. ISPs just need to

Probably not. Nor should they need to. Although perhaps they
could allocate other netblocks, and they _do_ charge a fair
amount for PI space... :wink:

remove the access lists from each router in the network and
centralize them.

Now, how can we force that? Sufficient reward for doing so, or
pain for failure. Evidently "some people can't reach you" isn't
enough pain, and having full reachability isn't enough reward.

I'm looking forward to Jon Lewis (or others) providing some stats
about just how bad the problem is... being fortunate enough not
to have [any clients in] 69/8 space I can't comment first-hand on
the severity of the problem.

Eddy

3

Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the packets to a bit bucket..
Which is better than an access list since, now we are forwarding packets
instead of sending them to a CPU to increase router load.

I don't think ARIN can help the situation. ISPs just need to remove the
access lists from each router in the network and centralize them.

I totally agree with you. However, as always, centralized systems, while
ease management and scalability, everything becomes a trust issue and a
single point of failure or source of problems...

May be, this could be a subscription based type of service, something like
RADB, where everyone subscribes into a central filtering list that is
managed by a seperate organization? I really like the Rob's bogon
route-server setup.

-hc

4

What surprises me most about this entire thread is the lack of centralized
filtering.

Central as in 'ALL INTERNET USES MY FILTERING SERVICE' or... 'My network
uses my filter service and your network uses yours'?

Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the packets to a bit bucket..

This can be VERY dangerous, the default part atleast. At one point we, as
an experiment in stupidity (it turns out) announced 0/1 (almost default).
We quickly recieved well over 600kpps to that announcement. This in a very
steady stream... When one announces a very large block like this there are
always unintended consequences :frowning: There is alot of traffic spewed out to
non-available address space, this traffic is very large when aggregated :slight_smile:

Which is better than an access list since, now we are forwarding packets
instead of sending them to a CPU to increase router load.

Yes, routes to null0 or to a dead interface/collection host are much nicer
than acls. So, for this perhaps instead of acls uRPF would be a solution
for the implementor?

I don't think ARIN can help the situation. ISPs just need to remove the
access lists from each router in the network and centralize them.

Or, have an 'automated' manner to deploy/audit/change said acls? RAT
perhaps or some other 'automated' router config checking/deployment tool?

5

I can think of two organisations which could probably take care of a good chunk of the problem, if people were prepared to leave it up to them. The routing system is already largely dependent on the interoperability of bugs produced by these people, and so arguably no additional trust would be required.

One organisation has a name starting with "j", and the other starts with "c".

Joe

6

Date: Mon, 10 Mar 2003 17:30:27 +0000 (GMT)
From: Christopher L. Morrow

This can be VERY dangerous, the default part atleast. At one
point we, as an experiment in stupidity (it turns out)
announced 0/1 (almost default). We quickly recieved well
over 600kpps to that announcement. This in a very steady

Announced via IGP or BGP? I hope/assume the former, but am
somewhat surprised at the traffic volume... even for UUNet.

Eddy

7

> Date: Mon, 10 Mar 2003 17:30:27 +0000 (GMT)
> From: Christopher L. Morrow

> This can be VERY dangerous, the default part atleast. At one
> point we, as an experiment in stupidity (it turns out)
> announced 0/1 (almost default). We quickly recieved well
> over 600kpps to that announcement. This in a very steady

Announced via IGP or BGP? I hope/assume the former, but am
somewhat surprised at the traffic volume... even for UUNet.

bgp, no-export.

8

I think the only way that's relatively guaranteed to be effective is to
move a critical resource (like the gtld-servers) into new IP blocks when
previously reserved blocks are assigned to RIR's.

I still have a couple hundred thousand IPs to check (I'm going to step up
the pace and see if I can get through the list today), but I already have
a list of several hundred IPs in networks that ignore 69/8. The list
includes such networks as NASA, the US DoD, and networks in China, Russia,
and Poland. Those are just a few that I've done manual whois's for.

I haven't decided yet whether I'll send automated messages to all the
broken networks and give them time to respond and fix their filters, or
just post them all to NANOG when the list is complete.

Are people interested in seeing the full list (at least the ones I find)
of networks that filter 69/8?

Does Atlantic.Net get an ARIN discount for doing all this leg work? :slight_smile:

9

I still have a couple hundred thousand IPs to check (I'm going to step up
the pace and see if I can get through the list today), but I already have
a list of several hundred IPs in networks that ignore 69/8. The list
includes such networks as NASA, the US DoD, and networks in China, Russia,
and Poland. Those are just a few that I've done manual whois's for.

You have been busy!

I haven't decided yet whether I'll send automated messages to all the
broken networks and give them time to respond and fix their filters, or
just post them all to NANOG when the list is complete.

Are people interested in seeing the full list (at least the ones I find)
of networks that filter 69/8?

Why not do a weekly report of some sort. Post a summary to nanog with a
reference to the website containing the full list. If you can group them by ASN
you can do a report a la cidr-report of top 20 offenders and include that in
your nanog post.

I think this would be a good way to sustain momentum in your worthy cause..

Steve

10

Monday, March 10, 2003, 9:52:06 AM, you wrote:

I think the only way that's relatively guaranteed to be effective is to
move a critical resource (like the gtld-servers) into new IP blocks when
previously reserved blocks are assigned to RIR's.

I agree with you. But then since I've been allocated 69/8 I guess you
can say I'm a bit biased.

I still have a couple hundred thousand IPs to check (I'm going to step up
the pace and see if I can get through the list today), but I already have
a list of several hundred IPs in networks that ignore 69/8. The list
includes such networks as NASA, the US DoD, and networks in China, Russia,
and Poland. Those are just a few that I've done manual whois's for.

I haven't decided yet whether I'll send automated messages to all the
broken networks and give them time to respond and fix their filters, or
just post them all to NANOG when the list is complete.

Are people interested in seeing the full list (at least the ones I find)
of networks that filter 69/8?

Again, since I've been recently allocated in the 69/8 range, I'd love
to see this completed list.

We've only renumbered our internal workstations into this range, so
no customer nets are affected as of yet. But we are about to plunge
into our renumbering, so I'm sure customers are going to start yelling
then.

However, I think this is going to be an on-going problem, even if the
gtld-servers were renumbered into 69/8.

Do a simple Google search on ip firewalling. You'll find lots of
examples using ipchains, iptables, etc, that show example configs.
These example configs usually show 69/8 as a bogon network and
recommends filtering them.

So, in my opinion it's only going to be a matter of time before some
network administrator looking to implement a firewall stumbles across
one of these broken sample configs and breaks connectivity to me
again.

In essence, it's going to be an ongoing problem, sure we can fix
networks now that we know are broken, but it's going to be an ongoing
problem that we are going to have to deal with.

Regards,

Joe Boyce

11

Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the packets to a bit bucket..
Which is better than an access list since, now we are forwarding packets
instead of sending them to a CPU to increase router load.

It would be nice if vendors had a variant to (in cisco terms) ip verify
unicast reverse-path that would work in asymmetrical networks. If you only
have a single link to the internet, the command works well, but then why
would you ever run bgp for a single uplink?

-Jack

12

> From: Christopher L. Morrow

> This can be VERY dangerous, the default part atleast. At one
> point we, as an experiment in stupidity (it turns out)
> announced 0/1 (almost default). We quickly recieved well
> over 600kpps to that announcement. This in a very steady

Announced via IGP or BGP? I hope/assume the former, but am
somewhat surprised at the traffic volume... even for UUNet.

I'm not surprised. My experience with defaults in ISPs is the same. The router
advertising the default (or any large prefix) becomes a "packet vacuum" for any
spoofed source packet returning backscatter and all those other auto-bots and
worms looking for vulnerable machines. It turns the router into a sink hole.

What saves many providers today is that these large route injections are spread
across all their peering routers. This is like anycasting the prefix
advertisements. People are discussing is putting these advertisements on
anycasted Sink Holes. So instead of having the CIDR prefixes and the Null 0
lock-ups on the peering routers, you would put them on anycast Sink Hole
routers. The anycast spreads the packet black hole load over several sink holes
spread over the network.

Barry

13

Date: Mon, 10 Mar 2003 11:17:55 -0800
From: Barry Raveendran Greene

> Announced via IGP or BGP? I hope/assume the former,
> but am somewhat surprised at the traffic volume... even
> for UUNet.

I'm not surprised. My experience with defaults in ISPs is
the same. The router advertising the default (or any large
prefix) becomes a "packet vacuum" for any spoofed source
packet returning backscatter and all those other auto-bots
and worms looking for vulnerable machines. It turns the
router into a sink hole.

Assuming one's upstreams and peers lack 'deny le 7'.

What saves many providers today is that these large route
injections are spread across all their peering routers. This
is like anycasting the prefix advertisements. People are
discussing is putting these advertisements on anycasted Sink
Holes. So instead of having the CIDR prefixes and the Null 0
lock-ups on the peering routers, you would put them on
anycast Sink Hole routers. The anycast spreads the packet
black hole load over several sink holes spread over the
network.

IMHO, this is a good thing.

Eddy

14

Can you point out where the rule is written that noone is to
announce a prefix with length le 7? Just we don't see it now
doesn't mean we won't see it sometime in the future...

Regards,
Daniel

15

Date: Mon, 10 Mar 2003 23:10:35 +0100
From: Daniel Roesen

Can you point out where the rule is written that noone is to
announce a prefix with length le 7? Just we don't see it now
doesn't mean we won't see it sometime in the future...

Ditto ge 25. I might have missed the RFC where that was
specified; AFAIK, it's a de facto standard.

Here's a big difference: Assume all /8 (except for 0/8, 127/8,
and 224/3) could be aggregated. How many announcements would be
saved? I could live with 200-some /8 announcements as a result
of shorter prefixes being deaggregated. I suspect announcing
uebershort prefixes isn't a big concern.

Let's first address the issue of stray /24 prefixes. Your
question is interesting in theory, but has little applicability
to operational practices. It shouldn't be forgotten, and anyone
using an "le 7" filter should stay on top of things... but I
don't see it as a pressing issue.

Better yet, let RIRs allocate based on prefix length. Then
Verio-style filters would work great, save for small multihomed
networks. However, if said multihomed nets used IRRs...

Uhoh. Combining a handful on NANOG threads probably is a
dangerous thing to do.

Eddy