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/
