Tom H: WGLC comments on design of APC and Auth

[gorryfair]

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)

[Mike-Heard]

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.

[jtouch]

The term SAFE seems to be misconstrued as implying that a receiver can always ignore the option. The issue is only in the default case, which is specifically designed to mimic legacy endpoint behavior. In that case, any option that doesn't actually modify the data is "SAFE". Perhaps better terms for SAFE and UNSAFE would be "UNMODIFIED DATA" and "MODIFIED DATA". A receiver that wants to protect itself against APC errors is always welcome to change that default, as is one that intends to enforce AUTH. However, even AUTH would break a receiver who lacks the appropriate credentials - which isn't how many authentication mechanisms work (e.g., email).

[jtouch]

I’ve made my position clear on the default. Perhaps we should be clear that this is the “default default”, i.e., systems can override this default on a system-wide basis through active configuration, with the risk being that they are no longer behaving as a legacy system would (this may be desired, e.g., for highly secure systems).

Would this work”?

If a system has a system default applied to all new connections, it MUST be initially set to silent ignore and MAY be changed by direct action (e.g., explicit reconfiguration, privileged user or application). Each new connection default MUST be a silent unless a system default is defined, in which case it could follow the system default.

[Mike-Heard]

APC and AUTH remain ordinary SAFE options in -33, meaning that failure of either one does not (by default) cause the packet to be discarded. The status is passed to the application/upper layer, which many then make a decision whether to accept or reject the packet.

[gorryfair]

Closing this with the expectation that a specification for AUTH (in another draft) might include further text about what to do when the security association is established and how then to handle packets that either do not carry an AUTH option or where the AUTH option is not valid.