Subject: [ippm] Shepherd Review of draft-ietf-ippm-stamp-05

From: Tal Mizrahi <[email-masked]>
Date: Mon, 15 Apr 2019 08:54:08 +0300

Dear Authors,

Having reviewed the document, I found that it is clear and straightforward,
and that it is almost ready to be submitted to the IESG, with a few minor
comments below.

I will highly appreciate if you can post an updated draft, and afterwards
we will proceed with the publication process.

Thanks,
Tal.

Comments:

- Section 1: I would suggest to mention that TWAMP Light is a lightweight
architecture of a TWAMP deployment that is presented in RFC 5357.
- Section 2:
- The term OSS/BSS should be defined.
- The acronym SDN should be spelled out in its first appearance.
- Section 4:
- "Unauthenticated STAMP test packets are compatible on the wire with
unauthenticated TWAMP-Test [RFC5357] packet formats."
  Please explain what "compatible" means. The format defined in STAMP is
identical to RFC 5357? Can be configured to a specific mode in which it is
identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a STAMP
node? You may want to add a reference here to section 4.4.
- Section 4.1.1.:
- Please clarify that the timestamp field is as specified in RFC 5357 and
RFC 8186.
- "The Reflect Octets capability defined in [RFC6038]." ==> "This field is
used for the Reflect Octets capability defined in [RFC6038]."
- Section 4.1.2. + 4.2.2. + 4.3:
- Please clarify that the HMAC field is as defined in RFC 5357, and covers
the same fields as defined in RFC 5357.
- Section 4.2.1.:
- "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)"
- Section 4.3:
- "If confidentiality protection for STAMP is required, encryption at the
higher level MUST be used."
  Please elaborate, preferably with an example. IPsec is at a lower layer
than STAMP, so not sure "higher level" is clear to the reader.
- Section 5:
- This section should be more detailed. You may want to say that the
general security considerations of TWAMP are discussed in RFC 5357. You may
also want to explain that the main difference between STAMP and TWAMP is
the control plane, and you may want to make note that STAMP configuration
procedures should be secured in order to mitigate attacks at the control
plane.
- References:
- I suggest to move "[BBF.TR-390]" to the informative references.
- draft-ietf-ippm-port-twamp-test ==> RFC 8545.
- Minor nit:
- "less the length" ==> "minus the length"

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Apr 2019 18:32:12 -0700

Dear Tal,
thank you for your thorough review and clear, to the point comments. I'll
be working on updating the draft to address your comments and will share
the proposed changes before uploading the new version of the draft.

Regards,
Greg

On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi <[email-masked]>
wrote:

> Dear Authors,
>
> Having reviewed the document, I found that it is clear and
> straightforward, and that it is almost ready to be submitted to the IESG,
> with a few minor comments below.
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Apr 2019 10:01:07 -0700

Hi Tal,
please find the proposed updates in-lined and tagged GIM>>. Also, attached
are the diff and the updated working version of the draft.
Much appreciate your comments.

Regards,
Greg

> architecture of a TWAMP deployment that is presented in RFC 5357.
GIM>> I've used the characterization of the TWAMP Light as provided in RFC
8545:
OLD TEXT:
   One of such is Performance Measurement from IP Edge to Customer
Equipment using TWAMP Light from
   Broadband Forum ([BBF.TR-390]).
NEW TEXT:
   One of such is Performance Measurement from IP Edge to Customer
Equipment using TWAMP Light from
   Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that,
according to [RFC8545], includes
   sub-set of TWAMP-Test functions in combination with other applications
that provide, for example, control
   and security.

> - The acronym SDN should be spelled out in its first appearance.
GIM>> I've added the explanation of what OSS/BSS does and removed the SDN
acronym as it is the only place being used in the draft:
OLD TEXT:
   Command Line Interface, OSS/BSS using SNMP or
   SDN using Netconf/YANG are but a few examples.
NEW TEXT:
   Command Line Interface, OSS/BSS (operations support
   system/business support system as a combination of two
   systems used to support a range of telecommunication
   services) using SNMP or controllers in Software-Defined
   Networking using Netconf/YANG are but a few examples.

> node? You may want to add a reference here to section 4.4.
GIM>> Thank you for the detailed questions and the recommendation. Please
consider the update below:
OLD TEXT:
   Unauthenticated STAMP test
   packets are compatible on the wire with unauthenticated TWAMP-Test
   [RFC5357] packet formats.
NEW TEXT:
   Unauthenticated STAMP test
   packets, defined in Section 4.1.1 and Section 4.2.1, ensure
   interworking between STAMP and TWAMP Light as described in
   Section 4.4.  packet formats.

> - Please clarify that the timestamp field is as specified in RFC 5357 and
GIM>> I've added references to RFC 5357 and RFC 8186 as follows:
OLD TEXT:
   o  Timestamp is eight octets long field.  STAMP node MUST support
      Network Time Protocol (NTP) version 4 64-bit timestamp format
      [RFC5905].  STAMP node MAY support IEEE 1588v2 Precision Time
      Protocol truncated 64-bit timestamp format [IEEE.1588.2008].
NEW TEXT:
    o  Timestamp is eight octets long field.  STAMP node MUST support
      Network Time Protocol (NTP) version 4 64-bit timestamp format
      [RFC5905], the format used in [RFC5357].  STAMP node MAY support
      IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp
      format [IEEE.1588.2008], the format used in [RFC8186].

> used for the Reflect Octets capability defined in [RFC6038]."
GIM>> Thank you for the helpful suggestion. Done.

> the same fields as defined in RFC 5357.
GIM>> Hashed Message Authentication Code is defined in RFC 2104. Unlike
OWAMP or TWAMP that use HMAC-SHA-1, in STAMP we use HMAC-SHA-256. And in
STAMP HMAC also protects optional extensions. I hope that the addition of
the forward reference to Section 4.3 in 4.1.2 and 4.2.2 is acceptable.

> - "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)"
GIM>> Thank you. Accepted and done.

> than STAMP, so not sure "higher level" is clear to the reader.
GIM>> STAMP can be sent over its IPsec tunnel or share the IPsec tunnel of
the flow which performance is monitored. Please consider this update:
OLD TEXT:
   If confidentiality protection for STAMP is required, encryption at
   the higher level MUST be used.
NEW TEXT:
   If confidentiality protection for STAMP is required, encryption at
   the higher level MUST be used.  For example, STAMP packets could be
   transmitted in the dedicated IPsec tunnel or share the IPsec tunnel
   with the monitored flow.

> procedures should be secured in order to mitigate attacks at the control
GIM>> Yes, agree. The Security Considerations section is a bit terse.
Here's the updated text:
 6.  Security Considerations

   In general, all the security considerations related to TWAMP-Test,
   discussed in [RFC5357]apply to STAMP.  Since STAMP uses the well-
   known UDP port number allocated for the OWAMP-Test/TWAMP-Test
   Receiver port, the security considerations and measures to mitigate
   the risk of the attack using the registered port number documented in
   Section 6 [RFC8545] equally apply to STAMP.  Because the control and
   management of a STAMP test are outside the scope of this
   specification only the more general requirement is set:

      To mitigate the possible attack vector, the control and management
      of a STAMP test session MUST use the secured transport.

   Use of HMAC-SHA-256 in the authenticated mode protects the data
   integrity of the STAMP test packets.

> - I suggest to move "[BBF.TR-390]" to the informative references.
GIM>> Agreed and done.

> - draft-ietf-ippm-port-twamp-test ==> RFC 8545.
GIM>> Done

> - "less the length" ==> "minus the length"
GIM>> Thank you. Done.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 23 Apr 2019 07:39:27 +0300

Hi Greg,

Looks good. Many thanks for addressing the comments.

There were some comments in WG LC which also need to be addressed:
https://mailarchive.ietf.org/arch/msg/ippm/nAOnkGH9vD60hF4vcFAEqxVWLnI

Please feel free to upload a new version once this update is complete.

Thanks,
Tal.

On Mon, Apr 22, 2019 at 8:01 PM Greg Mirsky <[email-masked]> wrote:

>> - Please clarify that the HMAC field is as defined in RFC 5357, and
>> covers the same fields as defined in RFC 5357.
>>