Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)

How to treat unsigned paths is a matter of policy.
This is up to each provider to configure as he pleases.
I would prefer a signed route over an unsigned one,
but prefer an unsigned route over no route.
For more security sensitive routes, you may prefer no route
over an unsigned route. It's up to you.

I am saying, do not delay the regular updates.
Send the signatures in a separate connection.

A performance sensitive implementation does both
the signing and the checking in a low priority
process anyway. That results in two updates, one
with the regular update followed by a copy with
the signature.

I am saying to put that signature into a separate
connection, so as not to delay the higher urgency
regular updates.

--
Jakob Heitz.

> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf
> Of Russ White
> Sent: Tuesday, November 15, 2011 5:31 PM
> To: sidr@ietf.org
> Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
> 
> 
> 
> >>> I can not believe that it will be 2X.
> 
> It will likely be worse.
> 
> > Now, for a regular update that changes the bestpath, the signature
> > will likely come later (in my proposal). If it replaces an
> existing
> > valid path, the bestpath will not change until the signature
> arrives.
> > If it replaces no path, then the regular update will produce a
> > bestpath change, but the signature will not.
> 
> So you are arguing that if you have two signed paths, and you
> receive a new unsigned path replacing one of the signed paths --in
> fact, replacing the signed path that is currently your bestpath--
> you would keep using the old bestpath even though it has a lower
> security preference than the other existing signed path.
> 
> How does a system that says, "replay attacks are okay, you may
> accept unsigned information over signed information, it's okay if
> timers are expired, it's okay if AS' in the middle of that path can
> be attacked through replays, etc.," really provide security? I'm
> seeing a lot of work for little to no net gain here.
> 
> :-)
> 
> Russ
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr