Re: [sidr] Burstiness of BGP updates

[Brian Dickson <[e-mail]>]

On Wed, Nov 16, 2011 at 12:35 AM, Christopher Morrow
<[e-mail]> wrote:
> On Wed, Nov 16, 2011 at 12:29 AM, Brian Dickson
>> Does this illustrate the importance of not only validating origins,
>> but also only using signed prefixes if you are participating in
>> BGPsec?
>
> sure, but if your customer forgets to pay a bill, calls you up and
> (post proper 'this is the customer' authentication) says: "Hey, srsly,
> I forgot, checks in the mail to ARIN, can you accept our route pls?"

I was using "only" in contrast to Jakob, who was suggesting having the same
prefix and as-path, both signed and unsigned, be used, and in fact the
unsigned used prior to validating the signatures.

Basically, if you have BGPsec enabled with a given peer, you might get
a combination of signed and unsigned from that peer - but for a given prefix,
you MUST only get one or the other. Invalid-sig != unsigned.

Accepting unsigned as a "fast" short-cut is insane, frankly.

Signed prefix processing actually needs to "block" until the signature
result is received.
On a per-prefix basis, of course.

This is why having your cache very close is important, as are any
possible implementation
optimizations or design considerations that improve signature
processing/capacity/timeliness.

> you may be willing to do same, you may also be willing to do this in
> the case of internal services routes that you don't actually want
> externally visible.

Sure - and locally significant signatures/trust-anchors are very
important for just such an occasion.
(For any convenient value of "local", it should be noted. City, zip
code, province, continent, building, whatever.)

>
> re-announcement is 'harder' since it's not clear if NTT is supposed to
> be passing cogent aol's routes or not, is it?

Agreed - I can't be specific on exactly when, but expect me to present something
"real soon now" on a nuts-and-bolts level of how to do this. Maybe a
month, maybe two.

Brian