BGP over TLS

Wed Oct 23 15:17:17 UTC 2019

     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

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

     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
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191023/f31d9b41/attachment.html>