do not filter your customers

Christopher Morrow morrowc.lists at gmail.com
Fri Feb 24 22:04:40 UTC 2012


On Fri, Feb 24, 2012 at 4:29 PM, Leo Bicknell <bicknell at 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




More information about the NANOG mailing list