Re: BGP over TLS

[Julien Goodwin <nanog () studio442 com au>]

On 22/10/19 4:04 am, Jared Mauch wrote:
> > On Oct 21, 2019, at 12:30 PM, Joe Abley <jabley () hopcount ca> wrote:
> >
> > On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf () dessus com> wrote:
> >
> > > On Monday, 21 October, 2019 09:44, Robert McKay <robert () mckay com> wrote:
> > >
> > > > The MD5 authentication is built into TCP options.. not obvious how you
> > > > would transport it over TLS which afaik doesn't offer similar
> > > > functionality.
> > >
> > > AHA!  I understand now and sit corrected.  I was under the mistaken impression that MD5 authentication was an 
> > > application level thing, not a TCP level thing.
> >
> > Well, TLS exists within a TCP session, and that TCP session could incorporate the MD5 signature option. I guess.
> >
> > Julien's BGP-STARTTLS idea is interesting. I wonder about the practicality of deploying certificates to every BGP 
> > speaker that are useful for strict checking by neighbours, though. Perhaps I've been too long with my hands out of 
> > routers and things have moved on, but it seems to me that the history of certificate management in routers is not a 
> > rich tapestry of triumph.
>
> It’s not.  I talked about this in the security area session at IETF several meetings ago — the requirements operators 
> have around this space, and it’s quite a pain to be honest.
>
> I’ve seen enough people have issues with managing a password that certificates would be even harder when there’s a 
> router swap.
>
> 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.

Yeah, I come from the perspective not just of a (now former AS15169)
operator, but also often being one of a network's very few peers,
sometimes the only non-transit a network had.

IMO, *requiring* certificates or similar is a step too far at the
moment, however building something that allows for easy extension to
certificates (or whatever) is sensible.

> > Without strict checking in both directions, the threat model with TLS looks pretty similar to that with TCP-MD5 with 
> > not very secret secrets, which I gather is one of the deficiencies that the TLS proposal seeks to address.
>
> This is a whole mess of trouble here due to the disconnect in how routers are managed, the technical capabilities of 
> vendors and where the protocol split lives here.
>
> I will take routers that don’t reboot when we commit them and devices that can be managed automatically vs the 
> keyboard jockey days that we’re all used to.

My personal major gripe with certificate based systems is that many
routers don't have an RTC and won't know what time it is until they can
NTP, which likely requires protocol adjacencies, and then a dependency loop.