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

Mailman List Mirror (Read Only)
1

I continue to agree that moving critical resources (see below) to these
new blocks is the best approach I have seen or heard in the months since
I made the original post. This approach punishes the clueless instead
of the people that already know what the problem is (and have to live
with it every day).

I can't begin to calculate the amount of support time we have burned
contacting the offending networks. I know the cost has been prohibitive
at best.

I have seen this suggestion once before (maybe even by Jon) and I still
think it is the best way things will get resolved quickly.

Maybe we should suggest that ARIN also host some of their stuff on this
block :slight_smile:

Todd
IPOutlet LLC

2

After this 69.0.0.0/8 thing is sorted out I guess we can move the
"critical resources" over to 202.0.0.0/7 to track down all the idiots
blocking that range (trying to decide if I should put a smilie here).

I nominate the arin.net nameservers.

Could someone publish a name of a valid resource (or even pingable ip) in
69/8 space? This would allow people to test their (and their upsteams)
filters quickly while we wait for the list to come out.

3

Could someone publish a name of a valid resource (or even pingable ip) in
69/8 space? This would allow people to test their (and their upsteams)
filters quickly while we wait for the list to come out.

The BrightNet nameservers are both in 69.8.2.0/24 for now.

ns.brightok.net: 69.8.2.15
ns2.brightok.net: 69.8.2.12

-Jack

4

69.atlantic.net (69.28.64.8) is a loopback on our Gainesville, FL office
router.

5

Date: Tue, 11 Mar 2003 11:28:55 +1300 (NZDT)
From: Simon Lyall

After this 69.0.0.0/8 thing is sorted out I guess we can move
the "critical resources" over to 202.0.0.0/7 to track down
all the idiots blocking that range (trying to decide if I
should put a smilie here).

Agree.

I had the pleasure of dealing with someone locally who decided to
5.x.x all mail from 216/8. At least they were responsive... I
pity people in 202/7. :frowning:

Eddy

6

After this 69.0.0.0/8 thing is sorted out I guess
we can move the "critical resources" over to 202.0.0.0/7
to track down all the idiots blocking that range (trying
to decide if I should put a smilie here).

I nominate the arin.net nameservers.

Most people seem to think it would be impractical to put the root name
servers in 69.0.0.0/8

Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do IP assignment lookups...

Ray

7

Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do IP assignment lookups...

You are presuming that people are doing IP assignment lookups from the
affected network, sometimes just an affected server. Further more, you
presume that people do IP assignment lookups at all. Clueless people often
don't even know what ARIN is. Just the other day I was asked what Aaron had
to do with the problem I was describing.

-Jack

8

I continue to agree that moving critical resources (see below) to these
new blocks is the best approach I have seen or heard in the months since
I made the original post. This approach punishes the clueless instead
of the people that already know what the problem is (and have to live
with it every day).

I think this illustrates very well that the concept of filtering on
statically configured IP address ranges is severely broken and needs to
be replaced with something better.

Fortunately, in this particular case there is a solution on the horizon:
S-BGP or soBGP. These BGP extensions authenticate all prefix
announcements, so there is no longer any need to perform bogon filtering
on routing information. uRPF can then be used to filter packets based on
the contents of the routing table.

In the mean time, I think we need a good best practices document. Way
too many people simply don't know about these kinds of issues, or worse,
know only half, and having a single, authorative set of guidelines would
be extremely helpful, even if it doesn't magically make the problem
disappear.

I have seen this suggestion once before (maybe even by Jon) and I still
think it is the best way things will get resolved quickly.

Maybe we should suggest that ARIN also host some of their stuff on this
block :slight_smile:

Or maybe list the offending IP addresses/ranges in the anti-spam lists?
This should get people's attention without breaking too much important
stuff (who needs email anyway).

9

Fortunately, in this particular case there is a solution on the horizon:
S-BGP or soBGP. These BGP extensions authenticate all prefix
announcements, so there is no longer any need to perform bogon filtering
on routing information. uRPF can then be used to filter packets based on
the contents of the routing table.

A majority of the filters in place are not BGP filters. They are firewall
rulesets designed to filter out hijacked and spoofed IP addresses to limit
DOS and illegitimate connections. S-BGP and soBGP will not solve the problem
for these people.

-Jack

10

> Fortunately, in this particular case there is a solution on the horizon:
> S-BGP or soBGP. These BGP extensions authenticate all prefix
> announcements, so there is no longer any need to perform bogon filtering
> on routing information. uRPF can then be used to filter packets based on
> the contents of the routing table.

A majority of the filters in place are not BGP filters.

Let's stay focussed on the problem at hand. Or are you saying that most
of the _bogon_ filters aren't BGP filters?

They are firewall
rulesets designed to filter out hijacked and spoofed IP addresses to limit
DOS and illegitimate connections. S-BGP and soBGP will not solve the problem
for these people.

If all routes in the routing table are good (which soBGP and S-BGP can
do for you) and routers filter based on the contents of the routing
table, hosts will not see any bogon packets except locally generated
ones so they shouldn't have bogon filters of their own. So this will
indeed solve the problem for these people.

11

If all routes in the routing table are good (which soBGP and S-BGP can
do for you) and routers filter based on the contents of the routing
table, hosts will not see any bogon packets except locally generated
ones so they shouldn't have bogon filters of their own. So this will
indeed solve the problem for these people.

I believe you are confusing authentication with authorisation.

Having authentic routes does not imply that all the traffic will be
'correct'. Various networks will always fail to filter customer traffic at
ingress etc. and then source address spoofing becomes trivial.

Peter

12

Thus spake "Ray Bellis" <rpb@community.net.uk>

Most people seem to think it would be impractical to put the root name
servers in 69.0.0.0/8

Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do IP assignment lookups...

I'd bet most of the people with broken filters have never heard of ARIN and
still think "the InterNIC" assigns addresses. We're talking about people
with no network staff; directing technical solutions at the people oblivious
to technology is difficult stuff.

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

13

> If all routes in the routing table are good (which soBGP and S-BGP can
> do for you) and routers filter based on the contents of the routing
> table, hosts will not see any bogon packets except locally generated
> ones so they shouldn't have bogon filters of their own.

I believe you are confusing authentication with authorisation.

I don't think I am.

Having authentic routes does not imply that all the traffic will be
'correct'. Various networks will always fail to filter customer traffic at
ingress etc. and then source address spoofing becomes trivial.

I don't see your point. Packets with bogon sources are just one class of
spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will
get rid of bogons. Neither this or bogon filters on the host will do
anything against non-bogon spoofed packets.

14

Most people seem to think it would be impractical to put the root name
servers in 69.0.0.0/8

Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do IP assignment lookups...

The vast majority of broken networks won't care/notice. A few will assume
ARIN's whois server is broken. How often do people on forgotten networks
in China and Albania use ARIN's whois server?

Take away the western Internet (all of gtld-servers.net) and they will
notice the problem.

From a whois, it appears Verisign owns gtld-servers.net. Do they own just

the domain or all 13 gtld-servers as well? Anyone from Verisign reading
NANOG care to comment on the odds of Verisign cooperating and helping
with the breaking in of new IP ranges?

Also, on a side rant here....Why do all the RIR's have to give out whois
data in different, incompatible, referal-breaking formats? The next step
in my work once my ping sweep is complete (looks like that'll be today) is
going to be to take a list of what looks like it'll be ~1000 IPs and
generate a list of the unique networks that are broken. To do this, it'd
be nice if there were some key I could get from whois, store in a column,
select a unique set from, then reuse to lookup POCs from whois, and send
off the emails.

registro.br and LACNIC entries start with inetnum: using what I'll call
brief CIDR, i.e.
inetnum: 200.198.128/19

APNIC and RIPE entries start with inetnum:, but use range format. i.e.
inetnum: 203.145.160.0 - 203.145.191.255

ARIN entries include fields like
NetRange: 128.63.0.0 - 128.63.255.255
CIDR: 128.63.0.0/16

The APNIC and RIPE NetRange/inetnum fields are easy enough to deal with,
but send a whois request for 200.198.128/19 to whois.arin.net and you get
"No match found". Send it as 200.198.128, and whois.arin.net will refer
you to whois.lacnic.net. Send it to whois.lacnic.net as 200.198.128, and
you get "Invalid IP or CIDR block".

I realize programming around all this is by no means an insurmountable
task, but it is a pain. It'd be ideal if there were a unique key field,
say Net-ID included in the whois output from all the RIR whois servers
that could be used to identify the network and the appropriate whois
server. i.e.

NetID: 200.198.128.0@whois.lacnic.net

15

I don't see your point. Packets with bogon sources are just one class of
spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will
get rid of bogons. Neither this or bogon filters on the host will do
anything against non-bogon spoofed packets.

You're thinking technical. The problem isn't bogon filters per say. The
problem is that someone got it in their head that if you filter packets
using a bogon list, you'll limit the number of possible spoofed packets
allowed into your network. Given than many bots use randomizers, and bogon
networks do cover a large amount of the netspace, this may be true. Then
again, perhaps not. It doesn't matter in the end. The fact remains that
while people may protect the routes from being advertised, many large
providers do not drop packets that do not have valid routes. Because of
this, many firewalls (which don't run BGP) filter based on bogon lists.

Only 1 of the last 6 people I contacted for blocking 69/8 actually had BGP.

-Jack

16

[ apologies for the long post ]

Also, on a side rant here....Why do all the RIR's have to give out
whois data in different, incompatible, referal-breaking formats?

The reason for the different formats is partly historical, and
partially a result of the fundamental differences between the RIR's.

The historical reason is that each RIR has a different origin, and the
databases and Whois software comes from that origin. The RIPE NCC
started with nothing, evolved to RIPE-181, then RPSL, and is now
moving to RPSLng + extensions. APNIC adopted RIPE NCC software, and
is very nearly compatible. ARIN's database was inherited from the
InterNIC, and has since evolved into a new, organisation-based model.
I believe LACNIC's database is inherited from the Brazil domain name
registry, so it uses that format (this is the one I am least familiar
with - so I may be in error).

The formats remain different because the RIR's have evolved their
databases to solve problems that are most important in their regions.
For instance, ARIN has chosen a model that reflects registration in a
straightforward way, whereas RPSL is useful for operators wanting to
document policy.

The next step in my work once my ping sweep is complete (looks like
that'll be today) is going to be to take a list of what looks like
it'll be ~1000 IPs and generate a list of the unique networks that
are broken. To do this, it'd be nice if there were some key I could
get from whois, store in a column, select a unique set from, then
reuse to lookup POCs from whois, and send off the emails.

registro.br and LACNIC entries start with inetnum: using what I'll
call brief CIDR, i.e.
inetnum: 200.198.128/19

APNIC and RIPE entries start with inetnum:, but use range format.
i.e.
inetnum: 203.145.160.0 - 203.145.191.255

ARIN entries include fields like
NetRange: 128.63.0.0 - 128.63.255.255
CIDR: 128.63.0.0/16

The APNIC and RIPE NetRange/inetnum fields are easy enough to deal
with, but send a whois request for 200.198.128/19 to whois.arin.net
and you get "No match found". Send it as 200.198.128, and
whois.arin.net will refer you to whois.lacnic.net. Send it to
whois.lacnic.net as 200.198.128, and you get "Invalid IP or CIDR
block".

I realize programming around all this is by no means an
insurmountable task, but it is a pain. It'd be ideal if there were
a unique key field, say Net-ID included in the whois output from all
the RIR whois servers that could be used to identify the network and
the appropriate whois server. i.e.

NetID: 200.198.128.0@whois.lacnic.net

In the current situation, users must query up to 4 servers
(whois.apnic.net, whois.arin.net, whois.lacnic.net, and
whois.ripe.net) to find information about an IP address, in some cases
without any way of knowing which RIR has allocated the space. Each
RIR parses queries and presents results in a different format.

This is not ideal - to put it mildly.

The good news is that we are aware of the problem, and not sitting on
our laurels. The eventual goal is to answer a query for IP or AS
space at each RIR, using the "native" query and result format, and get
the best possible answer. We've completed part of the mapping between
schemas, and after that is finished it's just a matter of writing some
software. :wink:

There is also a technology that might come out of the CRISP IETF
working group:

http://www.ietf.org/html.charters/crisp-charter.html

We (the RIR's) are tracking this work. Since this involves an actual
protocol difference from our beloved Whois protocol, if it is adopted
it will certainly take longer to adopt. But there is no reason the
two protocols can't co-exist and complement each other.

If you have any interest in participating in RIPE Database-related
issues, please feel free to join the mailing list:

http://www.ripe.net/ripe/wg/db/index.html

We (meaning the RIPE NCC, especially the database group) take a lot of
our direction from the DB working group. It's open to all.