On Tue, Oct 22, 2019 at 6:35 AM Julien Goodwin <nanog@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@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.
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?)