[150469] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Fri Feb 24 16:30:35 2012
Date: Fri, 24 Feb 2012 13:29:11 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: "North American Network Operators' Group" <nanog@nanog.org>
Mail-Followup-To: North American Network Operators' Group <nanog@nanog.org>
In-Reply-To: <CAL9jLaYYkhv1v-kJQ4VPf=e0oxdWVzJ79VydWc9oWxnfdXp9Bw@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Feb 24, 2012 at 04:07:28PM -0500, Christopher =
Morrow wrote:
> well.... for bgpsec so if the paths were signed, and origins signed,
> why would they NOT pass BGPSEC muster?
I honestly have trouble keeping the BGP security work straight.
There is work to secure the sessions, work to authenticate route
origin, work to authenticate the AS-Path, the peer relationships,
and so on.
I believe BGPSEC authenticates the AS-Path, and thus turning up a
new peer requires them to each sign each others "path object".
During the time period between when the route propogates and the
signature propogates these routes appear to be a leak. I don't
believe the signature data is moved via BGP. Worse, in this case,
imagine if one of the parties was "cut off" from the signature
distribution system. They would need to bring up their (non-validating)
routes to reach the signature distribution system before their
routes would be accepted!
In fact, this happens today with those who strict IRR filter. Try
getting a block from ARIN, and then service from a provider who
only uses IRR filters. The answer is to go to some other already
up and working network to submit your IRR data to the IRR server,
before your network can come up and be accepted!
On a new turn up for an end-user, not a big deal. When you look at the
problems that might occur in the face of natural or man made disasters
though, like the cable cut, it could result in outages that could have
been fixed in minutes with a non-validing system taking hours to fix in
a validating one.
That may be an acceptable trade off to get security; but it depends on
exactly what the trade off ends up being. To date, I personally have
found "insecure" BGP, even with the occasional leaks, to be a better
overall solution.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBT0gBJ7N3O8aJIdTMAQITjA//eZC/gf5oQE5nDtzM7mg5ZD7UWQQhg1to
fFuzZB0QRayQm6+aODht0FcHuawc0IG+fvXWQdfwpuG/XI//v/sHzazh5s1WcT3I
mLRLGrk3yxVBiXT3kZFREASxwAnOMEjwytFCCJgb12mEoDN3nh1mSnrYnomAF+oF
I+O6ZiiKLy7x9yM3UXPhplI9zHFyYydk8kosG3UUHOVvztGN580wijUvYoexVVsr
PktSLN1dor3Sy8JXiir8HVBIE3HGiQi/XugITVzEXh7vDhbEWtPaUgo3BABj1KDj
bpQU+v1tjQGI7u0MLfdIq1NzulI1JdUT+JGQ2R+piHh9u4VWB/6GYk7E/3dvzAt6
b59zew9rxaZMo/dgdFTBduQZJLLCQvF0Z2igNxqZxbAikUbD3plhpTmFPepQFy43
cLFo7Za39ALQvpVbV/vSkOiw01EzcfYV37rvG4DCGkxyF3YxdzVWusZN9hANqS7K
Z2l+iGw3xjKmCfuMU0Z/G0NxCVbPZGg384f3OgUpKua3DTNkgkD8d2tYyIGAnnRK
g/MXJcKxCSkEtfouJqC0CwByJ5hrcezUEkEEl1LGK8+Zca2GvBb4/9NvfRgomaz9
cOf9dD+zGgzCNDUUK1pOmV0A46dG5VDEbPf8v/DsjBRNtNKW6CKByMtT2YfZ7znt
xqc3QEeWrFo=
=sD+F
-----END PGP SIGNATURE-----
--vkogqOf2sHV7VnPd--
