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

From: Linda Dunbar <[email-masked]>
Date: Mon, 13 Aug 2018 19:26:56 +0000

One of the comments to https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/ 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.

Does it still post a risk?

Linda Dunbar

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 16 Aug 2018 15:59:16 -0400

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.

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Aug 2018 15:23:35 -0700

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-masked]> wrote:

> 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.
>
>
> UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used
> to carry management/configuration information.
>
> 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.
>
> 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.
>
> 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.
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 16 Aug 2018 22:59:24 +0000

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-masked]]
Sent: Thursday, August 16, 2018 2:59 PM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]; Jeff Tantsura <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: Preventing BGP Route leak (Hijack) for Management Channel BGP session

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.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Aug 2018 11:20:06 +0200

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-masked]>
wrote:

> 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-masked]]
> *Sent:* Thursday, August 16, 2018 2:59 PM
> *To:* Linda Dunbar <[email-masked]>; [email-masked];
> [email-masked]; Jeff Tantsura <[email-masked]>; RTGWG <
> [email-masked]>
> *Subject:* Re: Preventing BGP Route leak (Hijack) for Management Channel
> BGP session
>
>
>
> One of the comments to https://datatracker.ietf.org/
> doc/draft-dm-net2cloud-gap-analysis/
> session, which is completely isolated form the dataplane BGP sessions..
>
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 17 Aug 2018 20:37:05 +0000

Robert,

Actually IPsec Public key being hijacked doesn’t pose any issue to IPsec because the IPsec key is generated by Public & Private key, like IKEv2 is exchanged over public internet, while anyone can see it.

Using BGP’s RR to exchange the Public key is to avoid the Peer Authentication requirement on the Resource Constraint CPEs & virtual CPEs.
Of cause, we can use some kind Registration protocols, such as NHRP, to do the job.
Since those CPEs already support BGP, leveraging BGP update is less processing on those resource constraint CPEs than supporting another new protocol.

Linda

From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, August 17, 2018 4:20 AM
To: Linda Dunbar <[email-masked]>
Cc: Eric C Rosen <[email-masked]>; [email-masked]; RTGWG <[email-masked]>
Subject: Re: 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 <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

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.

Thanks, Linda Dunbar

From: Eric C Rosen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 16, 2018 2:59 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; RTGWG <[email-masked]<mailto:[email-masked]>>
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..

Presumably:

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 17 Aug 2018 14:51:37 -0700

/as working group contributor

Linda,

I disagree with “already support BGP” point as the right argument to use BGP for key distribution.

In most cases, after booting up  1st time, CPE would “call back home” to activate and obtain right SW, config, etc

BGP session(s) would be configured/activated later

Cheers,

Jeff

From: rtgwg <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Friday, August 17, 2018 at 13:37
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, RTGWG <[email-masked]>
Subject: RE: Preventing BGP Route leak (Hijack) for Management Channel BGP session

Robert, 

Linda

Hi Linda,

Thx,

R.

On Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar <[email-masked]> wrote:

Eric, 

Thanks, Linda Dunbar

Presumably:

_______________________________________________ rtgwg mailing list [email-masked] https://www.ietf.org/mailman/listinfo/rtgwg