BGP over TLS

Wed Oct 23 17:54:57 UTC 2019

On Wed, Oct 23, 2019 at 11:18 AM Alain Hebert <ahebert at pubnix.net> wrote:
>
>     I do not have much to contribute but this.
>
>     We already have ( choose your poison(s) )
>
>         Dark Fiber + MACsec + BCP38 + ACL + MD5 + MPLS + IRRD + GRE + IPsec + yadi yada

much of this isn't solving the problem though, and adding complexity
and layers to the problem, right?

>         PS: Yup, I have SRX300s doing BGP over NNI -and- a GRE + IPsec on LTE as a backup.
>

sure everyone can cook up a loony solution.. but in the general case
of my iBGP cross-country (or cross-ocean) it'd be nice to not have to
do a bunch of really heavyweight things just to get better
authen/integrity/<privacy> for my bgp traffic, I think.

>     What is the real endgame from the people(s) proposing "BGP over TLS"?  It feel like someone is trying to create a job for himself over a solution in search of a problem.
>
> -----
> Alain Hebert                                ahebert at pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
>
> On 2019-10-23 10:42, 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?
>
> 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).
> 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.
>
> adam
>
>
>
>
>