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

[Benjamin Kaduk <[e-mail]>]

On Mon, Aug 05, 2019 at 10:29:16PM +0000, Hu, Jun (Nokia - US/Mountain View) wrote:
> Hi Ben,
> Thanks for your comments, my replies are in line as [Hu Jun]
> 
> -----Original Message-----
> From: Idr <[e-mail]> On Behalf Of Benjamin Kaduk
> Sent: Friday, August 2, 2019 12:16 PM
> To: [e-mail]
> 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

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.

> 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)

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

> 
> 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.
> [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr