[Idr] additional mic comments on security/IPsec

[Benjamin Kaduk <[e-mail]>]

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