[150491] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Jeff Young)
Fri Feb 24 22:54:21 2012
From: Jeff Young <young@jsyoung.net>
In-Reply-To: <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
Date: Sat, 25 Feb 2012 14:53:21 +1100
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-27--352516925
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On 25/02/2012, at 12:59 PM, Christopher Morrow wrote:
> On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young <young@jsyoung.net> =
wrote:
>> 1. Make your customers register routes, then filter them.
>> (may be time for big providers to put routing tools into
>> open source for the good of the community - make it
>> less hard?)
>=20
> not a big provider, but ras@e-gerbil did release irr-tools no?
And other providers out there have extensive tool sets from which
we could all benefit. I'll let them chime in if they choose.
>=20
>> 2. Implement the "1-hop" hack to protect your BGP peering.
>>=20
>> 98% of problem solved on the Internet today
>>=20
>=20
> which problem? GTSH only protects your actual bgp session, not the
> content of the session(s) or the content across the larger network.
>=20
The security problem, but it was a hedge on my part.
>> 3. Implement a "# of routes-type" filter to make your peers
>> (and transit customers) phone you if they really do want
>> to add 500,000 routes to your session ( or the wrong set
>> of YouTube routes...).
>=20
> max-prefix already exists... sometimes it works, sometimes it's a
> burden. It doesnt' tell you anything about the content of the session
> though (the YT routes example doesn't actually work that way)
Depends on how many /24's the Pakistan(?) Telecom guy let into the=20
network to block the YT content... but you're right, the example would=20=
have been better in support of #1. =20
(had PT been forced to register routes before sending them and his=20
upstream been filtering based on those routes we'd have never heard=20
about it.)
>=20
>> 99.9% of problem solved.
>=20
> ? not sure about that number
>=20
>> 4. Implement BGP-Sec
>>=20
>> 99.91% of "this" problem solved.
>>=20
>> Because #1 is 'just too hard' and because #4 is just too sexy
>> as an academic pursuit we all suffer the consequences. It's
>=20
> there are folks working on the #4 problem, not academics even. It's
> not been particularly sexy though :(
>=20
Point was that the problem is mostly operational. We have tools
to deal with the problem but the operational costs are high. For=20
fifteen (below) years we've treated this (route leak) as "not my =
problem"
because it's too costly. Every 6-12 months it comes back to bite
us. If the cost of an outage every 6 months+ is low compared to
solving the problem, the community will endure the outage. If we=20
want it to stop today we can make it stop but stopping it has a cost.
=93...a glitch at a small ISP... triggered a major outage in Internet =
access=20
across the country. The problem started when MAI Network Services
...passed bad router information from one of its customers onto Sprint.=94=
-- news.com, April 25, 1997
jy
--Apple-Mail-27--352516925
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iF4EAREIAAYFAk9IWzYACgkQxvthcni5E29VLgEAgyxM8KvzCerIfyRsewA5136a
HPtwisX5uGxxi3sOf90A/3vU0m24fsABCAQ3PwR4mr3QyEYj6T2+6AJn1U4OxQfU
=MN0L
-----END PGP SIGNATURE-----
--Apple-Mail-27--352516925--
