do not filter your customers

Fri Feb 24 21:29:11 UTC 2012

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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120224/f46b3dcf/attachment.sig>