Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session

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 <linda.dunbar@huawei.com>
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:erosen@juniper.net]
> *Sent:* Thursday, August 16, 2018 2:59 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>; shares@ndzh.com;
> idr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG <
> rtgwg@ietf.org>
> *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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>