The API extensions for UDP Options must allow UDP fragmentation to be on or off for any send request

[Mike-Heard]

Appearing at the end of Section 15 of -26 (and persisting in the current version, -28) I see:

APIs are not intended to provide user control over option order, especially on a per-packet basis, as this could create a security issue, although there are means to address this at receivers (see Section 24). Similarly, APIs are not intended to provide user/application control over UDP fragmentation on a per-packet basis.

That last sentence is problematic. The upper layer MUST be able to specify, for any send request, whether fragmentation is allowed or not. DPLPMTUD, when implemented as a library on top of UDP Options, won't work if UDP fragmentation cannot be suppressed on probe packets. I thought that we had a firm consensus on that point.

If the intent is that the application is not supposed to have fine-grained control over what goes into fragments, I'm all in, but the text needs to be reworded to say that.

Additionally, I think that the first sentence would be improved if it were rewritten as follows:

APIs are not intended to provide user control over option order, especially on a per-packet basis, as this could create a covert channel (see Section 24 for further discussion).

Mailing list reference: https://mailarchive.ietf.org/arch/msg/tsvwg/XCcF_rMNv0nLKSj9Hnl6NDm-wtw/

[jtouch]

Agreed; the original intent was that the API doesn't control HOW fragmentation happens. I still think that's worth including, though yes, it should be able to be enabled/disabled on a per-packet basis.

[jtouch]

Fixed in -29

[Mike-Heard]

I'm closing the issue with the following suggestion for a typo fix and a minor editorial change:

Current -29 text:

APIs are not intended to provide user control over option order, especially on a per-packet basis, as this could create a cover channel (see [Section 24]). Similarly, APIs are not intended to provide user/application control over UDP fragment boundaries on a per-packet basis, although they are expected to allow control over which options are enabled (or disabled) on a per-packet basis. Such control over when fragmentation is used is critical to DPLPMTUD.

Proposed update:

APIs are not intended to provide user control over option order, especially on a per-packet basis, as this could create a covert channel (see [Section 24]). Similarly, APIs are not intended to provide user/application control over UDP fragment boundaries on a per-packet basis, although they are expected to allow control over which options, including fragmentation, are enabled (or disabled) on a per-packet basis. Such control over when fragmentation is used is critical to DPLPMTUD.

I.e.: s/cover channel/covert channel/ s/which options are/which options, including fragmentation, are/

[jtouch]

Fixed in -31.

Joe

— Dr. Joe Touch, temporal epistemologist www.strayalpha.com

On Mar 4, 2024, at 11:41 AM, Mike-Heard @.***> wrote:

I'm closing the issue with the following suggestion for a typo fix and a minor editorial change:

Current -29 text:

APIs are not intended to provide user control over option order, especially on a per-packet basis, as this could create a cover channel (see [Section 24]). Similarly, APIs are not intended to provide user/application control over UDP fragment boundaries on a per-packet basis, although they are expected to allow control over which options are enabled (or disabled) on a per-packet basis. Such control over when fragmentation is used is critical to DPLPMTUD.

Proposed update:

APIs are not intended to provide user control over option order, especially on a per-packet basis, as this could create a covert channel (see [Section 24]). Similarly, APIs are not intended to provide user/application control over UDP fragment boundaries on a per-packet basis, although they are expected to allow control over which options, including fragmentation, are enabled (or disabled) on a per-packet basis. Such control over when fragmentation is used is critical to DPLPMTUD.

I.e.: s/cover channel/covert channel/ s/which options are/which options, including fragmentation, are/

— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/24#issuecomment-1977329123, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJVISBRIQJ57K5WDRDHCI3YWTE7PAVCNFSM6AAAAAA73H6UPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXGMZDSMJSGM. You are receiving this because you commented.

[Mike-Heard]

I screwed up. For -31 note this typo:

s/is used is critical/is critical.

I didn't see that the first time around. Sorry about that.

[jtouch]

Fixed in -32.