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

[Tal Mizrahi <[e-mail]>]

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 <[e-mail]> wrote:

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