[149486] in North American Network Operators' Group
Re: Hijacked Network Ranges
daemon@ATHENA.MIT.EDU (Mark Tinka)
Mon Feb 6 03:00:33 2012
From: Mark Tinka <mtinka@globaltransit.net>
To: Christopher Morrow <morrowc.lists@gmail.com>
Date: Mon, 6 Feb 2012 15:59:29 +0800
In-Reply-To: <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
Cc: nanog@nanog.org
Reply-To: mtinka@globaltransit.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart6616625.NNMKNBpp72
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Monday, February 06, 2012 03:06:24 PM Christopher Morrow=20
wrote:
> do you have customers with 10k long prefix lists? it gets
> hard when the lists get long, or the data is for
> downstream folks of your customer. Good that someone's
> checking though, I'd love to see this part automated.
No, we don't have customers with 10,000-long prefix lists,=20
but we have planned to implement automation (either using=20
the IRR Toolset or home-grown solutions) to make this=20
possible as a means to scaling, should that time arise.
As it is now, throwing NOC staff at the problem for the=20
volumes we have works well enough. But this is, by no means,=20
a panacea as we scale up.
Heck, one must even worry whether a some router=20
configurations can take that many lines. But there are other=20
ways around that.
> RPKI doesn't necessarily mean that the router knows
> anything about certificates in the short-term. I think
> there's a time when 'the resource certification system'
> (which is really, today, the rpki) holds cert/roa data
> that you could use to filter what the IRR tells you for
> a customer. You could even do this in any automated
> manner!
Well, given validation information will be available within=20
a network, one may use it in non-obvious ways to implement=20
policy.
> The time between the previous and next paragraphs though
> is when all isp's will need to beat the drums with their
> customers saying: "Hey, you REALLY need to get that shit
> into the 'resource certification system' (rpki), NOW."
> (because shortly we'll stop accepting your "invalid"
> routes... and then the interwebs won't be able to find
> you, and we'll all be sad.)
Well, we have all seen how doing this with DNSSEC, IPv6 and=20
4-byte ASN's worked out.
We need to understand that different operators and different=20
customers will have varying reasons as to why they can't yet=20
"do the right thing". There is abundant evidence of this=20
with other similar initiatives.
Adoption will have to be incremental. During that time, the=20
Internet must not break.
> sure... it's not working so well though :(
Not for lack of having some kind of solution.
What we have today may not be the best, most scalable=20
option, but it is one nonetheless. Automating it (like what=20
RPSL does) is how you can make it scale to some extent, but=20
it's still the same solution.
We can't just sit around waiting for RPKI. There will be=20
some reason why some of us can't deploy it, while someone=20
else is thinking up its successor. Rinse, repeat.
Mark.
--nextPart6616625.NNMKNBpp72
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)
iQIcBAABAgAGBQJPL4hkAAoJEGcZuYTeKm+G8IQQAL3gGFl+Y2hf2gZUpow4UTaM
u+/De5s9gIA912TWh3OnrGNxwih0KQKffdAVzjMVRY+F87b0csa6W42RaRr6PFFh
/7HPGW1Lqlk9gSs1BaH1FMBarprmtaOta4kVAeSDSjywnB4pUDog8ywqf7t56xu4
BbzLlgSGVKm9cL9k50e7AmCQnv0w9efuHlGRu0J11JRs+M5C2e1GU0btJF83vdHl
JC7FzN5Cpg4kX2Gfgg7kpOFe6RNTbChUND2sVSZR+PjPj4o27sZI7ETbMKNaKRF8
E0yPK6JKTm4YLLwiUATvlb/a0XRWmpC2RUGYxfXv/pH0pBFlgyH+3NiDDWcJHwXS
Hi8OsZhq4N5DZrddubAvD24/A1dz0yhK2GA34PmpdB+y0Wj7VugnimjNY6ydDxeu
sAs+AxqJGA0W/yksFEJ+0cMOTZuW9197C5QFcC7hjnv43nYZLkX8XU1wICSLmvvj
TLBOifZVYpwHkskzAHFCWrz35VRamHM5EIfaxY0N+Knt6lz2DhV3quw13s2CXEin
5aQmIKscM4msKiWQOV29QrK4SkZO3e4uB/7OJC1mqDZi4j22q9RFhqOLXFOlaB0c
RrRO+DSm5mOSNMwqVaOcdOfuwnaObWgjLInHk11woB8aGR/7XvyU1OGTKzzUPKNi
HpV1Q0Gyz7BMh/K1f0gZ
=8gKk
-----END PGP SIGNATURE-----
--nextPart6616625.NNMKNBpp72--
