Hello, I've raised concerns several times in the working group concerning the fact the Authentication Option may be arbitrarily ignored by a receiver, such that packets containing the option are accepted without being authenticated. The chairs declared consensus on this, however at best that was a weak consensus (the WG chair called it "consensus in the rough"). I believe these concerns merit review by IESG as, IMO, it is a potential security liability in the protocol. My specific concerns are: 1) The Authentication Option is a SAFE option which means it may be ignored by a receiver when present in a packet. I believe this is inconsistent with other IETF Authentication protocols including IPv6 Auth Header and TCP authentication options where the rule is that if the option is authentication is present it MUST be validated before accepting the packet. The effect of this is that a sender might send an authentication option which has no effect (other than costing the sender CPU cycles to compute the HMAC and burning bits on the wire). Effectively, this is either a "false sense of security" or "best effort security" 2) Even if the Authentication Option is recognized and processed, the draft does not specify what the receiver is supposed to do if authentication fails. The required behavior is that the packet should be sent to the "user" who presumably could decide what to with a packet with an authentication failure, but there is no guidance on that. This is also inconsistent with IETF convention, in other protocols the normal behavior is when authentication fails is to drop the packet at that point 3) The description of the Authentication Option (section 11.9 of -38) is labeled as Reserved. It is just a placeholder, and the requirements are incomplete and the option is unimplementable. IMO, this is not appropriate for a Standards Track document, and section 11.9 and any discussion of Authentication could be removed without any loss of substantive content. (removing the section would also sidestep issues #1 and #2) Note that issues #1 and #2 are also concerns of the Additional Payload Checksum option (a CRC, section 11.3 of -38). A receiver may ignore the set option which is inconsistent with other protocols like iSCSI CRC or UDP checksum. Likewise, the draft does not specify a behavior, like dropping the packet, when the CRC is calculated and determined to be invalid. Technically, this isn't a security concern, however ignoring a CRC could lead to undetected data corruption which could be quite detrimental. Thanks, Tom On Mon, Jan 27, 2025 at 8:57 AM The IESG <iesg-secretary@xxxxxxxx> wrote: > > > The IESG has received a request from the Transport and Services Working Group > WG (tsvwg) to consider the following document: - 'Transport Options for UDP' > <draft-ietf-tsvwg-udp-options-38.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@xxxxxxxx mailing lists by 2025-02-10. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > Transport protocols are extended through the use of transport header > options. This document updates RFC 768 (UDP) by indicating the > location, syntax, and semantics for UDP transport layer options > within the surplus area after the end of the UDP user data but > before the end of the IP length. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/2673/ > > > > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
