search

tsvwg / draft-ietf-tsvwg-udp-options

1 stars 0 forks source link

CMH: Apply "first instance only" rule to options received in fragments as well as in the surplus area #47

Closed Mike-Heard closed 3 months ago

Mike-Heard commented 7 months ago

In Section 10 I see:

>> Each option SHOULD NOT occur more than once in a single UDP datagram, the only exceptions being NOP, EXP, and UEXP. If an option other than these occurs more than once, a receiver MUST interpret only the first instance of that option and MUST ignore all others. Section 24 provides additional advice for DOS issues that involve large numbers of options, whether valid, unknown, or repeating.

>> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more than once using the same ExID (see Sections 11.10 and 12.3).

The "first instance only" rule is not respected in the existing instructions on what to do with per-fragment instances of MDS, MRDS, REQ, RES, and TIME (see sections 11.5 through 11.8). The instructions for MDS and MRDS recommend reporting the minimum value received; the instructions for REQ and RES recommend reporting the the most recent i.e., last) value received; and the instructions for TIME recommend reporting the minimum and maximum values without specifying what value should be reflected to the remote end (if the values in question are TSVALs). And none of these instructions are explicit about what to do if one of these options is received both in a fragment and in the surplus area of the corresponding reassembled UDP packet.

The main use that I see for allowing MDS, MRDS, REQ, RES, and TIME on UDP fragments (including atomic ones) is "to provide limited support for UDP options in systems that have access to only the initial portion of the data in incoming or outgoing packets," as noted near the end of Section 11.4. For that use case, it would IMO suffice to stipulate that the first instance received is the one reported to the upper layer, thus sustaining the text quoted above, and I recommend that the per-frag text in sections 11.5 through 11.8 be modified accordingly.

jtouch commented 3 months ago

Multiple occurrences of FRAG should probably cause a drop; not sure that applies to other options, but it would for FRAG.

Mike-Heard commented 3 months ago

Multiple occurrences of FRAG should probably cause a drop; not sure that applies to other options, but it would for FRAG.

That problem is fixed in editor's version of -33. See Issue #51 for the text.

The remainder of the initial comments (about which version of a per-frag options to keep) are withdrawn. The text concerning with those matters will remain as-is, and this issue is hereby closed.