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
