Processing and requirements of APC and Authentication options

[tompandadev]

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

[moeller0]

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.

[jtouch]

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.

[tompandadev]

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 https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/21#issuecomment-1797668702, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCKYEUQMLDFS3CVVBOP3YDGUA5AVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXGY3DQNZQGI . You are receiving this because you authored the thread.Message ID: @.***>

[jtouch]

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

https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/21#issuecomment-1797668702,

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: @.***>

[tompandadev]

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

< https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/21#issuecomment-1797668702>,

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 https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/21#issuecomment-1797935457, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK2QJZVI67G6C77TTDLYDHNTBAVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJXHEZTKNBVG4 . You are receiving this because you authored the thread.Message ID: @.***>

[jtouch]

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.

[tompandadev]

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 https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/21#issuecomment-1798964454, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASQYCK4UHLWKLBM7AFP3U4DYDJJYNAVCNFSM6AAAAAA5J6ISA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYHE3DINBVGQ . You are receiving this because you authored the thread.Message ID: @.***>

[jtouch]

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.

[tompandadev]

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: @.***>

[jtouch]

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

[jtouch]

[not addressed in -25 - I do not see consensus on needed changes]

[jtouch]

See response to #23.

[Mike-Heard]

I think that the substantive issues are satisfactorily addressed.