BGP over TLS

Fri Oct 25 06:07:40 UTC 2019

On Thu, Oct 24, 2019 at 9:33 AM <adamv0025 at netconsultings.com> wrote:
>
> > From: Christopher Morrow <morrowc.lists at 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 at netconsultings.com> wrote:
> > >
> > > > Sent: Tuesday, October 22, 2019 8:26 PM
> > > > To: Keith Medcalf <kmedcalf at dessus.com>
> > > >
> > > > No,
> > > >
> > > >
> > > > > On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedcalf at 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