[149477] in North American Network Operators' Group
Re: Hijacked Network Ranges
daemon@ATHENA.MIT.EDU (Mark Tinka)
Mon Feb 6 01:36:37 2012
From: Mark Tinka <mtinka@globaltransit.net>
To: Christopher Morrow <morrowc.lists@gmail.com>
Date: Mon, 6 Feb 2012 14:35:35 +0800
In-Reply-To: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
Cc: nanog@nanog.org
Reply-To: mtinka@globaltransit.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart2992513.26VmUxtsLi
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Monday, February 06, 2012 01:14:20 PM Christopher Morrow=20
wrote:
> o not having filters at all (pccw/pktel)
Well, we know what this leads to (part of the reasons you=20
find some eBGP sessions carrying /25's or longer + RFC 1918=20
space is because of this).
> o filtering using old/stale data (ntt/l3)
Well, we think that this problem resolves itself rather=20
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=20
prefix in the yonder than have open filters, because one is=20
more likely to quickly get resolved without any colleteral=20
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=20
prefix lists or AS_PATH filters, until they appeared. And=20
while some folk still use so-called "distribute lists"=20
today, it's fine with me as long as they maintain secure=20
operations with whatever solution they choose, hard or easy.
Some ISP's have automated this process either by using=20
internal IRR software, or scripting web GUI's that their NOC=20
can use to simply stick in the prefix, select which router=20
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=20
you can use to edit on object, including IRR data (and=20
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=20
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=20
networks might automate this with an internal system that=20
checks the RIR WHOIS database, and probably integrates with=20
their provisioning system that can automatically create and=20
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=20
take a very long time for various reasons, e.g., education,=20
delayed software upgrades, persistence with older methods,=20
fear of centralization, e.t.c.
In such a case, operators will need to support "Invalid" and=20
"NotFound" states of origin information for a long time. As=20
adoption and deployment increases, operators can begin=20
dropping "Invalid" results, "NotFound" results, or both. Or=20
even mark them down with poor LOCAL_PREF values so as not to=20
use those routes for forwarding unless it is really=20
necessary.
At some point, when diffusion of RPKI is sufficiently=20
prolific, anything that does not return a "Valid" result=20
will be dropped. This should force every operator around the=20
world to support it, much like the large carriers forced us=20
all to use IRR's just so they won't ignore our routes,=20
wherever we are in the world.
But before all this happens, we have to prevent more=20
hijacks. And we have to use the tools we have today.
Mark.
--nextPart2992513.26VmUxtsLi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJPL3S6AAoJEGcZuYTeKm+GWnAP/3Tf3Md0S/9+fVCgUMM83o52
42wEKhP43wQgkKuBpYRURrl/DFl55TNHZhgyHZFsQaTlnAzE1IJMfl1XcyBxrJb8
efew1eBs77QdhXGW50dQGu2J0+szYak90RZVPCPwxUmz9mzb6bL5tWSvkw/qc3by
6WXviEIMwDWinozvz5gi/la73iT854IIuA3NR9PFflXHeHgDnRkWvyxGrMO54TP2
aK/yStevArzPHl4xCrmS3nLFl1IwsjvifsbZQnoYFwerhCDjeoXk7ZO3SJQApZ24
0P4D6BWt5+fh+Qqno2YNz8gaVMLmBvd0bwaOTHI9WVVU4Gh7qLS8/fCoWXo9xXBi
ogd/IbDR88DqN1lzTCeM2IimzdmenPVa9Yxg/+arXkLapRJx9ZmP7How/DCz0qAP
O54QyBwqSMmuYY9CooAU+iSrnie9sMuG8/gDrK6UGxpjDw9JRRxZJRjzkUskVVL8
DxyWA20/Cl49H5Nwwgd88NWSMKZmE3k5VHGAaFVI1ntkcLli1QjoUBW9uyW2VAwo
JZ5XNv0SCKssE8JM1JekZO8wvoH5UypyVGJ1TLR4sNKRjJq334jht8XJOruFhJK1
AgxuPZMYt7Pf2FXteksBuAR1CX8pKQv6y+cPffnVT0VIUI8XjXHfRes0pxucw5GD
Aa7znmrzcDkajGrNeF/F
=0dCm
-----END PGP SIGNATURE-----
--nextPart2992513.26VmUxtsLi--
