mailing list archives
Re: do not filter your customers
From: Christopher Morrow <morrowc.lists () gmail com>
Date: Fri, 24 Feb 2012 17:04:40 -0500
On Fri, Feb 24, 2012 at 4:29 PM, Leo Bicknell <bicknell () ufp org> wrote:
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".
well currently it doesn't do anything (really) but the PLAN is that
you'd be able to look at the origin, view some transitive
community/attribute and say: "That validates with the roa data" - some
then later on you'd be able to say for each AS in the ASPATH:
"Yes, the route is signed by AS1, the signature validates. Yes the
route is signed by AS2, the signature validates (wash/rinse/repeat for
the whole path)"
During the time period between when the route propogates and the
signature propogates these routes appear to be a leak. I don't
signatures follow inside the announcement as currently draft-spec'd.
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!
the sig data for an NLRI follows along inside the announcement.
the cache of data is probably updated inside of a day... there's
likely some skew, but provided the origins don't change and no one has
to emergency release new key materials, I think it's not important for
you simply start hearing routes with same origin as previously on
different paths. "new customers" essentially pop up en-mass. This
isn't a problem as long as the customers are the same origin-as as
before... it'd mean some rejiggering of prefix-lists (as I said
before) but ... you'd be doing that anyway.
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!
right, there's some lag between publication and acceptance/update. I
think in the case of (for example L(3) the lag is ~6hrs in the worst
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.
I don't think that's really the case, but walking through the
processes/requirements seems like a sane thing to do.
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
how's that chinese leak of F-root doing for you? :)