[180741] in North American Network Operators' Group
RE: Routing Insecurity (Re: BGP in the Washington Post)
daemon@ATHENA.MIT.EDU (Russ White)
Wed Jun 10 07:51:29 2015
X-Original-To: nanog@nanog.org
From: "Russ White" <russw@riw.us>
To: "'David Mandelberg'" <david@mandelberg.org>,
<nanog@nanog.org>
In-Reply-To: <4e841065a0d9ea6460b04f5f160cbb7c@mail.mandelberg.org>
Date: Wed, 10 Jun 2015 07:51:17 -0400
Errors-To: nanog-bounces@nanog.org
> > Crypto =3D more overhead. Less priority to crypto plus DDoS =3D =
routing
> > update issues.
>=20
> I don't think there's an update issue here. The crypto verification is =
probably
> going to be deferred in addition to being low priority. If I =
understand it
> correctly, this means that a route can be passed along right away =
without
> waiting for the crypto checks.
I don't think this quite fits with Postel's law... There's also the size =
of the table and the ability to pack (compress) the information to =
consider.=20
> > One can infer peering relationships in a way not possible before.
>=20
> How?
The keys are per router, not per AS. You could use a single =
private/public key pair across the entire AS -- but that's not good =
security hygiene. There's no way to sign an update without exposing the =
signer; if you sign at anything below the AS level, you're exposing new =
information.
What about the per NLRI timer? The timer is essentially the amount of =
time you'd like someone to be able to advertise a route once the peering =
session is broken. How long are you comfortable with someone advertising =
your routes after you've taken down your peering with them? What's the =
performance impact of forcing every route in the table to expire, say, =
every 24 hours? Given your cost of setting your timers to a few minutes =
or hours is nil (you're transferring the cost of your increased security =
onto "everyone else"), why not set it lower? Tragedy of the commons?=20
I'm not saying BGPSEC a bad solution for the questions asked -- I'm =
saying it's is too heavyweight given the tradeoffs, and that we probably =
started with the wrong questions in the first place.
What's needed is to spend some time thinking about what questions really =
need to be answered, the lowest cost way to answer those questions, and =
a complete examination of the tradeoffs involved. Is "what path did this =
update travel," or "are the BGP semantics being properly followed," =
really questions that want asking? Or are there other, more pertinent =
questions available?=20
:-)
Russ=20
