BGP over TLS

[morrowc.lists at gmail.com (Christopher Morrow)]

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.

> 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...
there's lots of variables here... options are nice to have... better
security for /not just my IX/ bgp would be nice too :)