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

[Jeff Tantsura <[e-mail]>]

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 <[e-mail]> 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.
>
>