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