BGP over TLS

Tue Oct 22 15:52:11 UTC 2019

On Tue, Oct 22, 2019 at 6:35 AM Julien Goodwin <nanog at studio442.com.au> wrote:
>
>
>
> On 22/10/19 4:04 am, Jared Mauch wrote:
> >
> >
> >> On Oct 21, 2019, at 12:30 PM, Joe Abley <jabley at hopcount.ca> wrote:
> >>
> >> On 21 Oct 2019, at 12:05, Keith Medcalf <kmedcalf at dessus.com> wrote:
> >>
> >>> On Monday, 21 October, 2019 09:44, Robert McKay <robert at 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.

TLS in the traditional sense 'requires' that there be an X.509
certificate to use in authenticating (and to some extent authorizing -
can you be a CA? sign email? etc...) endpoints, ideally you do 'tls
mutual authentication'...

The x.509 system, to be effective here would require a TrustAnchor /
Root-of-Trust that both parties agreed was acceptable...
Julien, you are asserting that: "yea, but that's hard, because
Julien-net and Chris-net may agree on 'bobs bait and tackle CA', but
certainly Jared-net is obstinate and will required only the CA at
"Sams Veggie Hut & CA"" ... so we'd end up with managing a 'worse'
version of the web-PKI on network devices.

To get around that you propose we hopscotch over to 'TLS with
preshared keys (PSK)'... ok, that smells nice, it's NOT a kernel/tcp
option (hurray) it's possibly safer-ish. I think Jared's point that;
"this is just gussied up md5..." isn't wrong, it is nice that this
isn't in the kernel path (tcp-md5/tcp-ao HA)... I think that really
it'd need some method to change PSK though over time in a sane
fashion, ie the 'key table' that is used in other places for this sort
of problem.

Internally folk that wanted could use their own CA infra to operate /
use certs on their iBGP sessions, or customer sessions... and maybe
later in our lifetime we could re-use the certs that RPKI distributes
as the certs for bgp session security ? (I think there are some pretty
draconian restrictions on the certs here, but I don't remember off the
top of my head what those are right now.)

> >> 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.

this is also a problem, but really ... your igp should get you to an
NTP source... or we'd all get to that fairly quickly, right? :)
  (some of this is updating 'best practices' in building / maintaining
a network, right?)