Mike-Heard
commented
1 month ago As there seems to be no convergence on this point, chairs may wish to put this specific question to the WG. I could go either way.
Open gorryfair opened 2 months ago
Mike-Heard
commented
1 month ago As there seems to be no convergence on this point, chairs may wish to put this specific question to the WG. I could go either way.
I have reviewed draft-ietf-tsvwg-udp-options-32. I will reiterate my primary objection to UDP options in that APC and Auth are defined as SAFE options and not UNSAFE options; as described below, I believe this can lead to harmful effects to the user in silent data corruption and security risks. Also, I have a number of other comments below. Additionally, UDP options diverges from the precedents set in other similar protocols in different aspects which I point out below.
1 If a sender sends an APC the receiver should not be allowed to ignore it
APC is a UDP option containing a CRC that is stated in the draft Per the draft a receiver may freely ignore an APC option. This is contrary to the precedent of other IETF protocols that contain data check mechanisms: a data check may be optional at the sender but not optional at a receiver, and if a receiver fails to validate a received checksum or CRC the behavior is to discard the packet. The most pertinent example is 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"
But the UDP options draft states "APC needs to be silently ignored when failing by default"
That is almost the complete opposite of how every protocol with a CRC or checksum works. For those, if CRC or checksum fails the packet is summarily dropped-- that's not only the default behavior, it's almost always the only behavior.
The argument that APC should be a SAFE option to ensure behavioral compatibility with legacy receivers. However, even in the case when UDP Options are explicitly sent to a non-legacy receiver in a FRAG option, the receiver may still ignore the APC. There is no way in UDP Options for a sender to insist that the receiver validates the CRC in an APC, and so when a sender sends an APC it never knows for sure whether the receiver will actually check the APC (again this is different behavior than UDP checksum and other protocols). Also, even if a receiver does process an APC, the draft offers no guidance on what to do in the case that verification fails. The only requirement is that "UDP packets with incorrect APC checksums MUST be passed to the application by default, e.g., with a flag indicating APC failure.", and there is no recommendation as to what the application should do in the case of a bad CRC (IMO, minimally it's at least a SHOULD that a packet with corrupted data be dropped).
All of this leads to the possibility of silent data corruption. When a sender chooses to use the APC it is doing so to protect the data it's sending. If a receiver ignores the APC then that will inevitably miss data errors. If there are no other mechanisms to catch those errors, then corrupted data may go all the way to the application. This is silent data corruption which could be a very costly problem and bring harm to the user. IMO, the risk of silent data corruption outweighs the ease of deployment argument.
2 If a sender sends an Auth the receiver should not be allowed to ignore it
The Auth is also a SAFE Option that can be ignored by a receiver, and this is also a divergence from established precedent. For instance, if the AH header is essentially equivalent to the IP Auth header, however from RFC4302:
"If the computed and received ICVs match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid."
Ignoring Auth is perhaps more dangerous than ignoring APC since it is a security risk. If a sender sends an Auth and it's arbitrarily ignored by a receiver then that means that most likely no packets are authenticated and hence there is no security for the user. However, Auth has another property that motivates it to always be an UNSAFE option: given that authentication requires some key negotiation at both the sender and the receiver, there doesn't seem to be a valid use case for a sender ever sending Auth to a legacy receiver. That is, why would the system negotiate a key for a legacy receiver that doesn't even support UDP Options? IMO, the security risks outweigh the ease of deployment argument.
(Added by GF during WGLC)