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

[Greg Mirsky <[e-mail]>]

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

On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi <[e-mail]>
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.
>
> 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.
>
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.

- Section 2:
> - The term OSS/BSS should be defined.
> - 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.

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

- Section 4.1.1.:
> - Please clarify that the timestamp field is as specified in RFC 5357 and
> RFC 8186.
>
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].

- "The Reflect Octets capability defined in [RFC6038]." ==> "This field is
> used for the Reflect Octets capability defined in [RFC6038]."
>
GIM>> Thank you for the helpful suggestion. Done.

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

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

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

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

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

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