Telechat Review of draft-ietf-ippm-ipsec-09

Request Review of draft-ietf-ippm-ipsec
Requested rev. no specific revision (document currently at 11)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2015-04-07
Requested 2015-04-02
Authors Kostas Pentikousis, Emma Zhang, Yang Cui
Draft last updated 2015-04-09
Completed reviews Genart Last Call review of -08 by Meral Shirazipour (diff)
Genart Telechat review of -09 by Meral Shirazipour (diff)
Secdir Last Call review of -08 by Hannes Tschofenig (diff)
Secdir Telechat review of -09 by Hannes Tschofenig (diff)
Opsdir Last Call review of -08 by Fred Baker (diff)
Assignment Reviewer Hannes Tschofenig
State Completed
Review review-ietf-ippm-ipsec-09-secdir-telechat-tschofenig-2015-04-09
Reviewed rev. 09 (document currently at 11)
Review result Has Issues
Review completed: 2015-04-09


Hi Kostas,

thanks for responding to my review.

A few remarks inline.

On 02/12/2015 01:29 PM, Kostas Pentikousis wrote:
> 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
> (

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

I just got a hung up on the numbers you mention since you do not provide
any description of where these numbers came from. So, I would prefer to
say something like widely deployed or so.

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

When you talk in the introduction about the widespread deployment of
IPsec and IKEv2 in operator networks, then state that using IPsec /
IKEv2 is a "viable alternative" for protecting O/TWAMP
and then document the solution then it is easy to come up with the idea
this existing deployment can be re-used.

I believe that the reason for stating that IPsec/IKEv2 is already so
widely deployed is to create the argument for going with the IPsec/IKEv2
solution approach.

In all fairness for operators, who read this specification, they should
not be under the impression that they can might necessarily be able to
re-use their existing IPsec/IKEv2 stack since the described solution is
a bit special IMHO.

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

What was the outcome of that discussion? Can you send me a pointer to it?

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

Of course, an IPsec VPN vendor who provides a solution as described
in the document will not encounter a problem. This, however, supports
my impression that a random IPsec VPN solution (I call it
"of-the-shelve" stack) might not work.

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

It is great to describe aspects that concern interoperability
but it is also important to point to potential
implementation/operational issues.

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

) does leave certain
> interactions "unspecified", which "may be proprietary protocols".

... which is not good for interoperability.

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

> If you would like other text to be added or this to be edited, please
> kindly send a proposal.
> <snip>

Here is the current text:


   If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the
   corresponding shared secret key generated from the SA can continue to
   be used until the O/TWAMP session terminates.

I would prefer to have this paragraph written in a normative way (i.e.,
using RFC 2119 language). It seems that you leave it up to the
implementation on how to react to re-keying / IKEv2 SA deletion.
Wouldn't this create potential issues when one side decides to derive
new keying material and the other side doesn't? What happens if one side
has the policy to delete the O/TWAMP keying material in response to the
IKEv2 SA being deleted?

Was there a reason why rekeying of an IKEv2 SA shouldn't lead to new
keying material be derived mandatorily? Also, one would think when the
underlying IKEv2 SA is deleted then the keying material for the O/TWAMP
also be deleted.

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

In the above paragraph I have been trying to express a question
regarding authorization. In a shared secret environment the
authorization procedure is often dealt-with implicitly but with public
key cryptography you have to deal with authorization separate. How do
you expect authorization to be handled here?

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

Since I have not participated in the working group I am not aware of
these discussions. Just from reading the document it felt a bit strange
to find the text in Section 5.4 while the introduction argues differently.

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

It is up to the IESG to decide how to take crypto agility in IETF
specifications into account.

I personally would make use of IKEv2 (and the algorithm negotiation
capabilities) as well as take steps to support state-of-the-art algorithms.

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

> However, this brings us back to motivation discussion at the
> beginning of this email.

Thanks. Btw, I also agree with you that DTLS would have been a better
choice ...

A last question: Has someone implemented this specification? I am
curious about the challenges they ran into.


> Once again, many thanks.
> Best regards,
> Kostas




 OpenPGP digital signature