Processing and requirements of APC and Authentication options #21
Comments
|
My take in this is, UDP options clearly are not a protocol in themselves, but building blocks to create protocols running on top pf a UDP carrier abstracting out a number of assumed useful types of information a real protocol might want to use. By that logic the real protocol lives on top of UDP and hence it seems suitable to have that protocol layer make decisions about what to reject and what to keep, so passing packets with incorrect checksums on might still be in-line with how other protocols operate. But the onus to do something reasonable with those packets is on the layer on top of UDP that implements the actual protocol. |
|
The goal of UDP options is to first and foremost be backward compatible with legacy receivers. Because a legacy receiver will, by default, ignore UDP options, the default for APC is to pass the packet - along with the indicator that the checksum has failed - to the user. The user default is to accept such a packet, just as a legacy receiver would. This is IMO already clear in the document. The default for CRC is to cease option processing but also to pass the packet up to the user. In that case, the CRC indicates only that the option area is incorrect; it is NOT an indication about the UDP user data. Users are free to make other decisions, but that is why these are the defaults. |
|
On Mon, Nov 6, 2023 at 7:35 PM Joe Touch ***@***.***> wrote:
The goal of UDP options is to first and foremost be backward compatible
with legacy receivers. Because a legacy receiver will, by default, ignore
UDP options, the default for APC is to pass the packet - along with the
indicator that the checksum has failed - to the user. The user default is
to accept such a packet, just as a legacy receiver would. This is IMO
already clear in the document.
The default for CRC is to cease option processing but also to pass the
packet up to the user. In that case, the CRC indicates only that the option
area is incorrect; it is NOT an indication about the UDP user data.
Joe,
I'm confused, the draft states: "The Alternate Payload Checksum (APC,
Kind=2) option provides a stronger alternative to the checksum in the UDP
header, using a 32-bit CRC of the conventional UDP user data payload only"
Doesn't that mean that the CRC covers the UDP payload?
Also, the statement "The Alternate Payload Checksum option provides a
stronger alternative to the checksum in the UDP header" is only true _if_
the APC is actually validated by the receiver. If it is ignored by the
receiver, either by a legacy receiver or the receiver limiting the number
of TLVs processed per section 23, then it offers no verification of the
data and so is not a stronger alternative to the UDP checksum.
Users are free to make other decisions, but that is why these are the
defaults.
Yes, but there's two users in a communication: the sender and receiver. If
the sender decides to send an APC then it is making a decision that it
wants strong protection for the data it's sending. If the receiver decides
not to validate a received APC then it is disregarding the decision and
intent of the sender. So the decisions made by the two users would seem to
be in conflict. The practical effects are the potential for undetected data
corruption and wasted compute cycles by senders.
Note that the UDP checksum does not have the same conflict, from RFC1122:
"If a UDP datagram is received with a checksum that is non-zero and
invalid, UDP MUST silently discard the datagram."
Tom
—
… Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKYEUQMLDFS3CVVBOP3YDGUA5AVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGY3DQNZQGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
On Nov 6, 2023, at 10:37 PM, tompandadev ***@***.***> wrote:
On Mon, Nov 6, 2023 at 7:35 PM Joe Touch ***@***.***> wrote:
The goal of UDP options is to first and foremost be backward compatible
with legacy receivers. Because a legacy receiver will, by default, ignore
UDP options, the default for APC is to pass the packet - along with the
indicator that the checksum has failed - to the user. The user default is
to accept such a packet, just as a legacy receiver would. This is IMO
already clear in the document.
The default for CRC OCS is to cease option processing but also to pass the
packet up to the user. In that case, the CRC OCSindicates only that the option
area is incorrect; it is NOT an indication about the UDP user data.
Joe,
I'm confused, the draft states: "The Alternate Payload Checksum (APC,
Kind=2) option provides a stronger alternative to the checksum in the UDP
header, using a 32-bit CRC of the conventional UDP user data payload only"
Doesn't that mean that the CRC covers the UDP payload?
See above. I’ll reissue that shortly.
Also, the statement "The Alternate Payload Checksum option provides a
stronger alternative to the checksum in the UDP header" is only true _if_
the APC is actually validated by the receiver. If it is ignored by the
receiver, either by a legacy receiver or the receiver limiting the number
of TLVs processed per section 23, then it offers no verification of the
data and so is not a stronger alternative to the UDP checksum.
It is stronger, but the default is to let the application decide whether that strength is used.
Users are free to make other decisions, but that is why these are the
defaults.
Yes, but there's two users in a communication: the sender and receiver. If
the sender decides to send an APC then it is making a decision that it
wants strong protection for the data it's sending.APC used as defined means the sender intends for a legacy receiver to ifbore it. That’s why the default is as it is for nonlegacy receivers - see the new design principles section as a reminder of the principles that have governed the option design from the beginning. If the receiver decides
not to validate a received APC then it is disregarding the decision and
intent of the sender.It legitimately emulates a legacy receiver unless the receiving user/app decides otherwise. So yes, the receiver decides, but the default is legacy behavior. So the decisions made by the two users would seem to
be in conflict. The practical effects are the potential for undetected data
corruption and wasted compute cycles by senders.
The sender offers. The receiver decides what to do with the offer.
Note that the UDP checksum does not have the same conflict, from RFC1122:
"If a UDP datagram is received with a checksum that is non-zero and
invalid, UDP MUST silently discard the datagram."
Yes, but that was defined when we had control over legacy receiver behavior. We do not anymore.Joe
Tom
—
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCKYEUQMLDFS3CVVBOP3YDGUA5AVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGY3DQNZQGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
|
On Mon, Nov 6, 2023 at 11:13 PM Joe Touch ***@***.***> wrote:
On Nov 6, 2023, at 10:37 PM, tompandadev ***@***.***> wrote:
On Mon, Nov 6, 2023 at 7:35 PM Joe Touch ***@***.***> wrote:
> The goal of UDP options is to first and foremost be backward compatible
> with legacy receivers. Because a legacy receiver will, by default,
ignore
> UDP options, the default for APC is to pass the packet - along with the
> indicator that the checksum has failed - to the user. The user default
is
> to accept such a packet, just as a legacy receiver would. This is IMO
> already clear in the document.
>
> The default for CRC OCS is to cease option processing but also to pass
the
> packet up to the user. In that case, the CRC OCSindicates only that the
option
> area is incorrect; it is NOT an indication about the UDP user data.
>
Joe,
I'm confused, the draft states: "The Alternate Payload Checksum (APC,
Kind=2) option provides a stronger alternative to the checksum in the UDP
header, using a 32-bit CRC of the conventional UDP user data payload only"
Doesn't that mean that the CRC covers the UDP payload?
See above. I’ll reissue that shortly.
Also, the statement "The Alternate Payload Checksum option provides a
stronger alternative to the checksum in the UDP header" is only true _if_
the APC is actually validated by the receiver. If it is ignored by the
receiver, either by a legacy receiver or the receiver limiting the number
of TLVs processed per section 23, then it offers no verification of the
data and so is not a stronger alternative to the UDP checksum.
It is stronger, but the default is to let the application decide whether
that strength is used.
Joe,
There are two applications here, the sending application and the receiving
application. If the sending application sets the APC then it is deciding
that a strong data verification is to be used, for instance maybe the
sender is at the other end of an unreliable satellite link and wants a
strong verification of sensitive data it's sending. If the receiving
application is allowed to ignore the APC sent by the sending application,
then it's not honoring the sender's request. The net effect of that is that
the APC is ineffective, undetected data corruption is possible, and the
sender wasted CPU cycles and power computing a CRC that's never used
(computing a CRC is much more expensive than a checksum)
Note that the general rule of IETF protocols is that checksums or CRCs may
be optional to set by the sender, but it's not optional for a receiver to
ignore checksums or CRCs that are present in a packet. Ignoring them is not
correct and non-deterministic.
> Users are free to make other decisions, but that is why these are the
> defaults.
>
Yes, but there's two users in a communication: the sender and receiver. If
the sender decides to send an APC then it is making a decision that it
wants strong protection for the data it's sending.APC used as defined
means the sender intends for a legacy receiver to ifbore it. That’s why the
default is as it is for nonlegacy receivers - see the new design principles
section as a reminder of the principles that have governed the option
design from the beginning. If the receiver decides
not to validate a received APC then it is disregarding the decision and
intent of the sender.It legitimately emulates a legacy receiver unless the
receiving user/app decides otherwise. So yes, the receiver decides, but
the default is legacy behavior. So the decisions made by the two users
would seem to
be in conflict. The practical effects are the potential for undetected
data
corruption and wasted compute cycles by senders.
The sender offers. The receiver decides what to do with the offer.
Note that the UDP checksum does not have the same conflict, from RFC1122:
"If a UDP datagram is received with a checksum that is non-zero and
invalid, UDP MUST silently discard the datagram."
Yes, but that was defined when we had control over legacy receiver
behavior. We do not anymore.Joe
We can control the behavior at a legacy receiver by making APC an UNSAFE
option. A packet with an APC cannot be processed correctly by a legacy
receiver. If APC is an UNSAFE option then legacy receivers don't ever see
the option so correctness is maintained (assuming a non-legacy receiver
MUST validate the APC if present).
Tom
…
Tom
—
> Reply to this email directly, view it on GitHub
> <
#21 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ASQYCKYEUQMLDFS3CVVBOP3YDGUA5AVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGY3DQNZQGI>
> .
> You are receiving this because you authored the thread.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
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK2QJZVI67G6C77TTDLYDHNTBAVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXHEZTKNBVG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
OK, so the doc does not need an update. My response that cited CRC was the only point of confusion - I should have referred to OCS rather than CRC. The rest of this thread raises no new issues. UDP options were always designed to behave consistently with a legacy endpoint by default - the default never adds UDP options and the default silently accepts all received options UNLESS OCS fails, at which point only the failed OCS is indicated. Just as it is the sender's prerogative what to send, it remains the receivers' prerogative which SAFE options to require or ignore. |
|
On Tue, Nov 7, 2023 at 7:47 AM Joe Touch ***@***.***> wrote:
OK, so the doc does not need an update. My response that cited CRC was the
only point of confusion - I should have referred to OCS rather than CRC.
The rest of this thread raises no new issues.
Yes, but it reiterates an open issue.
UDP options were always designed to behave consistently with a legacy
endpoint by default needed
But the behavior isn't consistent. If a sender sends the same packet to a
legacy receiver and one to a non-legacy receiver with APC and the packet is
corrupted, then the non-legacy receiver should drop the packet as being
corrupted but the legacy receiver would accept the packet. That is NOT
consistent behavior between legacy and non-legacy receivers.
Tom
- the default never adds UDP options and the default silently accepts all
received options UNLESS OCS fails, at which point only the failed OCS is
indicated. Just as it is the sender's prerogative what to send, it remains
the receivers' prerogative which SAFE options to require or ignore.
—
… Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASQYCK4UHLWKLBM7AFP3U4DYDJJYNAVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYHE3DINBVGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Note also that UNSAFE options are designed for those that modify user data. APC does not modify user data, so it should not be considered an UNSAFE option. I As to "typical IETF requirements", UDP options cannot simultaneously support that expectation AND equivalence with legacy receivers by default. That latter is the result of extending a widely deployed protocol with minimal impact until explicitly activated by the user. And yes, it's an open issue, but no - none of these points are new, so they don't warrant new responses. |
|
On Tue, Nov 7, 2023 at 8:03 AM Joe Touch ***@***.***> wrote:
Note also that UNSAFE options are designed for those that modify user data. APC does not modify user data, so it should not be considered an UNSAFE option.
I don't believe there is consensus on that definition. The alternate
definition is that an UNSAFE option is any option that MUST be
processed for the packet to be processed correctly. That would include
options that modify data, but also those where ignoring the option is
incorrect (IMO, ignoring a CRC that might indicate the packet is
corrupt is not correct behavior).
As to "typical IETF requirements", UDP options cannot simultaneously support that expectation AND equivalence with legacy receivers by default. That latter is the result of extending a widely deployed protocol with minimal impact until explicitly activated by the user.
How do you define "minimal impact"? If a datacenter deploys UDP
Options enabling APC on senders but not on receivers then every single
Watt needed to compute the CRC by the sender is wasted energy. How
many wasted Watts qualify as "minimal impact"? And if data corruption
makes it all the way through to users' data, how many dollars to fix
undetected data corruptions qualify as "minimal impact"?
Tom
…
And yes, it's an open issue, but no - none of these points are new, so they don't warrant new responses.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
On Nov 7, 2023, at 8:29 AM, tompandadev ***@***.***> wrote:
On Tue, Nov 7, 2023 at 8:03 AM Joe Touch ***@***.***> wrote:
>
> Note also that UNSAFE options are designed for those that modify user data. APC does not modify user data, so it should not be considered an UNSAFE option.
I don't believe there is consensus on that definition.
That has been the definition since the beginning and it has passed every call for consensus to date without being raised, as well as being referred to in nearly every summary of UNSAFE options.
Joe
|
|
[not addressed in -25 - I do not see consensus on needed changes] |
|
See response to #23. |
|
I think that the substantive issues are satisfactorily addressed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The processing and requirements of APC and Authentication options are not clear in the draft, especially in regards to what actions receiver takes if an APC value fails to be verified or authentication fails. To be consistent with other IETF protocols, the behavior should be to drop when CRC or authentication validate fails
The text was updated successfully, but these errors were encountered: