On Tue, 11 Mar 2003, Simon Lyall wrote:

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.

69.atlantic.net (69.28.64.8) is a loopback on our Gainesville, FL office router. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

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 -- Ray Bellis, MA(Oxon) - Technical Director community internet plc - ts.com Ltd Windsor House, 12 High Street, Kidlington, Oxford, OX5 2PJ tel: +44 1865 856000 email: ray.bellis@community.net.uk fax: +44 1865 856001 web: http://www.community.net.uk/

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

[ apologies for the long post ] On 2003-03-11 19:57:04 +0000, jlewis@lewis.org wrote:

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. ;) 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. -- Shane Kerr Database Group Manager RIPE NCC

From: "Iljitsch van Beijnum"

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

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

From: "Iljitsch van Beijnum"

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