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

From: Russ Housley via Datatracker <[email-masked]>
Date: Thu, 22 Aug 2019 10:17:35 -0700

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

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.

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.

Nits:

The document uses "Z field" and "Z flag".  Please pick one and use it
throughout the document.

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 26 Aug 2019 15:10:15 -0700

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 <
[email-masked]> wrote:

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

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

> 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].
> The document uses "Z field" and "Z flag".  Please pick one and use it
GIM>> Settled on "Z flag".

>    CBC Cipher Block Chaining
GIM>> Cleared them all.