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