BGP over TLS

Brandon Martin lists.nanog at monmotha.net
Tue Oct 22 18:45:53 UTC 2019


On 10/22/2019 14:07, Keith Medcalf wrote:
> That is incorrect.
> 
> I believe that an endpoint (lets call it Alice) can connect to another endpoint (lets call it Bob) and Alice can say to Bob, "Hello Dude, lets negotiate a secret key between us".  "Yokkely dokelly", says Bob, "Lets do that".  They then exchange some stuff to and fro and then Alice says "Righty then, lets encrypt!" and Bob says, "Yabba Doodle Doo".
> 
> At this point further communications are encrypted and secure against eavesdropping.  Alice still has no idea who she is talking to (other than it is the dude that picked up the phone), and Bob has no idea who he is talking too other than the fact it is whoever rang him up.
> 
> The Security part in Transport Layer Security is Encryption.  Authentication is lathered on top as an afterthought and requires external measures be taken in order to have*any*  effect whatsoever.

This is unauthenticated Diffie-Hellmann key agreement, essentially.  As 
has been pointed out, it only works if you know that, during the initial 
agreement, you can trust that you are talking directly to who you want 
to talk to without fear of a man in the middle (a passive observer will 
still be foiled).

TLS supports this in the form of anonymous TLS.

Something similar is normally used for opportunistic TLS upgrade with 
e.g. SMTP, but there at least one end (the "server") still presents a 
certificate; the client just doesn't validate it.

Password-authenticated DHKA fixes the above problem, but then you're 
back to the status quo of a preshared secret.  This is, in fact, how the 
DHE* suite of TLS ciphersuites works, AFAIK.  Use PKI to exchange one 
secret (with trust of who you're talking to, where applicable, due to 
the PKI), then use authenticated DH to establish a session secret using 
that as the PSK.  Then throw away that session secret when you're done.

One thing that comes to mind in the context of what others have done is 
to have each router maintain, internally, its own long-term CA and issue 
a peer certificate when a session is first started to its peer.  This 
has the same problem in that the initial session establishment could be 
meddled with but, assuming that does not happen (and it does not, in 
practice, seem especially likely except maybe on an IX), the peer can 
identify itself for the long term.  THrow alarm bells if an unknown peer 
again tries to talk on that configured peer.

That at least gets you some form of long-term security (at the cost of 
possibly NO security if the above assumptions are not met), and it 
happens automatically.

You could do the same thing with a symmetric secret being automatically 
established using DHKA or similar, too, of course.

--
Brandon Martin



More information about the NANOG mailing list