Mike-Heard
commented
5 months ago The big question I would have, in response to the above comments, is "what existing non-standard uses of the surplus area?" No one has presented any evidence that any such uses exist. And IMO the guidance is clear, if OCS fails, the options are ignored, and the user data (if any) is delivered. Finally, the OCS is actually designed in such a way as to facilitate integration with protocol-agnostic checksum offload. See https://mailarchive.ietf.org/arch/msg/tsvwg/9_1YWp-TApI9mcCuia8U6jfCwTA/.
gorryfair
What about existing non-standard uses of the surplus area?
"The design enables traversal of errant middleboxes that incorrectly compute the UDP checksum over the entire IP payload [Fa18][Zu20], rather than only the UDP header and UDP payload (as indicated by the UDP header length)."
The procedures for computing and processing the OCS should be articulated here, maybe incorporate those from draft-fairhurst-udp-options-cco. That includes the extra pseudo header which I believe contains the UDP options length to satisfy middleboxes that use the IP length instead of UDP length in the pseudo header for computing the UDP checksum.
"Like the UDP checksum, the OCS is optional under certain circumstances and contains zero when not used. UDP checksums can be zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload already covered by another checksum, as might occur for tunnels [RFC6935]."
Typo: "when UDP payload already" should be "when UDP payload is already"
As I've mentioned before, there is no correlation between the UDP checksum and OCS, so if the UDP payload is already covered by another checksum that is no indication to the user that not using OCS is safe and we should not imply otherwise. I think the intent here is that the OCS is required if the UDP checksum is non-zero, but optional if the UDP checksum is zero (for either IPv4 or IPv6). If it is optional, then we should provide guidance to the user on the risks of setting a zero OCS.
"OCS can be disabled, e.g., to conserve energy or processing resources or when it can improve performance"
This is dependent on implementation. Given the way modern NICs and stacks work, using an optional OCS is more likely to be a negligible performance improvement or even a slight performance degradation. Note, this is also inconsistent with the precedent of TCP options which are always covered by the TCP checksum.
">> UDP user data that is validated by a correct UDP checksum MUST be delivered to the application layer, even if the OCS fails, unless the endpoints have negotiated otherwise for this UDP packet's socket pair."
Okay, but what is the application supposed to do with a bad OCS? Should it drop the packet or pretend like nothing is wrong? What if there was an APC in the data that would need to be validated before accepting the packet? Please provide clear guidance to the developer here.
(Added by GF during WGLC)