BGP over TLS

Grant Taylor gtaylor at tnetconsulting.net
Tue Oct 22 02:04:46 UTC 2019


On 10/21/19 11:04 AM, Jared Mauch wrote:
> I’ve seen enough people have issues with managing a password that 
> certificates would be even harder when there’s a router swap.

I think that's an unfortunate state of affair.  I don't know how to get 
around the PEBKAC problem.

> The issue isn’t that most people want privacy, it’s they want 
> transport integrity which in general the TLS community seems to think 
> everyone NEEDS both.

The biggest argument that I've seen is that you can't truly have privacy 
without integrity.  Lest you be speaking over an encrypted channel with 
an unauthenticated MitM.

My understanding is that authentication is the most important issue and 
that privacy is a nice add-on.

With that in mind, I wonder if we couldn't have each router be it's own 
CA and issue /client/ certificates for and to each neighbor to use to 
authenticate back to the local router.  This has the added advantage 
that you wouldn't need to worry about different routers trusting the 
same CA or bother with PKI.  Everything would be local router centric. 
The neighbor would effectively be using a super fancy key that a 
neighbor provided for use when talking to said neighbor.

I think that using /client/ certificates would also allow for 
certificate rotation in that the router can issue a new /client/ 
certificate while still trusting the existing /client/ certificate. 
Then once the client updates to using the new /client/ certificate, the 
router can revoke the old /client/ certificate using standard CRL methods.

All of this would be centric to the local router.

I suspect that it would likely be okay to have longer lived certificates 
in such a configuration.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191021/a2ae379d/attachment.bin>


More information about the NANOG mailing list