Subject: [ippm] Publication has been requested for draft-ietf-ippm-ipsec-07

From: "Brian Trammell" <[email-masked]>
Date: Tue, 06 Jan 2015 02:24:40 -0800

Brian Trammell has requested publication of draft-ietf-ippm-ipsec-07 as Proposed Standard on behalf of the IPPM working group.

Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 16 Jan 2015 10:40:18 -0600

Hi, Brian,

On Tue, Jan 6, 2015 at 4:24 AM, Brian Trammell <[email-masked]> wrote:

> Brian Trammell has requested publication of draft-ietf-ippm-ipsec-07 as
> Proposed Standard on behalf of the IPPM working group.
>
> Please verify the document's state at
> http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

I've done the AD evaluation for this doc, and am mostly fine with it, but
had some suggestions that I wanted to share with you before Last Call.

I want to emphasize that these are either nits or close to nits, but found
that I didn't understand the draft clearly when I encountered them.

If you'd like to do a minor revision, that would be fine, or if you'd like
to tell me that smart people can understand the stuff that wasn't clear to
me, that would be fine, or if you'd like me to issue Last Call and then
post my comments, that would be fine.

Just let me know! And thanks, as always ...

Spencer

-- my notes follow --

In this text, in the Abstract:

Abstract

   The O/TWAMP security mechanism requires that both the client and
   server endpoints possess a shared secret.  Since the currently-
   standardized O/TWAMP security mechanism only supports a pre-shared
   key mode, large scale deployment of O/TWAMP is hindered
   significantly.  At the same time, recent trends point to wider IKEv2
   deployment which, in turn, calls for mechanisms and methods that
   enable tunnel end-users, as well as operators, to measure one-way and
   two-way network performance in a standardized manner.  This document
   discusses the use of keys derived from an IKEv2 SA as the shared key
   ^^^^^^^^^
   in O/TWAMP.  If the shared key can be derived from the IKEv2 SA, O/
   TWAMP can support certificate-based key exchange, which would allow
   for more operational flexibility and efficiency.  The key derivation
   presented in this document can also facilitate automatic key
   management.

"discusses the use of keys" probably isn't quite right for a Proposed
Standard. In Section 3, you say "describes". That's probably better.

While we are in Section 3, this text:

3.  Scope and Applicability

   This document specifies a method for enabling network measurements
   between a TWAMP client and a TWAMP server which both support IPsec.
   In short, the shared key used for securing TWAMP traffic is derived
   using IKEv2 [RFC7296].  This document reserves from the TWAMP-Modes
   registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit
   set in position 7) [NOTE to IANA: remove before allocation and final
   publication] and MUST be used by TWAMP implementations compatible
   with this specification.

   Although the control procedures described in this document are
   applicable to OWAMP per se, the lack of an established IANA registry
   for OWAMP Mode values technically prevents us from extending OWAMP
   Mode values.  Therefore, independent OWAMP implementations SHOULD be
   checked for full compatibility with respect to the use of this Mode
   value.  Until an IANA registry for OWAMP Mode values is established,
   the use this feature in OWAMP implementations MUST be arranged
   privately among consenting OWAMP users.

is the first place I understood clearly what the document is doing. Perhaps
the first two sentences could go in the Introduction, so you'd be
introducing what the document does in the Introduction? ;-)

In this text in 5.1.  Shared Key Derivation

   When the shared secret key is derived from the IKEv2 SA, SK_d must be
   generated first.  SK_d MUST be computed as per [RFC7296].

   The shared secret key MUST be generated as follows:

      Shared secret key = PRF( SK_d, "IPPM" )
                          ^^^

   Wherein the string "IPPM" comprises four ASCII characters and prf is
                                                                 ^^^
   a pseudorandom function.

Is it common usage to capitalize "PRF" in the algorithm, but not in the
definition? Or, and this is equally likely, there's a relationship between
"PRF" and "prf" that I don't understand?

In this text: 5.2.  Server Greeting Message Update

   To achieve a binding association between the key generated from IKEv2
   and the O/TWAMP shared secret key, Server Greeting Message should be
   updated as in Figure 2.
   ^^^^^^^

I'm sorry, but I don't understand what it means to "update" a message.
Could you help me here? If I was guessing, I'd guess "should include these
extensions, as in Figure 2", but that's a guess.

---

From: Kostas Pentikousis <[email-masked]>
Date: Mon, 26 Jan 2015 13:01:27 +0100

Many thanks Spencer. We have now updated the document as per your suggestions.

Best regards,

Kostas

Von: Spencer Dawkins at IETF [mailto:[email-masked]]
Gesendet: Freitag, 16. Januar 2015 17:40
An: Brian Trammell
Cc: [email-masked] Chairs; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: Publication has been requested for draft-ietf-ippm-ipsec-07

Hi, Brian,

On Tue, Jan 6, 2015 at 4:24 AM, Brian Trammell <[email-masked]<mailto:[email-masked]>> wrote:
Brian Trammell has requested publication of draft-ietf-ippm-ipsec-07 as Proposed Standard on behalf of the IPPM working group.

I've done the AD evaluation for this doc, and am mostly fine with it, but had some suggestions that I wanted to share with you before Last Call.

I want to emphasize that these are either nits or close to nits, but found that I didn't understand the draft clearly when I encountered them.

If you'd like to do a minor revision, that would be fine, or if you'd like to tell me that smart people can understand the stuff that wasn't clear to me, that would be fine, or if you'd like me to issue Last Call and then post my comments, that would be fine.

Spencer

-- my notes follow --

Abstract

"discusses the use of keys" probably isn't quite right for a Proposed Standard. In Section 3, you say "describes". That's probably better.

is the first place I understood clearly what the document is doing. Perhaps the first two sentences could go in the Introduction, so you'd be introducing what the document does in the Introduction? ;-)

Is it common usage to capitalize "PRF" in the algorithm, but not in the definition? Or, and this is equally likely, there's a relationship between "PRF" and "prf" that I don't understand?

I'm sorry, but I don't understand what it means to "update" a message. Could you help me here? If I was guessing, I'd guess "should include these extensions, as in Figure 2", but that's a guess.