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.
yes
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 cert-check/hash-check/etc. 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 this discussion. 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 case.
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 overall solution.
how's that chinese leak of F-root doing for you? :) -chris