On Thu, Oct 24, 2019 at 9:33 AM <adamv0025@netconsultings.com> wrote:
From: Christopher Morrow <morrowc.lists@gmail.com> Sent: Wednesday, October 23, 2019 6:53 PM Subject: Re: BGP over TLS
On Wed, Oct 23, 2019 at 10:43 AM <adamv0025@netconsultings.com> wrote:
Sent: Tuesday, October 22, 2019 8:26 PM To: Keith Medcalf <kmedcalf@dessus.com>
No,
On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
At this point further communications are encrypted and secure against eavesdropping.
The problem isn't the protocol being eavesdropped on. The data is already published publicly by many people.
The problem is one of mutual authentication and authorization of the transport.
Yes the information is public but if the routing information exchanged over a given peering session is tempered with that could potentially cause some problems right?
'mutual authentication' CAN be the thing (via tcp md5 today) that does this 'do not tamper' part. there ARE problems with tcp-md5... some are "because we collectively didnt' squeak enough to get key-tables" some are: "err, doing low-level-kernel-muckery is gross".
But then again, as Jeff mentioned, with GTSM this vector is limited to a local link between two eBGP speakers (or whole IGP domain for iBGP sessions but let's leave that one out for now).
ibgp, it turns out, is important.
Well yes and that's why we all have internet plane RR infrastructure separate to the RR infrastructure(s) distributing information for other services right? And is also why we all filter non-standard or even non-usual BGP attributes and unusually long AS paths and community lists on ingress to our AS, just to safeguard our BGP infrastructure. ...yeah about that.
sounds right, yes. There's at least 1 BCP that talks about this... and some BCOP's from ripe/nanog as well I think?
So move from bilateral peering over common IX-LAN to direct peering Or if a direct link is still not to be trusted do MACSEC. Then it's all about you and the peer -if he/she screws you over de-peer.
and it burning a 100g port on a chassis for ~1g (or less) of traffic is worthwhile... Sure cause the usual math is if I have 100G to IX LAN which is half empty then going direct means 100G x number of peers I'd like to move to direct peering...
Sorry, I skipped a sentence figuring it wasn't worth typing, but ... "100g is the new 10g which was the new 1g ... and on 100g platforms you often don't get 1g as well... it's harder to delivery 10G (almost) than 100g :( " So default at the edge is moving to 100g for some folk
there's lots of variables here... options are nice to have... better security for /not just my IX/ bgp would be nice too :)
Well yes I do agree with that statement on a sentimental level almost.
But pragmatically I'd have to ask what big of a problem is BGP over TLS going to solve and how much would it cost. Ideally the solution would tick all these 3 together: 1) it's a panacea (solves all aspects of the problem), 2) it's zero effort (development and getting it to the network) 3) it solves a huge problem, (operators are struggling with the effects of this problem on a daily bases)
sure... I don't have a cogent answer to all of these, but if you believe there's a need for authentication / integrity / privacy on some/all of your BGP sessions, you probably want: 1) something that rotates regularly instead of static md5 would be great because everyone's md5 secret is public, regardless of your efforts to secure that data :( 2) something that doesn't require operator interference to enable/rotate/manage would be nice one main complaint about md5 is it's very hard to setup reliably, folk don't record the keys, etc. "argh, peer didn't come up, rm-rf-key.. look working now!" making that more straightforward and less error prone would be good. -chris