I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These 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.

Summary: The specification proposes to derive keying material from an
IKEv2 exchange to secure the One-way Active Measurement Protocol (OWAMP)
[RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) protocols.

Introduction:

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

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.

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 since you only want the outcome of the exchange to produce the
keying material as input to the O/TWAMP protocol via the already
standardized pre-shared authentication exchange. Third, when the IKEv2
exchange is finished it needs to notify the application that the keying
material is ready. The new key derivation function described in Section
5.1 is obviously not available in any IKEv2 implementation and, as you
correctly stated, you don't want to make export the SK_d directly to the
application but rather only the output of the derivation, namely prf(
SK_d, "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.

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?

It might be wortwhile to talk to people who used IKEv2 in a way similar
to what you are proposing (namely for not establishing IPsec SAs). While
there may not be that many of such standardization development I
remember that there was some work in the routing area.

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.

A small note on the use of shared secrets. It seems that you have the
impression that the shared secrets used in the O/TWAMP protocol have to
be manually configured. This may not necessarily be true if you want to
use them in cellular networks, as you describe.

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.

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.

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.

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. If IANA cannot
give you that value they should correct the text in the draft and put
the appropriate value there. If that's the case then the correct way to
write this is as follows:

"
   The new Modes value indicating support for this
   specification is IKEv2Derived and is TBD."

In the IANA consideration section you then note that all TBDs have to be
replaced with the value allocated by IANA.

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.

Ciao
Hannes




Attachment:


signature.asc




Description:

 OpenPGP digital signature