Subject: [Idr] additional mic comments on security/IPsec

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 2 Aug 2019 14:16:29 -0500

Hi all,

Stealing Paul's subject line, and with apologies for the slowness in
sending, let me expound a bit more on my comments from the mic line
regarding the IPsec-related documents.

My intention was to look at a high-level picture that might be appropriate
for all three of the documents in question, to make sure that we're
thinking about the right aspects as we do the protocol analysis for these
proposals; that does, of course, mean that there's some risk that not all
comments will apply to all documents.

First off, when we start to get IPsec config via BGP, it's helpful to think
of what other information we get in the same way, and to analyze the
effects of misconfiguration or malicious configuration both on IPsec and on
the broader system.  For example, if we are getting NLRI from BGP, then a
misconfiguration that gives us parameters that are incompatible with a
peer's is not causing particularly new harm, since we could just as easily
be told that the peer is unreachable and we wouldn't try to talk to them
anyway.  On the other hand, we could be given configuration to use
computationally expensive algorithms, which would increase the DoS risk in
a way that may not (or may!) already be possible.

It's also important to remind ourselves what the goal of using IPsec is --
IIRC all the schemes presented are using ESP, and so desire data
confidentiality.  But confidentiality from whom, and the authentication of
the peer remain important questions.  If the configuration obtained via BGP
influences how we determine what the valid peer identities are, then we
could end up producing a "secure" IPsec ESP connection to a peer that we've
"successfully authenticated", and yet still not achieve the data
confidentiality that we intended, if the peer we authenticated is actually
an attacker.  In a single administrative domain (as in Jun's draft) where
the BGP messages with configuration are already going over (preconfigured)
IPSec, there is unlikely to be any problem, but once we start getting into
scenarios with multiple administrative domains the analysis can get a lot
more complicated.

In a related vein, adding IPsec configuration to the mix means that we now
have two types of information relating to connectivity/connections -- the
network layer information inherent to BGP but also IPsec configuration
about IKE parameters to use with which peers and traffic selectors for what
traffic to send where.  Ensuring consistency between these two classes of
information will be important (and probably left to local
enforcement/policy).

With respect to the question of what to do when conflicting configuration
is received (e.g., via different BGP peers), the normal
priority/tie-breaking scheme already used for NRLI should be fine.  The
important matter is that all parties agree on the scheme that's used; the
specific algorithm is probably less important.

I did also have a few comments about the specific technology presentations:

Jun's presentation seemed fairly boring from a security perspective (that's
a good thing!) -- within a single administrative domain and just
distributing configuration parameters before running normal IKEv2 is pretty
much using the protcol as intended.  Assuming the IKEv2 implementation
isn't willing to accept nonsense parameters (or the local agent does sanity
checking), I'm not very worried about this.

For the SDWAN case, one of the biggest security risks I see is tracking
when traffic is going over the (trusted) MPLS path vs. the open Internet.
Keeping consistency between the IPsec configuration and the network-layer
routing is very important here, and similarly for the site-ID/node-ID
information (sorry, my notes are pretty vague on the last part).  It may be
possible to have local policy enforce sanity checks on the respective
configurations.  (That said, many in the security community remain
skeptical that "secure networks" are always so and will remain so
indefinitely, but this is not the place for that debate.)

For "controller-IKE", I'm willing to accept that there are external factors
(to IKE) motivating the desire to use the controller to distribute
configuration/keying information, even if the concrete details of the
scaling improvements remain a little hazy (this is the "messages" vs.
"bytes" question, basically, but I don't feel a need to reiterate it at the
moment).  Another factor that stuck out to me was the note about how in
some cases the connection to the controller is "securely provisioned"
whereas the full mesh of connections is less so; that will be important to
keep in mind when doing the security analysis, especially if it is a
property that can be guaranteed for all deployments.  Paul's point about
the loss of unique per-peer key material and the corresponding weakening of
the security properties is also important to consider, though.

Thanks for the interesting talks (and for asking us to come by early in the
process)!

-Ben

---

From: "Hu, Jun (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 5 Aug 2019 22:29:16 +0000

Hi Ben,
Thanks for your comments, my replies are in line as [Hu Jun]

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Friday, August 2, 2019 12:16 PM
To: [email-masked]
Subject: [Idr] additional mic comments on security/IPsec

Hi all,

Stealing Paul's subject line, and with apologies for the slowness in sending, let me expound a bit more on my comments from the mic line regarding the IPsec-related documents.

My intention was to look at a high-level picture that might be appropriate for all three of the documents in question, to make sure that we're thinking about the right aspects as we do the protocol analysis for these proposals; that does, of course, mean that there's some risk that not all comments will apply to all documents.

First off, when we start to get IPsec config via BGP, it's helpful to think of what other information we get in the same way, and to analyze the effects of misconfiguration or malicious configuration both on IPsec and on the broader system.  For example, if we are getting NLRI from BGP, then a misconfiguration that gives us parameters that are incompatible with a peer's is not causing particularly new harm, since we could just as easily be told that the peer is unreachable and we wouldn't try to talk to them anyway.  On the other hand, we could be given configuration to use computationally expensive algorithms, which would increase the DoS risk in a way that may not (or may!) already be possible.

[Hu Jun] for DoS attack with crafted malicious IPsec config in BGP update, with my draft, just like you said, single admin domain is less likely to have this problem;
In case of multi admin domains (although not focused, but my draft could also be used in multi-domain) , there are existing security mechanisms on both BGP and IKEv2 level to prevent DoS attack:
- BGP: origin validation, filter, BGPsec could be used to check the validity of a BGP update
- IKEv2: cookie, puzzles(RFC8019)
Beside above protocol level protection, there are additional implementation level mechanisms could be employed:
- limit the number of on-going IKEv2 negotiation 
- for tunnel initiator, if a given peer is keep failing IKEv2 negotiation, it could be put into a hold-down state 
- have a local list of allowed crypto-alg, check it against received IPsec config

It's also important to remind ourselves what the goal of using IPsec is -- IIRC all the schemes presented are using ESP, and so desire data confidentiality.  But confidentiality from whom, and the authentication of the peer remain important questions.  If the configuration obtained via BGP influences how we determine what the valid peer identities are, then we could end up producing a "secure" IPsec ESP connection to a peer that we've "successfully authenticated", and yet still not achieve the data confidentiality that we intended, if the peer we authenticated is actually an attacker.  In a single administrative domain (as in Jun's draft) where the BGP messages with configuration are already going over (preconfigured) IPSec, there is unlikely to be any problem, but once we start getting into scenarios with multiple administrative domains the analysis can get a lot more complicated.

[Hu Jun] with my draft, the BGP is not necessary running over a preconfigure IPsec tunnel; in fact, since the purpose of draft is to make IPsec config provision simpler, I expect there is no pre-configured IPsec in common cases; but I don't think it is an issue even BGP is not running over IPsec, as long as the both sides have IKEv2 auth credential that ties to its identity (e.g. tunnel endpoint address) , e.g. a certificate issued by a trusted CA, existing IKEv2 authentication mechanism will make sure peer is authenticated;
In case of multi admin domains, it is more complex, but is still doable as long as all domains agree on IKEv2 auth method and credentials (e.g. trusted CA), and some local mechanism to make sure for which domain use which auth method and credential (for example: for domain-1 uses IPsec config color-1 , auth method certificate, trust-CA: CA-1, for domain-2 uses IPsec config color-2 , auth method certificate, trust-CA: CA-2)

In a related vein, adding IPsec configuration to the mix means that we now have two types of information relating to connectivity/connections -- the network layer information inherent to BGP but also IPsec configuration about IKE parameters to use with which peers and traffic selectors for what traffic to send where.  Ensuring consistency between these two classes of information will be important (and probably left to local enforcement/policy).

With respect to the question of what to do when conflicting configuration is received (e.g., via different BGP peers), the normal priority/tie-breaking scheme already used for NRLI should be fine.  The important matter is that all parties agree on the scheme that's used; the specific algorithm is probably less important.

Jun's presentation seemed fairly boring from a security perspective (that's a good thing!) -- within a single administrative domain and just distributing configuration parameters before running normal IKEv2 is pretty much using the protcol as intended.  Assuming the IKEv2 implementation isn't willing to accept nonsense parameters (or the local agent does sanity checking), I'm not very worried about this.
[Hu Jun] yes, for security boring is good,😊

For the SDWAN case, one of the biggest security risks I see is tracking when traffic is going over the (trusted) MPLS path vs. the open Internet.
Keeping consistency between the IPsec configuration and the network-layer routing is very important here, and similarly for the site-ID/node-ID information (sorry, my notes are pretty vague on the last part).  It may be possible to have local policy enforce sanity checks on the respective configurations.  (That said, many in the security community remain skeptical that "secure networks" are always so and will remain so indefinitely, but this is not the place for that debate.)

For "controller-IKE", I'm willing to accept that there are external factors (to IKE) motivating the desire to use the controller to distribute configuration/keying information, even if the concrete details of the scaling improvements remain a little hazy (this is the "messages" vs.
"bytes" question, basically, but I don't feel a need to reiterate it at the moment).  Another factor that stuck out to me was the note about how in some cases the connection to the controller is "securely provisioned"
whereas the full mesh of connections is less so; that will be important to keep in mind when doing the security analysis, especially if it is a property that can be guaranteed for all deployments.  Paul's point about the loss of unique per-peer key material and the corresponding weakening of the security properties is also important to consider, though.

Thanks for the interesting talks (and for asking us to come by early in the process)!

-Ben

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Aug 2019 12:59:48 -0500

> - have a local list of allowed crypto-alg, check it against received IPsec config

Thanks for clarifying.  The last one especially is probably worth
emphasizing in the documents we produce, but also to note that it is
important for the policy ("local list") to be able to change over time as
best practices change.

> In case of multi admin domains, it is more complex, but is still doable as long as all domains agree on IKEv2 auth method and credentials (e.g. trusted CA), and some local mechanism to make sure fo…

Indeed, this then becomes an authorization problem/question.  For the
single admin domain, what you describe is in effect using a very weak
authorization policy of "anyone that my trusted CA has certified is
authorized to talk to me", and as you note, that authorization policy
doesn't cut it anymore in the multi-admin-domain case.  Most likely the
specific authorization policy in use will be a matter of site policy, so
all we can do is provide guidance on what attributes to consider in setting
that policy.

-Ben