Re: [secdir] Security review of draft-ietf-ippm-ipsec-08

[Kostas Pentikousis <[e-mail]>]

Hi Hannes,

<snip>

| comments were written primarily for the benefit of the security area
| directors.  Document editors and WG chairs should treat these comments just
| like any other last call comments.

Many thanks for the thorough review. Much appreciated.

<snip>


| In the introduction you point out that IKEv2 is very commonly deployed.
| You even say that "In mobile telecommunication networks, the deployment rate
| of IPsec exceeds 95% with respect to the LTE serving network."
| 
| While the exact number is probably not that important (and very likely hard to

This text originates from the motivation that got this draft going. In particular, the nearly 10-year old RFC 4656 argues in sec. 6.6 (https://tools.ietf.org/html/rfc4656#section-6.6), among other things, that 

     "The deployment paths of IPsec and OWAMP could be separate if OWAMP
      does not depend on IPsec.  After nine years of IPsec, only 0.05%
      of traffic on an advanced backbone network, such as Abilene, uses
      IPsec (for comparison purposes with encryption above layer 4, SSH
      use is at 2-4% and HTTPS use is at 0.2-0.6%).  It is desirable to
      be able to deploy OWAMP on as large a number of different
      platforms as possible."

I don't think we need to argue about the numbers for IPsec, HTTPS and so on today (esp. as we look towards 2020), but I would make the case that it's likely that IPsec is more widely deployed today than OWAMP is. Perhaps I'm wrong, please correct me. Hence, during the early phase of development of this draft we included this text to illustrate eminent use cases for this draft (such as the LTE case). If you think that "95%" should be replaced with "the vast majority of" or something of that nature, please let us know. If you have completely different numbers from operators, research studies or vendors for this type of deployment (or other settings for that matter), I'll be happy to hear them. 


| verify) the statement does, however, raise some questions. You seem to expect
| that you can re-use already deployed IKEv2 for the special version of IKEv2
| you are describing in this document and that's unfortunately very unlikely to
| be true.

I don't agree this is the case when I read the text.

 
| The solution described in the document requires a very tight integration
| between an IKEv2 implementation (not IPsec) and the O/TWAMP application and
| the text in the document gives me the impression that you are not entirely
| aware that this will actually need to happen. This may lead to unpleasant
| surprises when you implement it.

I don't agree with the term "very tight integration". In fact, we had the API discussion several times with folks in ipsecme over the last 2 years and a bit. I heard some of the background, and I agree that perhaps an IPsec vendor with *no interest in TWAMP* may have to think more if they want to invest the effort to support this spec. But for vendors with both implementations in house, I would leave it to their respective implementation teams. This spec would facilitate interoperability in this latter case.

As an aside, and given that this is an IPPM draft, I would like to point out that TWAMP per se (RFC 5357, sec. 1.2: https://tools.ietf.org/html/rfc5357#section-1.2) does leave certain interactions "unspecified", which "may be proprietary protocols".

| First, you will have to trigger the IKEv2 exchange from the application.
| Second, you definitely do not want the IKEv2 exchange to create IPsec SAs

<snip>

| "IPPM" ). IMHO no off-the-shelf IKEv2 implementation will let applications
| access the SK_d directly nor will it have an API to the IKEv2 SA either.

Agreed, wrt "off-the-shelf" (in general), after all this is not an RFC yet. But please see above.


| It might also want to think about potential interactions from the
| IKEv2-> to O/TWAMP side, such as rekeying. I am not sure whether there
| are issues to take into account but have you thought about them?

This is addressed in the last paragraph of sec. 5.1 (https://tools.ietf.org/html/draft-ietf-ippm-ipsec-09#section-5.1). If you would like other text to be added or this to be edited, please kindly send a proposal.

<snip>


| In Section 5.1 you describe a way to obtain for the O/TWAMP implementation to
| interact with the IKEv2 code as follows:
| 
| "
|    the IPSec layer can perform a lookup
|    in the Security Association Database (SAD) using the IP address of
|    the server and thus match the corresponding IKEv2 SA.  At the server
|    side, the IPSec layer can look up the corresponding IKEv2 SA by using
|    the SPIs sent by the client, and therefore extract the shared secret "
| 
| I believe that this approach will not work since your use of IKEv2 shouldn't
| actually require any interaction with IPsec at all.

We use IPsec to refer to IKE+ESP/AH in this draft. If you would like to propose alternative, better refined text, please let us know.

<snip>


| I could imagine that a network management protocol could be used to provision
| the shared secrets to the appropriate nodes. While public key cryptography
| makes some aspects of the key distribution easier it does raise other
| questions, such as distribution of trust anchors and the question about
| authorization. Since you do not discuss authorization in the document I am not
| sure it is of concern with the use of O/TWAMP.

Indeed, a network management protocol _could_ be used, but this is not standardized and, imo, orthogonal to the problem at hand. Perhaps we should start a separate draft for OAM-based shared secret distribution for TWAMP.


| I am not sure why you include the text in Section 5.4 where you describe
| O/TWAMP over an IPsec tunnel since in the introduction you argue that this is
| not an approach that you favour since it introduces delays into the
| measurements.

This was introduced as part of the consensus process in the WG. If your comment is editorial in nature, then [editor hat on] I would let it go [editor hat off]. If it's substantial, blocking, then I would be happy to remove sec. 5.4. Mind you, several parts of the draft have been repeatedly tuned to reach consensus over the last 2 years.


| I am also wondering whether this solution offers crypto agility. The text
| describes that you use AES-CBC (for encryption) and HMAC-SHA1 (for data origin
| authentication and integrity protection). IKEv2 could, of course, allow you to
| negotiate other algorithms and particularly the more modern AEAD ciphers.

AES-CBC and HMAC-SHA1 are algorithms defined in the O/TWAMP RFCs. Perhaps there is space for another draft in this direction as well, i.e. to allow for more crypto agility in TWAMP beyond has been standardized so far.


| In a few parts of the document you say "
|    The new Modes value indicating support for this
|    specification is IKEv2Derived and is equal to 128 (i.e. bit set in
|    position 7) [NOTE to IANA: remove before allocation and final
| publication]".
| 
| I am not sure what you are asking IANA to do. I believe what you are trying to
| say is that you have proposed a specific value for this extension and you want
| IANA to confirm that allocation.

<snip>

Done in -09


| I would also remove this paragraph in the Security Consideration section:
| 
| 
| "
|    As a more general note, the IPPM community may want to revisit the
|    arguments listed in [RFC4656], Sec. 6.6.  Other widely-used Internet
|    security mechanisms, such as TLS and DTLS, may also be considered for
|    future use over and above of what is already specified in [RFC4656]
|    [RFC5357].
| "
| 
| While it is true that DTLS/TLS could also used (and are probably a better
| choice) it feels like the wrong statement in this document. It makes the
| reader feel like that even the authors are not convinced that this is the
| right solution approach.

We have removed this paragraph in -09, as per your request: http://www.ietf.org/rfcdiff?url1=draft-ietf-ippm-ipsec-08&url2=draft-ietf-ippm-ipsec-09. However, this brings us back to motivation discussion at the beginning of this email.

Once again, many thanks.

Best regards,

Kostas