On Wed, Oct 23, 2019 at 10:43 AM <adamv0...@netconsultings.com> wrote: > > > Sent: Tuesday, October 22, 2019 8:26 PM > > To: Keith Medcalf <kmedc...@dessus.com> > > > > No, > > > > > > > On Oct 22, 2019, at 2:08 PM, Keith Medcalf <kmedc...@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 :)