Closed Mike-Heard closed 3 months ago
gorryfair
commented
7 months ago I think this is helpful insight for me, and I would support a slight refocus to describe UNSAFE as based on the content OR /AND the processing of the surplus area, since such a datagram is processed correctly ONLY when the UDP Option is processed.
jtouch
commented
6 months ago I disagree; it is a fundamental design rule that options are optional for legacy receivers except where that's not possible - the only place where it's not possible is where user data has been altered by the options.
So far, the only rationale to relax that definition and use UNSAFE to "force" option processing seems based on AUTH and ACS; in both cases, AUTH or ACS could fail even when the data is valid, as when UDP content were changed en-route (similar to how some NATs translated content to account for in-band addresses). The key is that there is NO reason, IMO, that use of AUTH or ACS should not be backward compatible with legacy receivers - which is what happens if they're considered UNSAFE.
All option processing is always receiver opt-in; keeping these as SAFE allows that to be consistent across all options.
Mike-Heard
commented
6 months ago There was another use case for UNSAFE with options that do not modify data but which must be known for the receiver to properly process that data that was in the reverenced mailing list message:
Consider, for instance, the proposal in draft-daiya-tsvwg-udp-options-protocol-number to define a UDP option that identifies an upper layer protocol implemented on top of UDP. It would be used when the UDP port number does not suffice for that purpose.. If that option is transmitted in the surplus area to a legacy UDP receiver, it will be ignored, with the possible result of dispatching the received packets to the wrong upper layer protocol. This is every bit as unsafe as dispatching UDP fragments or encrypted UDP packets to a legacy endpoint that does not understand them.
If that does not prove the need for the proposed change the skeptics, I believe that we are at an impasse on this issue, and I suggest that the chairs need to make a WG consensus call to settle the matter.
jtouch
commented
6 months ago On Dec 25, 2023, at 11:07 AM, Mike-Heard @.***> wrote:
There was another use case for UNSAFE with options that do not modify data but which must be known for the receiver to properly process that data that was in the reverenced mailing list message:
Consider, for instance, the proposal in draft-daiya-tsvwg-udp-options-protocol-number to define a UDP option that identifies an upper layer protocol implemented on top of UDP.
That draft has already been replaced by draft-daiya-tsvwg-udp-options-next-header.
As described therein, this would be relevant only for port numbers that are defined for multiple encapsulations; those protocols would operate sufficiently using UDP options anyway, as no such protocols that a rely on the next-header are currently defined. So there’s never a case where a user has to worry that transmitting this to such user could be misinterpreted.
It would be used when the UDP port number does not suffice for that purpose.
Except that they already do - that’s how we know the difference between HTTP and HTTPS (different port number) or HTTP/TCP vs HTTP/QUIC (different transport). Or in some cases protocols have created their own per-packet context.
Joe
jtouch
commented
6 months ago On Dec 25, 2023, at 11:07 AM, Mike-Heard @.***> wrote:
There was another use case for UNSAFE with options that do not modify data but which must be known for the receiver to properly process that data that was in the reverenced mailing list message:
Consider, for instance, the proposal in draft-daiya-tsvwg-udp-options-protocol-number to define a UDP option that identifies an upper layer protocol implemented on top of UDP.
That draft has already been replaced by draft-daiya-tsvwg-udp-options-next-header.
As described therein, this would be relevant only for port numbers that are defined for multiple encapsulations; those protocols would operate only using UDP options anyway, as none are currently defined. So there’s never a case where a user has to worry that transmitting this to such user could be misinterpreted.
It would be used when the UDP port number does not suffice for that purpose.
Except that they already do - that’s how we know the difference between HTTP and HTTPS (different port number) or HTTP/TCP vs HTTP/QUIC (different transport). Or in some cases protocols have created their own per-packet context.
Joe
tompandadev
commented
6 months ago Riterating my points on the list why options such as ACS and Auth should be UNSAFE even though then don't explictily modify data.
Applying the dictionary definitions of "unsafe" and "safe", a SAFE options wold be one that can be ignored without harmful effects and an UNSAFE option is one that cannot be ignored lest ignoring the option has the potential to bring harm. Harmful effects are not limited to just options that explicitly modify data.
If an ACS is present in a packet is ignored by receiver then that is potentially harmful. The harm in this case is silently accepting corrupted data that woud have otherwise been detected had the receiver checked the CRC. Silent data corruption is harmful and cost the user time and money. Ignoring the Auth option carries a similar risk.
Ignoring CRC and Auth the at a receiver is also hearmful to the sender. The computations for CRC or secure hash require significant comoute resources, when a receiver ignores these then the sender is wasting these resources with no benefit other than providing a false sense of safety.
An established convention of IETF protcols is that intergrity checks and authentication may be optional for senders, but are not optional for receivers to check (this is established to avoid the harmful effects mentioned above and the fact that the sender is in the best position to evaluate whether optional checksums or CRCs are needed in packet);. If a checksum, CRC, or authentication is present in a packet is expected that a receiver validates it before accepting a packet. This is true for nearly all IETF protocols that define such constructs; UDP options draft is inconsistent with other IETF protocols in this regard. In particular, it's true for the UDP checksum. From RFC1122: "If a UDP datagram is received with a checksum that is non-zero and invalid, UDP MUST silently discard the datagram.", In the UDP options draft it's mentioned that the ACS is an strongly alternative to the UDP checksum, if a receiver may arbitraily ignore it then it is not a valid alterntive to UDP checksum and is not stronger than a UDP checksum.
This has other effects, for instance RFC6936 might allow a the UDPv6 to be zero if the inner packet is covered by it's own integrity check. The ACS would be insufficient to meet this requirement since it can be ignored. So if a sender sets ACS in a UDPv6 tunneled packet they still need to set the UDP checksum. If the ACS is an UNSAFE option then it would be sufficient for meeting this requirement from RFC6936.
jtouch
commented
6 months ago The only possibly new point here is the definition of UNSAFE. The doc already makes it clear that this is relative to a legacy receiver, thus it is correct as defined by dictionaries.
I've already addressed other points, including the reason why that context (relative to legacy) is the appropriate driving factor.
tompandadev
commented
6 months ago On Thu, Dec 28, 2023, 9:12 AM Joe Touch @.***> wrote:
The only possibly new point here is the definition of UNSAFE. The doc already makes it clear that this is relative to a legacy receiver, thus it is correct as defined by dictionaries.
Joe,
I do not see WG consensus on your definition. Neither do I believe you have addressed or even acknowledged the problems and harm of undetected data corruption that your definition can lead to.
In any case, I agree with Mike. We are at an impasse.
Tom
I've already addressed other points, including the reason why that context
(relative to legacy) is the appropriate driving factor.
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1871309849, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKZCZP37AVH57NW2N4DYLWK6JAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGMYDSOBUHE . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
6 months ago The issue was raised when the original design principles were presented. AT a minimum, it is directly addressed in the draft in principle 6:
That principle was presented before the draft became a WG doc, notably in IETF 94 in 2015:
(UDP options) MUST be silently ignorable by legacy receivers
This thread also has several places where I have already addressed this.
In summary:
Joe
tompandadev
commented
6 months ago On Thu, Dec 28, 2023, 10:28 AM Joe Touch @.***> wrote:
The issue was raised when the original design principles were presented. AT a minimum, it is directly addressed in the draft in principle 6:
- The UDP option mechanism and UDP options themselves should default to the same behavior experienced by a legacy receiver.
Joe,
Sorry, I don't see how that at all addresses the issues of potential silent data corruption that have been raised, nor the inconsistencies with other IETF protocols including UDP itself.
Tom
That principle was presented before the draft became a WG doc, notably in IETF 94 in 2015:
(UDP options) MUST be silently ignorable by legacy receivers
This thread also has several places where I have already addressed this.
In summary:
- UNSAFE was never intended to force receivers to process an option whose content could be used by legacy endpoints
- Forcing more options on receivers only serves to break legacy endpoints unnecessarily (while they can detect on-path errors for option-aware endpoints, they ALWAYS break ALL legacy endpoints)
- those checksums CAN detect path errors, but they also can be falsely triggered by on-path rewriting
Joe
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1871364665, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK6NHOZQBI2NJJEP473YLWT4TAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGM3DINRWGU . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
6 months ago The default has always been to act like a legacy receiver until explicitly overridden by the receiving user unless that is not possible. The flaw is to assume that the ACS or AUTH fail only because of signsl errors (for both) or malicious intent (for the latter). I’ve already noted ways both could fail without those events. Receivers always have the choice to drop packets that fail - but the default always has been to act like a legacy receiver where possible. Defaulting to force these on updated receivers means they won’t be available to legacy receivers at all. That was the opposite of the original design goal. I’m not repeating this again. New arguments are welcome. JoeOn Dec 28, 2023, at 1:37 PM, tompandadev @.> wrote: On Thu, Dec 28, 2023, 10:28 AM Joe Touch @.> wrote:
The issue was raised when the original design principles were presented.
AT a minimum, it is directly addressed in the draft in principle 6:
The UDP option mechanism and UDP options themselves should
default to the same behavior experienced by a legacy receiver.
Joe,
Sorry, I don't see how that at all addresses the issues of potential silent
data corruption that have been raised, nor the inconsistencies with other
IETF protocols including UDP itself.
Tom
That principle was presented before the draft became a WG doc, notably in
IETF 94 in 2015:
(UDP options) MUST be silently ignorable by legacy receivers
This thread also has several places where I have already addressed this.
In summary:
UNSAFE was never intended to force receivers to process an option
whose content could be used by legacy endpoints
Forcing more options on receivers only serves to break legacy
endpoints unnecessarily (while they can detect on-path errors for
option-aware endpoints, they ALWAYS break ALL legacy endpoints)
those checksums CAN detect path errors, but they also can be falsely
triggered by on-path rewriting
Joe
—
Reply to this email directly, view it on GitHub
https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1871364665,
or unsubscribe
.
You are receiving this because you commented.Message ID:
@.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
tompandadev
commented
6 months ago On Thu, Dec 28, 2023, 5:05 PM Joe Touch @.***> wrote:
The default has always been to act like a legacy receiver until explicitly overridden by the receiving user unless that is not possible. The flaw is to assume that the ACS or AUTH fail only because of signsl errors (for both) or malicious intent (for the latter). I’ve already noted ways both could fail without those events. Receivers always have the choice to drop packets that fail - but the default always has been to act like a legacy receiver where possible. Defaulting to force these on updated receivers means they won’t be available to legacy receivers at all. That was the opposite of the original design goal. I’m not repeating this again.
Joe,
As I said, I don't believe there is WG consensus on this.
@chairs, please make a determination on this issue.
Tom
New arguments are welcome. JoeOn Dec 28, 2023, at 1:37 PM, tompandadev
@.> wrote: On Thu, Dec 28, 2023, 10:28 AM Joe Touch @.> wrote:
The issue was raised when the original design principles were presented.
AT a minimum, it is directly addressed in the draft in principle 6:
- The UDP option mechanism and UDP options themselves should
default to the same behavior experienced by a legacy receiver.
Joe,
Sorry, I don't see how that at all addresses the issues of potential silent
data corruption that have been raised, nor the inconsistencies with other
IETF protocols including UDP itself.
Tom
That principle was presented before the draft became a WG doc, notably in
IETF 94 in 2015:
(UDP options) MUST be silently ignorable by legacy receivers
This thread also has several places where I have already addressed this.
In summary:
- UNSAFE was never intended to force receivers to process an option
whose content could be used by legacy endpoints
- Forcing more options on receivers only serves to break legacy
endpoints unnecessarily (while they can detect on-path errors for
option-aware endpoints, they ALWAYS break ALL legacy endpoints)
- those checksums CAN detect path errors, but they also can be falsely
triggered by on-path rewriting
Joe
—
Reply to this email directly, view it on GitHub
< https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1871364665>,
or unsubscribe
.
You are receiving this because you commented.Message ID:
@.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1871634574, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKZJ6GRVJ3IMYD3A6CDYLYCMPAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGYZTINJXGQ . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago Updated based on discusson on Feb 19 with Gorry Fairhurst and Mike Heard: ACS and AUTH remain SAFE because they do not modify UDP user data and could be safely used with legacy endpoints. The default is to report errors but otherwise ignore because legacy apps and endpoints cannot do otherwise. The default can be overridden, though (it is a default). Addressed in -29.
Mike-Heard
commented
3 months ago I think that the substantive issues are addressed and that the definition in -31 Section 12 is fine:
UNSAFE options are not safe to ignore [...]
However, I still see in -31 Section 10:
Options indicated by Kind values in the range 192..255 are known as UNSAFE options because they do alter the UDP data payload and thus would interfere with legacy endpoints.
I would still like to see the following change to the text in Section 10:
s/do alter the user data/modify the UDP data payload (or the semantics thereof)/
tompandadev
commented
3 months ago On Mon, Mar 4, 2024 at 6:42 PM Mike-Heard @.***> wrote:
I think that the substantive issues are addressed and that the definition in -31 Section 12 is fine:
UNSAFE options are not safe to ignore [...]
I don't see how the latest draft addresses the 5 concerns that I posted on Dec. 28 in the bug report.
However, I still see in -31 Section 10:
Options indicated by Kind values in the range 192..255 are known as UNSAFE options because they do alter the UDP data payload and thus would interfere with legacy endpoints.
I would still like to see the following change to the text in Section 10:
s/do alter the user data/modify the UDP data payload (or the semantics thereof)/
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1977846420, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKZZ5MPWSV4GTWTVPSDYWUWJHAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHA2DMNBSGA . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago Hi, Mike,
On Mar 4, 2024, at 6:42 PM, Mike-Heard @.***> wrote:
I think that the substantive issues are addressed and that the definition in -31 Section 12 is fine:
UNSAFE options are not safe to ignore [...]
However, I still see in -31 Section 10:
Options indicated by Kind values in the range 192..255 are known as UNSAFE options because they do alter the UDP data payload and thus would interfere with legacy endpoints.
I would still like to see the following change to the text in Section 10:
s/do alter the user data/modify the UDP data payload (or the semantics thereof)/
Can you give an example of what how semantics would vary?
Joe
jtouch
commented
3 months ago Tom,
Your 5 concerns raised on 12/28 were considered but did not raise new issues.
We did add the explanation of legacy applications that rely on NAT-like rewriting as a case where the current default creates the intended effect. Protecting default UDP behavior has always been the primary and most significant consideration.
tompandadev
commented
3 months ago Joe,
Consider the following scenario.
A user is deploying a critical UDP application in their data center. They read about UDP options and see that "The Alternate Payload Checksum (APC, Kind=2) option provides a stronger alternative to the checksum in the UDP header". They are very concerned about data corruption, so they decide to use UDP Options with APC and not even use UDP checksum since the APC is stronger. They upgrade all their servers and clients to the latest OS that support UDP Options so that there are no legacy receivers in their network. They enable APC to be sent by clients, however they omit to enable APC at receivers. They might omit this because unless they read the fine print, it wouldn't be obvious to them that CRC has to be explicitly enabled at a receiver since every other protocol they've dealt with (Ethernet, TCP, RDMA, iSCSI) doesn't require enabling CRC or checksum at the receiver.
The user starts testing their application. If they snoop the packets they see that APC is properly being set by senders. They're not seeing any errors reported by receivers so it seems like everything is working well, they proceed to deploy their application with UDP Options into production. For a couple of months, things seem to work fine, but then one of their routers develops an memory error that occasionally flips the 800th bit in packets. They might be using a cheap router that doesn't have ECC so the error isn't detected at the router, and when the packet is forwarded the Ethernet CRC is computed over the corrupted data so that the Ethernet CRC on the wire is correct. Since receivers aren't enabled to verify the APC, received packets are accepted and sent to the application with no indication that the data is corrupted.
Eventually, the user will find out about the data corruption. Maybe the user is a bank and customers start reporting errors in their account balances and transactions. Subsequently, they'll identify the root cause which is that APC is not working. At this point, their application may have accepted hundreds of Gigabytes of corrupted data and the user will also realize that all the compute cycles and power used by senders to compute the CRC in APC had absolutely no effect.The user's losses to address this problem could run into the millions of dollars.
When the user comes back and asks about this, what are you going to tell them?
Tom
On Mon, Mar 4, 2024 at 9:43 PM Joe Touch @.***> wrote:
Tom,
Your 5 concerns raised on 12/28 were considered but did not raise new issues.
We did add the explanation of legacy applications that rely on NAT-like rewriting as a case where the current default creates the intended effect. Protecting default UDP behavior has always been the primary and most significant consideration.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago On Mar 5, 2024, at 7:39 AM, tompandadev @.***> wrote: Joe,
Consider the following scenario.
A user is deploying a critical UDP application in their data center.
They read about UDP options and see that "The Alternate Payload
Checksum (APC, Kind=2) option provides a stronger alternative to the
checksum in the UDP header". They are very concerned about data
corruption, so they decide to use UDP Options with APC and not even
use UDP checksum since the APC is stronger. They upgrade all their
servers and clients to the latest OS that support UDP Options so that
there are no legacy receivers in their network. They enable APC to be
sent by clients, however they omit to enable APC at receivers. They
might omit this because unless they read the fine print, it wouldn't
be obvious to them that CRC has to be explicitly enabled at a receiver
since every other protocol they've dealt with (Ethernet, TCP, RDMA,
iSCSI) doesn't require enabling CRC or checksum at the receiver.
The user starts testing their application. If they snoop the packets
they see that APC is properly being set by senders. They're not seeing
any errors reported by receivers so it seems like everything is
working well, they proceed to deploy their application with UDP
Options into production. For a couple of months, things seem to work
fine, but then one of their routers develops an memory error that
occasionally flips the 800th bit in packets. They might be using a
cheap router that doesn't have ECC so the error isn't detected at the
router, and when the packet is forwarded the Ethernet CRC is computed
over the corrupted data so that the Ethernet CRC on the wire is
correct. Since receivers aren't enabled to verify the APC, received
packets are accepted and sent to the application with no indication
that the data is corrupted.
Eventually, the user will find out about the data corruption. Maybe
the user is a bank and customers start reporting errors in their
account balances and transactions. Subsequently, they'll identify the
root cause which is that APC is not working. At this point, their
application may have accepted hundreds of Gigabytes of corrupted data
and the user will also realize that all the compute cycles and power
used by senders to compute the CRC in APC had absolutely no effect.The
user's losses to address this problem could run into the millions of
dollars.
When the user comes back and asks about this, what are you going to tell them? There’s not much to tell someone who selectively applies a spec. The spec is definitely optimized for users who didn’t read a spec they didn’t intend to support - or aren’t even around to read it. One of the two will lose based on the default, and the default for this - a ubiquitously deployed transport - is on the side of legacy apps and users, as it should be.If they need advice, read the spec. Turn on APC required at the receivers to override the stated default. That could even be set when APC is sent on a given socket. This should be obvious anyway - we tell them about this repeatedly in the doc.Joe
Tom
On Mon, Mar 4, 2024 at 9:43 PM Joe Touch @.***> wrote:
Tom,
Your 5 concerns raised on 12/28 were considered but did not raise new issues.
We did add the explanation of legacy applications that rely on NAT-like rewriting as a case where the current default creates the intended effect. Protecting default UDP behavior has always been the primary and most significant consideration.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
tompandadev
commented
3 months ago On Tue, Mar 5, 2024 at 8:12 AM Joe Touch @.***> wrote:
On Mar 5, 2024, at 7:39 AM, tompandadev @.***> wrote: Joe,
Consider the following scenario.
A user is deploying a critical UDP application in their data center.
They read about UDP options and see that "The Alternate Payload
Checksum (APC, Kind=2) option provides a stronger alternative to the
checksum in the UDP header". They are very concerned about data
corruption, so they decide to use UDP Options with APC and not even
use UDP checksum since the APC is stronger. They upgrade all their
servers and clients to the latest OS that support UDP Options so that
there are no legacy receivers in their network. They enable APC to be
sent by clients, however they omit to enable APC at receivers. They
might omit this because unless they read the fine print, it wouldn't
be obvious to them that CRC has to be explicitly enabled at a receiver
since every other protocol they've dealt with (Ethernet, TCP, RDMA,
iSCSI) doesn't require enabling CRC or checksum at the receiver.
The user starts testing their application. If they snoop the packets
they see that APC is properly being set by senders. They're not seeing
any errors reported by receivers so it seems like everything is
working well, they proceed to deploy their application with UDP
Options into production. For a couple of months, things seem to work
fine, but then one of their routers develops an memory error that
occasionally flips the 800th bit in packets. They might be using a
cheap router that doesn't have ECC so the error isn't detected at the
router, and when the packet is forwarded the Ethernet CRC is computed
over the corrupted data so that the Ethernet CRC on the wire is
correct. Since receivers aren't enabled to verify the APC, received
packets are accepted and sent to the application with no indication
that the data is corrupted.
Eventually, the user will find out about the data corruption. Maybe
the user is a bank and customers start reporting errors in their
account balances and transactions. Subsequently, they'll identify the
root cause which is that APC is not working. At this point, their
application may have accepted hundreds of Gigabytes of corrupted data
and the user will also realize that all the compute cycles and power
used by senders to compute the CRC in APC had absolutely no effect.The
user's losses to address this problem could run into the millions of
dollars.
When the user comes back and asks about this, what are you going to tell them? There’s not much to tell someone who selectively applies a spec. The spec is definitely optimized for users who didn’t read a spec they didn’t intend to support - or aren’t even around to read it. One of the two will lose based on the default, and the default for this - a ubiquitously deployed transport - is on the side of legacy apps and users, as it should be.If they need advice, read the spec. Turn on APC required at the receivers to override the stated default. That could even be set when APC is sent on a given socket. This should be obvious anyway - we tell them about this repeatedly in the doc.Joe
Joe,
End users don't read RFCs, they read user guides and man pages. Maybe the user guide would be clear, or maybe the implementation would output a warning if an APC is received but ignored, or maybe implementation would outright ignore the spec and enable receive APC by default, then the user might avoid this problem then they might be okay (I would push for doing that latter in Linux implementation).
Regardless, I believe this scenario happening is a very real possibility and at Internet scale eventually someone will get bitten by this. IMO, telling just them that they should have read the spec to understand how this protocol deviates from the way every other IETF protocol is not sufficient.
Tom
Tom
On Mon, Mar 4, 2024 at 9:43 PM Joe Touch @.***> wrote:
Tom,
Your 5 concerns raised on 12/28 were considered but did not raise new issues.
We did add the explanation of legacy applications that rely on NAT-like rewriting as a case where the current default creates the intended effect. Protecting default UDP behavior has always been the primary and most significant consideration.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1979130902, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKYIU7CBGPNZVF2WFTTYWXVFLAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGEZTAOJQGI . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago Tom,
I agree that documentation needs to highlight these issues. As I noted, such documentation (RFC or otherwise) would be something we should expect option users to read, but cannot expect legacy designers to have read.
We tell people to read the spec every day and twice on Tuesday, so to speak. Implementers get it wrong all the time, and some do so deliberately/defiantly. There's no utility in optimizing "laws for the lawless", though.
This default is designed to protect legacy users. That comes at an expense to new users, but that's the trade that is knowingy being made here.
Joe
tompandadev
commented
3 months ago On Tue, Mar 5, 2024 at 10:09 AM Joe Touch @.***> wrote:
Tom,
I agree that documentation needs to highlight these issues. As I noted, such documentation (RFC or otherwise) would be something we should expect option users to read, but cannot expect legacy designers to have read.
Joe,
Because all users of TCP options have read RFC793?
We tell people to read the spec every day and twice on Tuesday, so to speak. Implementers get it wrong all the time, and some do so deliberately/defiantly. There's no utility in optimizing "laws for the lawless", though.
And sometimes protocol designers get it all wrong. Many times when we diverge from the spec in implementation it's because the spec is not pragmatic or the protocol designers don't have experience dealing with realities of deployment. The number one goal of an implementation is to protect and service the needs of the user and not to blindly adhere to the standard, especially one for which there is no deployment experience. As I said, if UDP options are pushed into Linux I'm pretty sure that receive APC processing will be enabled by default, and if the APC fails then we will drop the packet on the spot. This divergence from the spec is justified because the cost to the user for silent data corruption is very high (which we've seen many times over).
This default is designed to protect legacy users. That comes at an expense
to new users, but that's the trade that is knowingy being made here.
You're basically saying that it's okay to risk silent data corruption even in deployments where there are no legacy users. I don't believe that is a reasonable tradeoff, nor is it necessary since APC could be defined as an UNSAFE option which avoids all the problems.
Tom
Joe
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1979350944, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK2SHYAALYYREEJBPR3YWYC5FAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGM2TAOJUGQ . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago Tom,
No, not all users of TCP read RFC793, but they really ought to read the man pages about TCP socket opts and maybe a book before the start fiddling around with options. We can't fix ignorance except with education. Protocols are not child-safe.
Yes, I'm saying that we cannot have silent, default, desired behavior for both legacy and new users - they want different things. And legacy users prevail for legacy protocols.
Every option is unsafe by your definition - any time a sender insists that the receiver accept it. That's not how protocols work - that's not how TCP works. Senders don't force receivers to accept options - they offer, and the receiver decides. We're doing on a packet level what TCP does at the connection establishment level - let the receiver decide.
But we're rehashing old arguments; it's clear we disagree. But a few others discussed this and this is what rough consensus looks like. It's not unanimous.
Joe
tompandadev
commented
3 months ago On Tue, Mar 5, 2024 at 1:14 PM Joe Touch @.***> wrote:
Tom,
No, not all users of TCP read RFC793, but they really ought to read the man pages about TCP socket opts and maybe a book before the start fiddling around with options. We can't fix ignorance except with education. Protocols are not child-safe.
Yes, I'm saying that we cannot have silent, default, desired behavior for both legacy and new users - they want different things. And legacy users prevail for legacy protocols.
Every option is unsafe by your definition - any time a sender insists that the receiver accept it. That's not how protocols work - that's not how TCP works. Senders don't force receivers to accept options - they offer, and the receiver decides. We're doing on a packet level what TCP does at the connection establishment level - let the receiver decide.
But we're rehashing old arguments; it's clear we disagree. But a few others discussed this and this is what rough consensus looks like. It's not unanimous.
Joe,
No, this is not what rough consensus looks like. It is not up to the author of a draft to declare consensus, that is the prerogative of the WG chairs to declare consensus. See RFC7278.
As we have not heard from the chairs on this matter, I once again request that the chairs make a consensus call on this issue. Presumably this topic could be brought up in person at the IETF119 and a humming consensus could be done.
Tom
Joe
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1979645951, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK74LIQXFOQSEGX6C3LYWYYS7AVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGY2DKOJVGE . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago I did not declare rough consensus; I note this is an example of what it looks like.
I didn't decide how to move forward; see my initial note indicating how this update came about:
Updated based on discusson on Feb 19 with Gorry Fairhurst and Mike Heard.
Gorry is one of the chairs.
Consensus call can be done on the list, where we all can participate, not just those who attend in person.
Mike-Heard
commented
3 months ago With some reluctance, I am reopening this issue owing to the lengthy discussion that has taken place after closed it. That being said, most of the recent comments actually are not really addressed to this issue at all, but rather to Issue Issue #21.
I'll respond to this comment, which is directly relevant to this issue, in due course.
Thank you.
tompandadev
commented
3 months ago On Tue, Mar 5, 2024 at 2:34 PM Joe Touch @.***> wrote:
I did not declare rough consensus; I note this is an example of what it looks like.
I didn't decide how to move forward; see my initial note indicating how this update came about:
Updated based on discusson on Feb 19 with Gorry Fairhurst and Mike Heard.
I can't find this discussion in the tsvwg archives nor in this bug report. Where did it happen?
Thanks, Tom
Gorry is one of the chairs.
Consensus call can be done on the list, where we all can participate, not just those who attend in person.
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1979752265, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK3ZJ72MNOFXUKV3JDTYWZCANAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZG42TEMRWGU . You are receiving this because you commented.Message ID: @.***>
Mike-Heard
commented
3 months ago [ ... ] Updated based on discusson on Feb 19 with Gorry Fairhurst and Mike Heard.
I can't find this discussion in the tsvwg archives nor in this bug report. Where did it happen?
Skype call between the co-chair and the document editor, which I was invited to join.
Mike Heard
moeller0
commented
3 months ago Does a private skype call allow the desired public scrutiny of the sausage making inherent in an IETF RFC?
moeller0
commented
3 months ago I think that moving the discussion off list to github issues does mainly reduce the number of folks contributing which IMHO might speed up the process, but does it improve the quality of the final product? And does it foster the generation and assessment of (qualified) consensus?
jtouch
commented
3 months ago RFC sausage making happens off-list and off-meeting all the time, unless you're prepared to record and post every hallway chat and lunch discussion at the IETF itself, not to mention other subsets, such as with document shepherds, chairs, and authors that happen all the time.
Github is linked on the TSVWG main pages and open to the public. A weekly digest is posted to the list as well, as just occurred this morning.
I believe github has improved the process, notably when there are many open issues for a document. It encourages separate threads of discussion that are much easier for everyone to track and participate in. Any one of us can open and close a github issue, but the actual changes are visible in the posted draft versions, even if github isn't being tracked.
Consensus remains determined by the WG chair, as usual.
Mike-Heard
commented
3 months ago Does a private skype call allow the desired public scrutiny of the sausage making inherent in an IETF RFC?
It is no different than the occasional use of off-list emails or -- as mentioned above -- hallway discussions. Sometimes such discussions can bring technical issues that are blocking consensus into sharper relief than mailing list exchanges, where subtleties have a way of getting buried. The focus of the skype call was to close as many open github issues as possible. Please look at the diff from -28 to -31 and the github archive to judge the success of that effort and to frame your comments if you don't agree with the outcome.
I think that moving the discussion off list to github issues does mainly reduce the number of folks contributing which IMHO might speed up the process, but does it improve the quality of the final product? And does it foster the generation and assessment of (qualified) consensus?
It's probably true that fewer folks see the discussion when it takes place on github, and it takes extra effort to track it. On the other had, keeping the threads is focused is very useful. Unfortunately, we are violating that objective now by discussing something other that the subject of this issue, which is "The definition of UNSAFE options should not be limited to options that modify user data." I shall return to that issue momentarily, and I implore folks to stay on topic going forward. Issues specific to APC and AUTH should be discussed under Issue #21. Thank you.
gorryfair
commented
3 months ago We're heading to a WGLC - people implementing the spec or designing protocols that will use this spec will have a chance to comment on the definition of UNSAFE, during that stage. I'd recommend closing this issue, since we do now have updated text: "UNSAFE options are not safe to ignore and can be used unidirectionally or without soft-state confirmation of UDP option capability."
tompandadev
commented
3 months ago On Sun, Mar 10, 2024 at 10:50 AM Gorry Fairhurst @.***> wrote:
We're heading to a WGLC - people implementing the spec or designing protocols that will use this spec will have a chance to comment on the definition of UNSAFE, during that stage. I'd recommend closing this issue, since we do now have updated text: "UNSAFE options are not safe to ignore and can be used unidirectionally or without soft-state confirmation of UDP option capability."
Gorry, in Section 11 the draft also states:
"SAFE UDP options can be silently ignored by legacy receivers without affecting the meaning of the UDP user data. They stand in contrast to UNSAFE options, which modify UDP user data in ways that render it unusable by legacy receivers (Section 12)."
This clearly implies that UNSAFE options are limited to those that modify user data.
Tom
—
Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1987308769, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKYGNSW2AJUTFC722NTYXSMNPAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGMYDQNZWHE . You are receiving this because you commented.Message ID: @.***>
Mike-Heard
commented
3 months ago Mike Heard wrote:
I think that the substantive issues are addressed and that the definition in -31 Section 12 is fine:
UNSAFE options are not safe to ignore [...]
However, I still see in -31 Section 10:
Options indicated by Kind values in the range 192..255 are known as UNSAFE options because they do alter the UDP data payload and thus would interfere with legacy endpoints.
I would still like to see the following change to the text in Section 10:
s/do alter the user data/modify the UDP data payload (or the semantics thereof)/
Joe Touch replied:
Can you give an example of what how semantics would vary?
Sure, draft-daiya-tsvwg-udp-options-next-header is a live example, as I mentioned previously in this thread. The intent of the draft is to use a UDP option to discriminate between transport protocols on an arbitrary port. Here is one of the possible use cases that it mentions:
For instance, when a new transport protocol other than QUIC is developed and used that is based on UDP and works as a transport for HTTP, the server will not be able to instantly identify whether QUIC is used as the transport protocol or the new one is used.
If the proposed Next Header option is transmitted as a safe option in the surplus area, it will be ignored by a legacy UDP implementation, with the possible result of dispatching received packets to the wrong upper layer protocol. To me, at least, that seems is every bit as unsafe as dispatching UDP fragments or encrypted UDP packets to a legacy endpoint that does not understand them.
See also https://mailarchive.ietf.org/arch/msg/tsvwg/JPoH-JsrObcQbdWfRDNmIThyOoY/ and other discussion in that mailing list thread.
Gorry Fairhust writes:
We're heading to a WGLC - people implementing the spec or designing protocols that will use this spec will have a chance to comment on the definition of UNSAFE, during that stage. I'd recommend closing this issue, since we do now have updated text: "UNSAFE options are not safe to ignore and can be used unidirectionally or without soft-state confirmation of UDP option capability."
That's the text in Section 12, and as I said above, I agree that it satisfactorily addresses the substantive issues that have been discussed. However, I still believe that the explanatory text in Sections 10 and 11 is too narrow (thanks to Tom Herbert for pointing out the latter). So, once again, I will close this issue, but with the following comment (revised from the version above):
I would like to see the following change to the text in Section 10:
s/do alter the user data/do alter the user data (or the semantics thereof)/
and the following change to the text in Section 11:
s/which modify UDP user data/which modify UDP user data (or the semantics thereof)/
The above changes would address usages such as that in draft-daiya-tsvwg-udp-options-next-header without changing what is said in Section 12.
This can be discussed further during WGLC if necessary.
Thanks,
Mike Heard
jtouch
commented
3 months ago I disagree with "alter the semantics" as too vague and implying what could amount to arbitrary interpretation variations.
E.g., next-header might alter semantics, but it also might not - it might simply change which upper layer service handles the data. I have issues with that as being a useful UDP option at all.
The case under key consideration here is ACS, which neither alters the data nor its semantics, however.
So what we have is an argument entirely based on, AFAICT, an option that might not be approved and another case to which it does not apply.
tompandadev
commented
3 months ago On Sun, Mar 10, 2024 at 12:41 PM Joe Touch @.***> wrote:
I disagree with "alter the semantics" as too vague and implying what could amount to arbitrary interpretation variations.
E.g., next-header might alter semantics, but it also might not - it might simply change which upper layer service handles the data. I have issues with that as being a useful UDP option at all.
The case under key consideration here is ACS, which neither alters the data nor its semantics, however.
That is true. Ignoring an ACS risks silent data corruption. Ignoring Auth risks user security. So IMO, an UNSAFE option is one that must be processed if present for the packet to be correctly processed and to prevent harmful consequences.
Tom
So what we have is an argument entirely based on, AFAICT, an option that
might not be approved and another case to which it does not apply.
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1987341621, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK4WVEIARCR34XG64OLYXTAPTAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGM2DCNRSGE . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago Everything risks "not doing what the sender asked" - otherwise the sender would not have included the option. By your logic, there would be no SAFE options.
I do agree that APC might be renamed "additional" rather than "alternate", as it is not intended to be replacement for UDP CS (because legacy endpoints can't know it's there and know that the packet has a safety check and because it fails to cover the IP pseudo header and UDP header). It would thus be appropriate to use only with UDP CS. That can be made more clear in -32 if so.
tompandadev
commented
3 months ago On Sun, Mar 10, 2024 at 12:59 PM Joe Touch @.***> wrote:
Everything risks "not doing what the sender asked" - otherwise the sender would not have included the option. By your logic, there would be no SAFE options.
Joe,
Yes, any time a sender ignores something that they received there is some cost incurred to the sender, however the cost can vary greatly depending on what information is being ignored (if nothing else the sender burned cycles and bits on the wire to send information that has no effect).
For instance, ignoring a timestamp just means that the sender won't get the information and so it might not be able to optimize its retransmission timer; but the protocol still works and communications are robust, maybe just not optimized-- so it's "safe" to ignore timestamps. However, ignoring APC or Auth can have much more harmful consequences in silent data corruption and breaking security, so from my POV it is dangerous for the sender if the receiver ignores these-- so IMO it's "unsafe" to ignore APC and Auth.
Tom
I do agree that APC might be renamed "additional" rather than "alternate",
as it is not intended to be replacement for UDP CS (because legacy endpoints can't know it's there and know that the packet has a safety check and because it fails to cover the IP pseudo header and UDP header). It would thus be appropriate to use only with UDP CS. That can be made more clear in -32 if so.
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1987345760, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK44KZUMOLX4NLNUJHLYXTCTJAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGM2DKNZWGA . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago We agree, but UDP options are not intended to optimize for a kind of statefulness that UDP doesn't support. TCP does what you're expecting, though.
We probably ought to rename "safe" as "legacy-compatible"; the word "safe" seems to carry baggage that the definition in the doc (from nearly the beginning of the origin of these options) is not exactly consistent with.
Joe
Mike-Heard
commented
3 months ago We probably ought to rename "safe" as "legacy-compatible"; the word "safe" seems to carry baggage that the definition in the doc (from nearly the beginning of the origin of these options) is not exactly consistent with.
It's not clear to me that such a change would help in any way to resolve the disagreements lately aired here. I, for one, have always seen "legacy-compatible" and "safe" as meaning the same thing (I would, for instance, see the protocol number option in draft-daiya-tsvwg-udp-options-next-header as NOT being legacy compatible, as least as defined in that draft). The UDP options spec is likely to suffer some destabilization from such a move, and while that would be temporary, I would see that as another unwelcome delay at this late date.
Understood that one's mileage may vary on this point.
gorryfair
commented
3 months ago I'd personally agree that APC could be renamed "additional" rather than "alternate".
I'm less sure we need to change UNSAFE - a clear definition ought to be enough to say refers to whether it is compatible with legacy use.
gorryfair
commented
3 months ago Editor to consider if the change to definition of APC ought to be made.
tompandadev
commented
3 months ago On Mon, Mar 11, 2024 at 2:22 AM Gorry Fairhurst @.***> wrote:
I'd personally agree that APC could be renamed "additional" rather than "alternate".
Maybe call it "additional and best effort"
I'm less sure we need to change UNSAFE - a clear definition ought to be enough to say refers to whether it is compatible with legacy use.
— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1987956512, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKYNHZTIAY5UX4MAY2DYXVZXFAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXHE2TMNJRGI . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago "best effort" seems redundant given UDP is an unreliable, stateless protocol. Additional, alternate, supplemental, etc. - any of those seem appropriate.
tompandadev
commented
3 months ago On Tue, Mar 12, 2024 at 5:59 PM Joe Touch @.***> wrote:
"best effort" seems redundant given UDP is an unreliable, stateless protocol. Additional, alternate, supplemental, etc. - any of those seem appropriate.
Joe,
By "best effort" I was referring to the fact that APC might be correctly received but ignored by a receiver. This is different from UDP, where if a non-zero UDP checksum is received it MUST be validated by the receiver or the packet is dropped.
How about this text:
"When a sender sends the APC options, the receiver may ignore the option and accept the packet without validating the APC since the APC is a SAFE option. When a receiver ignores the APC option, data errors may be missed that would have otherwise been caught if APC was calculated. Note that a sender has no way of knowing if a receiver will validate or ignore the APC option. If a reliable data check that is not ignored by a receiver is required then it is RECOMMENDED to include a check, such as CRC, in the UDP payload itself."
Tom
—
Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1992899027, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK57WUSYBPRHOJCT2BDYX6QIVAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSHA4TSMBSG4 . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago All SAFE options are "receiver may ignore" and still get the user data. There's no reason to call this one out.
Additionally, there's no reason to recommend a CRC that could just as easily be ignored by a receiver. Any data check that needs to be reliable needs to, well, BE RELIABLE - which involves coordinating state between the endpoints. That state can easily be used to override the default for APC. We make that point clear in many places - that stateful behavior requires the user create and manage that state, as this is a user protocol.
tompandadev
commented
3 months ago On Tue, Mar 12, 2024, 10:32 PM Joe Touch @.***> wrote:
All SAFE options are "receiver may ignore" and still get the user data. There's no reason to call this one out.
Joe,
If other SAFE options risk silent data corruption or other harmful effects then maybe they should be called out as well. As I mentioned, ignoring Auth is a major security concern.
Additionally, there's no reason to recommend a CRC that could just as easily be ignored by a receiver. Any data check that needs to be reliable needs to, well, BE RELIABLE - which involves coordinating state between the endpoints. That state can easily be used to override the default for APC. We make that point clear in many places - that stateful behavior requires the user create and manage that state, as this is a user protocol.
That's incorrect. UDP checksum, TCP checksum, IP checksum, and Ethernet do NOT require negotiation. The rule is simple, if a receiver receivers any of the theses checks then they MUST be validated or the packet MUST be dropped. If they fail to do this then they're non-conformant with the standard.
In any case, since this is a new protocol and it diverges from semantics of existing protocols, I don't see what harm there is in clarifying the requirements and being completely transparent in the specification. APC does not work like UDP checksum that there user is familiar with-- that is a fact. Why not just be clear on this and avoid any ambiguity?
Tom
—
Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/23#issuecomment-1993599515, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKY7KLIQHC57XFDOA6DYX7QHTAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTGU4TSNJRGU . You are receiving this because you commented.Message ID: @.***>
jtouch
commented
3 months ago There are plenty of examples of extensions that are only ever silently ignored - new IPv4 options come to mind in particular, or new TCP options that would affect the SYN itself. Although those examples can be added to the general discussion, it's no more useful to call out APC as "hey this will not work as CRITICALLY if you don't override the default" than any other option whose use might be considered "critical" - which includes ALL options, SAFE ones too. I could create a protocol that won't work unless TIME is supported - if I do, it's my obligation to coordinate that with the receiver.
APC does not weaken a UDP packet, other than by reducing its payload size (as all our options do). Yes, using APC and not UDP CS would be a mistake (and that can be emphasized in the text) - not just because it can be silently ignored, but because coverage is different and because legacy path devices could misinterpret CS==0 as having no payload protection at all.
But this does NOT diverge from the semantics of any protocol being extended using a mechanism that was not anticipated with defined behavior for unknown codepoints when the core protocol was released.
Tom Herbert has asserted that "an UNSAFE option should be any option that MUST be processed for the packet to processed correctly." Joe Touch disagrees, and contends that only those options that modify the user data should be considered UNSAFE.
I agree with Tom, and I propose that the text in draft-ietf-tsvwg-udp-options-28 Section 6 and Section 11 be modified as follows:
s/modify user data/modify user data (or the semantics thereof)/
See also https://mailarchive.ietf.org/arch/msg/tsvwg/JPoH-JsrObcQbdWfRDNmIThyOoY/ and other discussion in that mailing list thread.