# Gunter Van de Velde, RTG AD, comments for review of draft-ietf-mpls-stamp-pw-13

# Original Ballot (with DISCUSS): https://mailarchive.ietf.org/arch/msg/mpls/3Qs5vA5wjCX3iIhaMsJFJeexFVU/
# Revised Ballot: (remaining DISCUSS#1 and #2) https://mailarchive.ietf.org/arch/msg/mpls/qZ7VgaB3p8rfNAic83c3S9Z52OM/
# Revised Ballot#2: (remaining DISCUSS#2): https://mailarchive.ietf.org/arch/msg/mpls/fbkZgro0b2s2QZ61ld03Fy4lzUU/

# Updated Review:

Nice update to the draft.  The DISCUSS#1 item is sufficiently resolved to be considered closed. Thank you for the edits.

About DISCUSS#2 (zero-checksum) , may I propose some stronger procedural text as what is currently enclosed within this document? The offered text would update 6936, 8085, 8200 in addition to the prior existing updates to 8762, 8972. The proposed change introduces a very narrow update to allow zero-checksum for STAMP application. Doing this provides a clean procedure and makes this draft properly compliant to prior work. (without this section I will set a non-blocking ABSTAIN, instead of a blocking DISCUSS to respect the reality of running code. The result would be that I have no longer a blocking position).

Note that when this section is inserted, that abstract and Introduction should also announce the exception. The sentence saying Section 4.4 applies to “all STAMP sessions” should be removed. This newly proposed section would be a real normative change to IPv6 and UDP applicability, not an editorial clarification. I would therefore expect explicit INT/6MAN and transport review.

Suggested replacement text (disclaimer: an agent was to compose this text):

***
4.4.1. Constrained IPv6 UDP Zero-Checksum Mode

Section 8.1 of [RFC8200] permits IPv6 UDP zero-checksum mode for protocols that use UDP as a tunnel encapsulation. A Format-1 STAMP packet does not use UDP as a tunnel encapsulation; its UDP payload is a STAMP message. In addition, an unauthenticated STAMP message does not provide the CRC or other packet-integrity mechanism required for a non-tunnel payload by Requirement 5 of Section 5 of [RFC6936]. STAMP sequence numbers and timestamps are measurement fields and are not packet-integrity checks.

This section defines a narrow additional exception to Section 8.1 of [RFC8200], Requirement 5 of Section 5 of [RFC6936], and Section 3.4.1 of [RFC8085]. The exception applies only to Format-1 STAMP test packets used for the MPLS LSP and PW measurements specified in this document. It does not apply to general STAMP operation or to STAMP over the Internet.

Implementations supporting Format-1 STAMP over IPv6:

  *
MUST implement transmission and reception using a non-zero UDP checksum.
  *
MUST use a non-zero UDP checksum by default.
  *
SHOULD use a checksum complement as described in [RFC7820] when that mechanism is supported by the timestamping implementation.
  *
MAY support UDP zero-checksum mode when the timestamping implementation cannot update the UDP checksum or insert a checksum complement after updating the timestamp. This mode MUST be enabled by explicit operator configuration and MUST NOT be enabled automatically.

UDP zero-checksum mode is permitted only when all of the following conditions are met:

  1.
The Session-Sender, Session-Reflector, and the complete MPLS path between them are operated within a single administrative domain. UDP zero-checksum mode MUST NOT be used across the general Internet or across independently operated domains.
  2.
The STAMP test packet is associated with a pre-provisioned point-to-point LSP or PW and is received in the MPLS forwarding or OAM context provisioned for that STAMP session. A zero-checksum STAMP packet received through ordinary native IPv6 forwarding, without the expected MPLS session context, MUST be discarded.
  3.
Both endpoints are explicitly configured with the expected LSP or PW context, IPv6 source and destination addresses, UDP source and destination ports, and, when present, the STAMP Session Identifier. A receiver MUST enable zero-checksum processing only for this configured combination. Enabling zero-checksum processing for all traffic arriving on an interface or for an unrestricted UDP port range is not permitted.
  4.
The receiver MUST continue to accept and validate packets carrying a non-zero UDP checksum on a UDP port for which zero-checksum processing has been enabled, as required by Section 4 of [RFC6936].
  5.
Before processing a zero-checksum packet as STAMP, the receiver MUST verify the expected MPLS context, IPv6 source and destination addresses, UDP source and destination ports, UDP Length, IPv6 Payload Length, STAMP packet length and format, and the configured STAMP session. A packet that fails any check MUST be discarded and SHOULD be counted for operational monitoring.
  6.
IPv6 fragmentation MUST NOT be used for a STAMP packet carrying a zero UDP checksum. A fragmented zero-checksum STAMP packet MUST be discarded.
  7.
Zero-checksum STAMP packets MUST be locally consumed as OAM traffic at the configured Session-Sender or Session-Reflector. They MUST NOT be forwarded toward an attachment circuit, delivered as customer traffic, passed to another UDP application, or forwarded outside the administrative domain.
  8.
Packet filters MUST be deployed at the boundaries of the administrative domain to prevent zero-checksum STAMP packets from entering or leaving the domain. Appropriate source-address, destination-address, UDP-port, and MPLS-context filters SHOULD also be applied at the STAMP endpoints.
  9.
Receipt of a zero-checksum packet MUST NOT create or delete a STAMP session or change routing, MPLS, PW, protection, or service-forwarding state. Any resulting state update MUST be bounded to the measurement state of the already configured STAMP session.
  10.
An unauthenticated measurement obtained using UDP zero-checksum mode MUST NOT be the sole input to an automated action that changes forwarding, protection, or service state. A non-zero UDP checksum, together with any integrity protection required by the deployment, MUST be used when STAMP measurements directly control such actions.
  11.
Zero-checksum STAMP traffic MUST be rate-limited and actively monitored. The implementation SHOULD provide counters for received, accepted, and discarded zero-checksum packets. If the operator can no longer ensure that the path and endpoints satisfy the restrictions in this section, zero-checksum mode MUST be disabled.

Except for the explicit exception to Requirement 5 described above, all applicable implementation and usage requirements in Sections 4 and 5 of [RFC6936] remain in force. Requirement 3 of Section 5 of [RFC6936] is not applicable because STAMP does not encapsulate an inner IPv4 or IPv6 packet. Middleboxes within the controlled domain that process these packets MUST comply with Requirements 8 through 10 of Section 5 of [RFC6936].

This exception accepts a residual risk that corruption of an unauthenticated STAMP message can be interpreted as packet loss, reordering, or an incorrect delay measurement. The use of a controlled MPLS environment, lower-layer error detection, strict session demultiplexing, packet filtering, absence of IP fragmentation, and rate limiting reduces the probability and operational scope of such corruption but does not provide packet integrity. Because a STAMP packet carries only measurement information and no customer payload, and because measurements obtained in this mode are prohibited from directly changing forwarding state, the consequences are confined to the accuracy or availability of the affected measurement session. The operator explicitly accepts this residual risk when enabling zero-checksum mode.
***

Thoughts?

Kind Regards,
Gunter Van de Velde
Routing AD