Re: [ippm] Secdir last call review of draft-ietf-ippm-stamp-07

[Greg Mirsky <[e-mail]>]

Hi Russ,
thank you for your review, comments, and suggestions. Please find my notes
in-lined under GIM>> tag.
Also, please find the diff and the working version of the draft attached.

Regards,
Greg

On Thu, Aug 22, 2019 at 10:17 AM Russ Housley via Datatracker <
[e-mail]> wrote:

> Reviewer: Russ Housley
> Review result: Has Issues
>
> I 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 authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
>
> Document: draft-ietf-ippm-stamp-07
> Reviewer: Russ Housley
> Review Date: 2019-08-22
> IETF LC End Date: 2019-09-03
> IESG Telechat date: unknown
>
> Summary: Has Issues
>
>
> Major Concerns:
>
> Section 4.1.1: This paragraph is a bit surprising:
>
>       The STAMP Session-Sender and Session-Reflector MAY use, not use,
>       or set value of the Z field in accordance with the timestamp
>       format in use.  This optional field is to enhance operations, but
>       local configuration or defaults could be used in its place.
>
> Why not have this bit set to align with the bits that actually appear
> in the packet?

GIM>> The use of the Z bit to indicate the format of the timestamp used by
TWAMP  test nodes has been described in RFC 8186
<https://datatracker.ietf.org/doc/rfc8186/>. The value of the Z flag is set
by the Session-Sender and the Session-Reflector independently to reflect
the format of timestamp that each of them respectively uses. The Z flag is
part of the Error Estimate field and thus is part of the STAMP test packet
transmitted by the Session-Sender and the packet reflected by the
Session-Reflector.

> This is especially worrisome because of the text that
> come later (Section 4.2.1), which says:
>
>    o  Timestamp and Receiver Timestamp fields are each eight octets
>       long.  The format of these fields, NTP or PTPv2, indicated by the
>       Z flag of the Error Estimate field as described in Section 4.1.
>
> If the Z field (or Z flag) is not really meaningful, I do not see how
> the peer knows how to interpret a received timestamp.
>
GIM>> A Session-Reflector would not interpret the value of the Z flag (will
convert to "Z flag") but only the Session-Sender will
use the value in the Error Estimate field on the reflected packet to
correctly interpret the values in the Receive Timestamp and Timestamp
fields. (The Session-Sender Timestamp is the copy of the timestamp set by
the Session-Sender and is expected to be processed correctly.)

>
>
> Section 4.3:  Please divide this into two sections.  First, you have
> picked a single mechanism for authentication (HMAC-SHA-256 truncated
> to 128 bits).  This choice seems fine to me, even though you are not
> saying much about the key management.  I would prefer that you have
> a mandatory to implement key management technique, but allow others;
> however, I am not going to insist on that.  Then, a separate section
> should talk about confidentiality protection.
>
>
> Section 4.3:  This text needs work:
>
>    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.
>
> I find "at the higher level" very unclear.  I believe that IPsec would
> be below this protocol.
>
> I think that DTLS would also provide the confidentiality protection
> that you desire.  Since you are not specifying any details of the
> encryption, you can say that a "secured transport" (the term that you
> use in the Security Considerations) such as IPsec or DTLS can be used.
>
GIM>> Thank you for the suggestions. Renamed Section 4.3 in Integrity
Protection in STAMP, and added the new section:
NEW TEXT:
4.4.  Confidentiality Protection in STAMP

   If confidentiality protection for STAMP is required, a STAMP test
   session MUST use a secured transport.  For example, STAMP packets
   could be transmitted in the dedicated IPsec tunnel or share the IPsec
   tunnel with the monitored flow.  Also, Datagram Transport Layer
   Security protocol would provide the desired confidentiality
   protection.


>
> Minor Concerns:
>
> Section 1:  I do not follow this topic, and this may be clear to your
> expected reader, but it is not clear to me.  The Introduction does not
> tell me the relationship of TWAMP Light and [BBF.TR-390] to this
> document.  One possible way to resolve this is to divide the section
> into four parts: (1) background and history of measurement protocols;
> (2) shortcoming of those protocols; (3) what this document does to
> resolve those shortcomings; and (4) pointers to other documents that
> make up the rest of the shortcoming resolution.
>
GIM>> Thank you for your suggestions. Split the section into four
paragraphs. Hopefully the text is more clear now:
 1.  Introduction

   Development and deployment of Two-Way Active Measurement Protocol
   (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined
   features such as Reflect Octets and Symmetrical Size for TWAMP
   provided invaluable experience.  Several independent implementations
   of both TWAMP and TWAMP Light exist, have been deployed, and provide
   important operational performance measurements.

   At the same time, there has been noticeable interest in using a more
   straightforward mechanism for active performance monitoring that can
   provide deterministic behavior and inherit separation of control
   (vendor-specific configuration or orchestration) and test functions.
   Recent work on IP Edge to Customer Equipment using TWAMP Light from
   Broadband Forum [BBF.TR-390] demonstrated that interoperability among
   implementations of TWAMP Light is challenged because the composition
   and operation of TWAMP Light were not sufficiently specified in
   [RFC5357].  According to [RFC8545], TWAMP Light includes sub-set of



Mirsky, et al.          Expires February 27, 2020               [Page 2]

Internet-Draft                    STAMP                      August 2019


   TWAMP-Test functions to provide comprehensive solution requires
   support by other applications that provide, for example, control and
   security.

   This document defines an active performance measurement test
   protocol, Simple Two-way Active Measurement Protocol (STAMP), that
   enables measurement of both one-way and round-trip performance
   metrics like delay, delay variation, and packet loss.  Some TWAMP
   extensions, e.g., [RFC7750] are supported by the extensions to STAMP
   base specification in [I-D.ietf-ippm-stamp-option-tlv].
>
>
>
> Nits:
>
> The document uses "Z field" and "Z flag".  Please pick one and use it
> throughout the document.
>
GIM>> Settled on "Z flag".

>
> These terms are defined in Section 2.1, but they are not used in the
> rest of the document:
>
>    AES Advanced Encryption Standard
>
>    CBC Cipher Block Chaining
>
>    ECB Electronic Cookbook
>
>    KEK Key-encryption Key
>
GIM>> Cleared them all.