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
