[Last-Call] Re: [ippm] draft-ietf-ippm-stamp-ext-hdr-16 ietf last call Intdir review

[Rakesh Gandhi <[e-mail]>]

Hi Shwetha,

Thank you for the Intdir review.

We have posted rev-17 that addresses your comments.

Please see replies inline with <RG>...


On Wed, Oct 14, 2026 at 12:30 AM Shwetha Bhandari via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-ippm-stamp-ext-hdr
> Title: Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
> Reflecting STAMP Packet IP Headers Reviewer: Shwetha Bhandari Review
> result:
> Ready with Issues
>
> I am the assigned int-dir reviewer for this draft. These comments were
> written
> with the intent of improving the Internet area aspects of the IETF drafts.
> Please treat these comments just like any other last call comments. For
> background on int-dir, please see the INTDIR guidelines
> (https://wiki.ietf.org/group/intdir)
>
> Document: draft-ietf-ippm-stamp-ext-hdr-16
>
> Summary
>
> The draft extends STAMP to reflect IPv4/IPv6 headers and IPv6 extension
> headers
> for active measurement. My review focuses on protocol processing
> requirements
> and interoperability, particularly header selection, packet-size
> constraints,
> and UDP checksum handling.
>
> Comments for the authors:
>
> 1. Header selection when identifying fields are not unique (Sections 4.2,
> 6.2,
> and 9.1)
>
> The draft identifies a requested header using its length and the first
> eight
> octets of an IPv6 extension header or the first four octets of an IPv4/IPv6
> fixed header. Section 9.1 notes that these octets must not change in
> transit
> when multiple same-length headers are present and only some are to be
> reflected.
>
> What happens if two headers of the same length have identical identifying
> octets, so that the requested header cannot be uniquely identified? The
> selection procedure appears to permit either matching header to satisfy the
> request, potentially causing the reflector to return data from a different
> header than intended.
>
> Please clarify whether the sender is required to ensure that the
> identifying
> fields uniquely distinguish the requested headers and what behaviour is
> required when this condition cannot be met.
>

<RG> Updated the procedures to cover this case.

*An all-zero value continues to select the first IPv6 extension header of
the matching length. If the requested header cannot be uniquely selected
under these rules, the Session-Sender MUST NOT request selective reflection
of that header.*

*..*

*If a non-zero Requested IPv6 Extension Header Data field matches more than
one IPv6 extension header of the requested length, the Session-Reflector
MUST return the TLV with the Conformant Reflected Packet STAMP TLV flag set
to 1, following the procedure specified in [RFC10052], and MUST NOT copy
data from any of the matching headers.*




>
> 2. Deterministic handling of TLVs when the packet exceeds the path MTU
> (Sections 4.2 and 6.2)
>
> The draft requires removal of TLVs from the end of the test packet when
> necessary to satisfy the path-MTU constraint. ARTART has also raised the
> question of which TLVs should be removed, while TSVART has asked how both
> endpoints know the applicable path MTU.
>
> Could the authors clarify how the sender and reflector determine the
> applicable
> path MTU and whether the TLV-removal procedure is deterministic and
> observable
> to the sender? Different MTU knowledge or removal policies could result in
> different sets of reflected headers being available for measurement.
>
> In particular, please clarify how a sender can distinguish an intentionally
> unrequested header from one omitted because of packet-size constraints, and
> whether the existing response flags provide sufficient information.
>


<RG> Created a section to cover this:

*7.2. MTU Considerations*

* Each Session-Sender and Session-Reflector MUST determine the applicable
path MTU for the direction in which it transmits STAMP-Test packets. This
information may be provisioned, collected through management protocols,
learned through a path-MTU-discovery mechanism such as Path MTU Discovery
for IPv6 [RFC8201], or distributed by a control protocol. The mechanisms
for obtaining this information are outside the scope of this document.*

* The transmitting node MUST ensure that the complete STAMP-Test packet,
including all applicable IP, UDP, STAMP, "Reflected Fixed Header Data", and
"Reflected IPv6 Extension Header Data" TLV fields, does not exceed the
applicable path MTU. If the packet exceeds this limit, the node MUST remove
complete reflected header data TLVs one at a time, starting with the last
TLV in the packet, until the packet fits within the MTU. When both types of
reflected header data TLVs are present, their ordering in Section 7.1
determines the removal order. The remaining TLVs MUST retain their relative
order. If removing all reflected header data TLVs does not bring the packet
within the path MTU, the node MUST NOT transmit it.*

* The Session-Reflector MUST return requested TLVs that it can process in
the order received. The Session-Sender can identify the MTU-driven removal
by comparing the ordered TLV sequence it sent with the sequence returned by
the Session-Reflector; an intentionally unrequested header has no
corresponding TLV in the Session-Sender packet. The Conformant Reflected
Packet STAMP TLV flag does not indicate MTU-driven removal.*




>
> 3. Integrity guarantees when IPv6 UDP zero checksum is enabled (Section
> 8.2)
>
> The draft permits IPv6 STAMP sessions to use a zero UDP checksum under
> specified constraints and requires STAMP to detect corruption of header
> information without allowing incorrect protocol state to accumulate.
>
> Please clarify which integrity checks provide this guarantee when the UDP
> checksum is zero and whether those checks cover the measurement information
> carried in the STAMP payload, including reflected header data. The draft
> recommends authenticated STAMP when payload integrity is required, but it
> would
> be useful to state precisely what corruption detection is guaranteed for
> sessions that use zero checksums without authenticated mode.
>

<RG> Added additional details as:

*When the IPv6 UDP checksum is zero, the UDP layer does not detect
corruption of the STAMP-Test payload. Implementations MUST perform the
specified STAMP packet and session validation, including checks of packet
format, session identification, sequence number field, timestamp fields (as
specified in Section 11), and TLV structure and length, and MUST discard
packets that fail those checks. These checks detect some invalid packets
but do not provide general integrity protection: corruption that leaves a
packet valid, including changes to measurement fields or TLV values, may go
undetected and affect the measurement. Thus, a session using a zero UDP
checksum without authenticated STAMP has no general assurance that its
measurement information is intact.*


Thanks,
Rakesh (for authors)




>
> This is important because undetected corruption of measurement data could
> produce misleading results even if the session continues to operate.
>
> Recommendation: These comments identify questions about interoperability
> and
> the interpretation of measurement results that merit clarification. The
> MTU and
> header-selection procedures are the primary concerns, followed by the
> checksum
> clarification. The checksum clarification should be treated as a
> substantive
> issue only if the existing STAMP requirements do not already provide the
> stated
> integrity guarantees.
>
>
> _______________________________________________
> ippm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>