Thanks Eric for your analysis! Linda - Eric confirmed wg feedback and explained in great details why using BGP for key distribution (while appealing) is not a great idea, you could add to that use of group keys, so in case of a breach, whole group becomes compromised (obviously there’s more to that, greatly generalized statement). Let’s move on.
Thanks, Jeff On Thu, Aug 16, 2018 at 12:59 Eric C Rosen <[email protected]> wrote: > On 8/13/2018 3:26 PM, Linda Dunbar wrote: > > One of the comments to > https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=RToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&s=9xbKYj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&e=> > the In RTGwg session of IETF102 is that using BGP session to pass > configuration keys for IPsec can be risky even if the path between RR & > node is secure (say via TLS) due to BGP route leak (Hijack). > > But the BGP session to carry IPsec configurations is via BGP management > session, which is completely isolated form the dataplane BGP sessions. > > > I'm not sure I have the whole context, but the question seems to be > whether it could ever be safe to use BGP to distribute secret keys. > > Presumably: > > - The keys would be carried in an attribute that can only be attached by > UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used > to carry management/configuration information. > > - UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are > adequately secured so as to provide privacy, integrity and authentication.. > > - The UPDATEs would carry the NO_ADVERTISE community (to make sure they > are not propagated further). > > - None of the BGP systems involved would allow any sort of "BGP > monitoring" that might expose the unencrypted contents of the UPDATEs. > > In this scenario, I don't think it matters whether the secure BGP session > also carries other AFI/SAFIs. > > The privacy properties of this scenario are pretty good, in theory, but I > don't think they are really good enough for distributing secret keys. > > - Once you're using BGP to distribute information, it is inevitable that > someone will decide to remove the "NO_ADVERTISE" and allow the information > to be propagated through intermediate nodes (RRs or ASBRs) to the actual > target node. After all, one of the main values of using BGP to distribute > stuff is that you get a big distribution system. Even if all the > intermediate nodes are trusted and all the intermediate BGP sessions have > adequate privacy/integrity/authentication, you still wouldn't want to > expose the secret keys to those nodes. You might trust those nodes to see > all the routing information, and even to see most of the management > information, but you probably don't want them to see all the secret keys. > And you probably don't want the secret keys stored in the clear on those > intermediate nodes. > > - I would worry about BGP monitoring procedures creating a backdoor > through which the secret keys would be exposed. > > - No matter how careful you are, when you use BGP you can be pretty sure > that your UPDATEs will end up somewhere they're not supposed to go. It's > just too easy to make mistakes. > So I don't think I'd try to do dynamic keying by attaching the actual keys > to BGP UPDATEs. At most I'd use BGP to distribute parameters that could > then be used by something like IKEv2 to actually fetch the secret keys. > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
