Hi Linda, > requiring Data Plan BGP session to be completely separate from the Management Plane BGP session, is it Okay?
As I mentioned offline there is no distinction in BGP for data plane BGP session vs Mgmt Plane BGP session. BGP session is a BGP session - pure TCP stream of packets which is pretty trivial to intercept, decode, hijack, etc .... Moreover BGP messages are designed to be flooded everywhere in a p2mp fashion. Even if you add "NO-ADVERTISE" BGP community to it - communities can get stripped automatically on any BGP speaker. Hence you clean your sole safety protection. The question I would like to state and understood - why are you trying so hard to use BGP for IPSec secret key distribution ? Is this only due to the fact that you have it there ? Wasn't IKE and now improved IKEv2 specifically designed to do just that ? Any reason you don't want to use it ? Thx, R. On Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar <[email protected]> wrote: > Eric, > > > > Thank you very much for the detailed explanation. > > > > I meant to ask about using BGP UPDATEs of a unique AFI/SAFI to distribute > the “Public Keys” and individual “Nonce” to all the CPEs. Just like IKE > (where peers exchange public key over internet), now the Public keys are > exchanged between peers via RR (Controller). With this approach, the CPEs > can offload the Peer Authentication job to Controller. > > > > IPsec’s Diffie-Hellman algorithm use “Public Key” and CPE’s Private Key > to compute the actual Security Association. > > > > In your draft-rosen-bess-secure-l3vpn-01, you have BLACK BGP session and > RED BGP session, and emphasized on how BLACK BGP not leaking routes to RED > BGP. I want to know if we can do the same for Management BGP session, i.e.. > requiring Data Plan BGP session to be completely separate from the > Management Plane BGP session, is it Okay? > > > > Thanks, Linda Dunbar > > > > > > > > *From:* Eric C Rosen [mailto:[email protected]] > *Sent:* Thursday, August 16, 2018 2:59 PM > *To:* Linda Dunbar <[email protected]>; [email protected]; > [email protected]; Jeff Tantsura <[email protected]>; RTGWG < > [email protected]> > *Subject:* Re: Preventing BGP Route leak (Hijack) for Management Channel > BGP session > > > > 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 > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
