Hijacked Network Ranges

Mon Feb 6 06:35:35 UTC 2012

On Monday, February 06, 2012 01:14:20 PM Christopher Morrow 
wrote:

>   o not having filters at all (pccw/pktel)

Well, we know what this leads to (part of the reasons you 
find some eBGP sessions carrying /25's or longer + RFC 1918 
space is because of this).

>   o filtering using old/stale data (ntt/l3)

Well, we think that this problem resolves itself rather 
well:

	o If a customer is not getting traffic hitting a
 	  prefix, they'll check with their upstream on if
	  their prefix is being received and propagated.

	o If a customer is not seeing their prefix on the
	  Internet, they'll check with their upstream on if
	  their prefix is being received and propagated.

	o If a customer starts announcing a new prefix
	  without updating their upstream, one e-mail or
	  phone call to the upstream will get this fixed.

In all cases above, it's better not to have an unauthorized 
prefix in the yonder than have open filters, because one is 
more likely to quickly get resolved without any colleteral 
than the other.

> why aren't filters applied at all? ("its hard, people
> keep asking me to update them, bah! work!")

Well, so was running the Internet without BGP communities or 
prefix lists or AS_PATH filters, until they appeared. And 
while some folk still use so-called "distribute lists" 
today, it's fine with me as long as they maintain secure 
operations with whatever solution they choose, hard or easy.

Some ISP's have automated this process either by using 
internal IRR software, or scripting web GUI's that their NOC 
can use to simply stick in the prefix, select which router 
to update, and bam!

Compared to the alternative, this is a small price to pay.

> why aren't filter data bases kept up to date? ("its hard,
> i have to email something to radb/altdb/etc... bah,
> work!")...

That's why we use the RIPE RR. They have a cool web GUI that 
you can use to edit on object, including IRR data (and 
they're respected by all other major RR's and operators):

	https://apps.db.ripe.net/webupdates/

It certainly beats the old "MAIL FROM" system, although I 
believe that is still operational.

> why aren't checks of the filter data simple and
> mechanical? (and accurate?) ("Bah! work! plus, have you
> looked at the ouptput? bah! work!")

See above.

We manually check the RIR WHOIS database. I'm sure some 
networks might automate this with an internal system that 
checks the RIR WHOIS database, and probably integrates with 
their provisioning system that can automatically create and 
update filters on routers. I don't know...

But it's certainly better than the alternative.

> resource certification would at least get us to the point
> where checking the data in the IRR is 'easy', it's not
> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
> and it's not going to get people to update their IRR
> objects (add AND DELETE!!!)

I support RPKI, but also realize that operator support will 
take a very long time for various reasons, e.g., education, 
delayed software upgrades, persistence with older methods, 
fear of centralization, e.t.c.

In such a case, operators will need to support "Invalid" and 
"NotFound" states of origin information for a long time. As 
adoption and deployment increases, operators can begin 
dropping "Invalid" results, "NotFound" results, or both. Or 
even mark them down with poor LOCAL_PREF values so as not to 
use those routes for forwarding unless it is really 
necessary.

At some point, when diffusion of RPKI is sufficiently 
prolific, anything that does not return a "Valid" result 
will be dropped. This should force every operator around the 
world to support it, much like the large carriers forced us 
all to use IRR's just so they won't ignore our routes, 
wherever we are in the world.

But before all this happens, we have to prevent more 
hijacks. And we have to use the tools we have today.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/ea1bda25/attachment.sig>