search

tsvwg / draft-ietf-tsvwg-udp-options

1 stars 0 forks source link

CMH: Clarification for FRAG Option Corner Cases #51

Closed Mike-Heard closed 2 months ago

Mike-Heard commented 7 months ago

Section 11.4 (Fragmentation) requires that if an instance of FRAG with a valid length (10 or 12, or possibly 12 or 14, if the extended length format is used) occurs when UDP Length > 8, then the entire option area is considered malformed and is discarded. I wanted to note that these instructions, combined with those in Section 10, have the following implications for some other corner cases:

IMO the behavior described above, if it is indeed a correct interpretation of the spec, is fine. I just wanted to get confirmation that this is indeed the intent of the spec (or if it isn't, to get clarification on what the intent is).

jtouch commented 3 months ago

I would suggest that FRAG with any length should never appear with UDP length >8; when that happens, it should be dropped as malformed. Frag with any length other than as defined even when UDP length >8 may have to be dropped to - it's not clear how to proceed with a packet with FRAG if you can't process the FRAG. Multiple occurrences of FRAG should probably cause a drop; not sure that applies to other options, but it would for FRAG -- see #47 .

Mike-Heard commented 3 months ago

I would suggest that FRAG with any length should never appear with UDP length >8; when that happens, it should be dropped as malformed. Frag with any length other than as defined even when UDP length >8 may have to be dropped to - it's not clear how to proceed with a packet with FRAG if you can't process the FRAG. Multiple occurrences of FRAG should probably cause a drop; not sure that applies to other options, but it would for FRAG -- see #47 .

Edits to -33 to the above effect will be forthcoming.

Mike-Heard commented 3 months ago

Edits to -33 to the above effect will be forthcoming.

The proposed changes now in the editor's copy of -33 are near the end of Section 10, on p. 15. They are shown below with added text in bold.

OLD:

>> Receivers supporting UDP options MUST silently ignore unknown SAFE options (i.e., in the same way a legacy receiver would ignore all UDP options). That includes options whose length does not indicate the specified value(s), as long as the length is not inherently invalid (i.e., smaller than 2 for the default and 4 for the extended formats).

NEW:

>> Receivers supporting UDP options MUST silently ignore unknown SAFE options (i.e., in the same way a legacy receiver would ignore all UDP options). That includes options whose length does not indicate the specified value(s), as long as the length is not inherently invalid (i.e., smaller than 2 for the default and 4 for the extended formats). Note: a FRAG option with an unknown length field SHALL be treated as an unsupported UNSAFE option.

and

OLD:

>> 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.

NEW:

>> Each option (other than FRAG) 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; if FRAG occurs more than once, the options area MUST be considered malformed and SHALL NOT be processed. Section 24 provides additional advice for DOS issues that involve large numbers of options, whether valid, unknown, or repeating.

Kindly let me know whether the proposed text is satisfactory or needs more work.