The definition of UNSAFE options should not be limited to options that modify user data #23
Comments
|
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. |
|
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. |
|
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:
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. |
|
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
|
|
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
|
|
Riterating my points on the list why options such as ACS and Auth should be UNSAFE even though then don't explictily modify data.
|
|
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. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKZCZP37AVH57NW2N4DYLWK6JAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGMYDSOBUHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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:
This thread also has several places where I have already addressed this. In summary:
Joe |
|
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:
1. 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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK6NHOZQBI2NJJEP473YLWT4TAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGM3DINRWGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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:
1. 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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK6NHOZQBI2NJJEP473YLWT4TAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGM3DINRWGU>
.
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: ***@***.***>
|
|
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:
>
> 1. 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
> <
#23 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ASQYCK6NHOZQBI2NJJEP473YLWT4TAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGM3DINRWGU>
> .
> 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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKZJ6GRVJ3IMYD3A6CDYLYCMPAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZRGYZTINJXGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Updated based on discusson on Feb 19 with Gorry Fairhurst and Mike Heard: |
|
I think that the substantive issues are addressed and that the definition in -31 Section 12 is fine:
However, I still see in -31 Section 10:
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)/ |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKZZ5MPWSV4GTWTVPSDYWUWJHAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHA2DMNBSGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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
|
|
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. |
|
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: ***@***.***>
|
|
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: ***@***.***>
|
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKYIU7CBGPNZVF2WFTTYWXVFLAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGEZTAOJQGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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 |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK2SHYAALYYREEJBPR3YWYC5FAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGM2TAOJUGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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 |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK74LIQXFOQSEGX6C3LYWYYS7AVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGY2DKOJVGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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:
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. |
|
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. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK3ZJ72MNOFXUKV3JDTYWZCANAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZG42TEMRWGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Skype call between the co-chair and the document editor, which I was invited to join. Mike Heard |
|
Does a private skype call allow the desired public scrutiny of the sausage making inherent in an IETF RFC? |
|
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? |
|
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. |
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.
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. |
|
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: |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKYGNSW2AJUTFC722NTYXSMNPAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGMYDQNZWHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Mike Heard wrote:
Joe Touch replied:
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:
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:
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):
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 |
|
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. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK4WVEIARCR34XG64OLYXTAPTAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGM2DCNRSGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK44KZUMOLX4NLNUJHLYXTCTJAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXGM2DKNZWGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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 |
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. |
|
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. |
|
Editor to consider if the change to definition of APC ought to be made. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKYNHZTIAY5UX4MAY2DYXVZXFAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBXHE2TMNJRGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
"best effort" seems redundant given UDP is an unreliable, stateless protocol. Additional, alternate, supplemental, etc. - any of those seem appropriate. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK57WUSYBPRHOJCT2BDYX6QIVAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJSHA4TSMBSG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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. |
|
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
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKY7KLIQHC57XFDOA6DYX7QHTAVCNFSM6AAAAAA73EP4SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTGU4TSNJRGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
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.
The text was updated successfully, but these errors were encountered: