[tsvwg] A review of draft-ietf-tsvwg-udp-options-12

["C. M. Heard" <[e-mail]>]

TSVWG,

This message is a detailed review of draft-ietf-tsvwg-udp-options-12. My
apologies for the length delay in getting it out. My opinion is that the
draft is NOT READY for WG last call; it needs at least one more pass to
correct some significant editorial and technical errors. Please note that
there will be a follow-on message dealing exclusively with the FRAG option;
I think it would be helpful if responses concerning that option were sent
as part of that thread.

Here is a summary of major issues that IMO still need to be addressed.
Details (and some less important issues) will follow.

   1. Minimum option lengths: there is contradictory text between Section
   4, which requires that the entire option area be dropped if an option
   length is too small, and section 5, which states that receivers cannot treat
   unexpected option lengths as invalid.
   2. Extended length format: there is contradictory text (also between
   Sections 4 and 5) as to whether the extended length format is required in
   all cases for all options that may need it, or whether the encoding
   should be the simplest possible. Recommendation: go with the latter
   (default format when possible, extended format only when the option
   instance occupies 255 bytes or more).
   3. Required options: I have no objection to requiring an implementation
   to recognize all of EOL, NOP, OCS, ACS, MSS, MRSS, and FRAG. I do,
   however, strongly object to requiring that an implementation be required to
   support generation and reassembly of fragments. I think it is very likely
   too high a bar for many implementers, and as much as I like the FRAG
   option, I would rather see the FRAG option removed altogether than see
   uptake of the specification impeded by a requirement to actually implement
   fragmentation and reassembly. There is a distinction between "must support"
   and "must recognize," and I think the spec needs to reflect this nuance.
   4. EOL option: the -12 draft requires that trailing padding
   following NOP be zeroes and requires that the receiver check that this is
   the case. I point out that this defeats the whole raison d'être for this
   option, and that if this requirement is maintained we might as well
   eliminate EOL and use NOP instead. Recommendation: keep the requirement
   that all padding past EOL be all zeroes, but do not require the receiver to
   check this. Correct decisions on this matter require careful thinking about
   the threat model and specifically on how covert channels would actually be
   used and countered by security equipment (hint: the behavior of a benign
   receiver has no role in countering typical threats).
   5. NOP option: why a limit of three? Why not allow seven NOPs for
   8-octet alignment? (Note: an arbitrary number at the end would need to be
   allowed if EOL is deleted).
   6. FRAG: the spec in the -12 draft is not coherent as it stands
   (specifically, OFFSET is not defined). At a minimum that needs to be
   corrected and the text edited to make the narrative coherent; however,
   there is a more economical way to design FRAG, and my subsequent message
   presents that alternative.
   7. MRSS: if the WG agrees that the capability to reassemble fragments
   should be optional, then there should be a stipulation that inclusion of
   the MRSS option indicates that the sender is capable of reassembling UDP
   fragments up to the limit indicated by MRSS. This would be an ideal way to
   enable the use of FRAG with DNS, a prime use case.
   8. UNSAFE option: what is propsed will work, but it is much less
   efficient than allocating a single bit in the option kind for this purpose.
   I'm aware that this was introduced several months ago, in the -09 draft,
   but as far as I can tell, there has been no discussion of the WG about this
   point. At a minimum I would like to see that discussion take place.
   9. AE: it is unclear to me why this is not considered to be an unsafe
   option, especially when the datagram is encrypted. There is also a
   per-fragment vs per-datagram ambiguity that needs to be resolved.
   Per-datagram is more in line with TCP-AO (in which case making it UNSAFE is
   correct).

Below is a section-by-section review covering the above points in more
detail, as well as a few relatively minor issues.

*Section 4, Page 7:*

   >> Any UDP option whose length is only smaller than 255 MUST always
   use the UDP option default format shown in Figure 4, excepting only
   EOL and NOP.


*Changing "is only smaller" to "is always smaller" would make this read
better. Also, the list of exceptions should include OCS (and FRAG, if my
forthcoming proposal is accepted), since that option (those options) have
no length field.*

   >> Any UDP option whose length can be larger than 254 MUST always
   use the UDP option extended default format shown in Figure 5,
   including UNSAFE and EXP.

   I.e., a UDP option always uses only the default format or the
   extended default format, depending on whether its length is only
   ever smaller than 255 or not.


*That is contradicted in Section 5 on page 9 by:*

   >> Options with fixed lengths MUST use the default option format.

   >> Options with variable lengths MUST use the default option format
   where their total length is 254 bytes or less.

   >> Options using the extended option format MUST indicate extended
   lengths of 255 or higher; smaller extended length values MUST be
   treated as an error.


*That contradiction must be resolved, preferably by accepting the language
in Section 5 and rewriting the earlier language (i.e., always use the
format that produces the shortest encoding). The language in the UNSAFE and
EXP sections needs to be reconciled also.*

   >> UDP options MUST be interpreted in the order in which they occur
   in the UDP option area.


*An exception should be allowed for OCS. It can be processed by computing
the Internet checksum over the surplus area conceptually prefixed by its
length, before attempting to parse any TLVs in the surplus area. This
should be a permissible implementation option (and IMO should be actively
encouraged).*

*Section 5, Page 8:*

   >> An endpoint supporting UDP options MUST support those marked with
   a "*" above: EOL, NOP, OCS, ACS, FRAG, MSS, MRSS, and UNSAFE. This
   includes both recognizing and being able to generate these options
   if configured to do so. These are called "must-support" options.


*I do not object that implementations should be required to recognize these
options, but IMO it is a BAD IDEA to REQUIRE implementation of reassembly
of fragments. It should be sufficient that implementations of UDP options
recognize FRAG, be able to process a self-contained terminal fragment that
is also an initial fragment, and be able to recognize and discard sequences
of fragments if they are not able to reassemble them. As a corollary, it is
also necessary that implementations be able to indicate when they do
support reassembly, and I propose that inclusion of MRSS in a packet so
indicate -- thus, there should be no need to send MRSS unless reassembly of
UDP fragments is supported, nor to process MRSS unless generation of UDP
fragments is supported. So, in summary, I propose:*

- All implementations of UDP options must support EOL, NOP, OCS, ACS (using
CRC32c), and MSS.
- All implementations must be able to recognize and process a
self-contained terminal fragment that is also an initial fragment.
- Support for generation and reassembly of UDP fragments is OPTIONAL (and
an implementation may support one of these capabilities without supporting
the other).
- If an implementation supports reassembly of UDP fragments, it must be
able to generate the MRSS option.
- If an implementation supports generation of UDP fragments, it must be
able to honor the MRSS option.
- All implementations must be able to recognize FRAG in both terminal and
non-terminal forms and to discard packets with non-terminal fragments if
reassembly is not supported.
- All implementations must be able to recognize UNSAFE options and discard
packets that contain UNSAFE options that are unknown or that occur outside
of a UDP fragment.

*Section 5, Page 9:*

   Receivers cannot treat unexpected option lengths as invalid, as this
   would unnecessarily limit future revision of options (e.g., defining
   a new ACS that is defined by having a different length).


*That is contradicted in Section 4 on page 7 by*

   >> Option Lengths (or Extended Lengths, where applicable) smaller
   than the minimum for the corresponding Kind and default format MUST
   be treated as an error. Such errors call into question the remainder
   of the option area and thus MUST result in all UDP options being
   silently discarded.


*That contradiction must be resolved, preferably by accepting the language
in Section 5 and deleting the above paragraph from Section 4 (i.e., always
treat a length that is not understood by skipping the option, except in the
case of ACS, where it should be treated as a checksum failure). A minimum
length dependent on the option Kind could not possibly work for any options
to be defined in the future, since their minimum lengths are unknown to old
implementations, and we need to ensure that new options can be correctly
processed by those old implementations. If the objective is to treat as a
parse error a default format length less than 2 or an extended format
length less than 255 (or 4 if we don't enforce a smallest encoding rule),
then that is what this paragraph should say (while noting also that the
rule does not apply to the mandatory-to-recognize options defined in this
spec that have an implied length).*

   >> "Must-support" options other than NOP and EOL MUST come before
   other options.


*This text does not properly take into account the interaction with FRAG
(either as specified in the -12 draft or in my forthcoming
counter-proposal).*

*Section 5.1, Page 9:*

   The End of Options List (EOL) option indicates that there are no
   more options. It is used to indicate the end of the list of options
   without needing to pad the options to fill all available option
   space.



*That last phrase ("without needing to pad") is contradicted in Section 5.1
on page 10 by:*

   >> All bytes in the surplus area after EOL MUST be zero. If these
   bytes are non-zero, the entire surplus area MUST be silently ignored
   and only the UDP data passed to the user with an adjusted UDP length
   to indicate that no options were present.

   Requiring the post-option surplus area to be zero prevents side-
   channel uses of this area, requiring instead that all use of the
   surplus area be UDP options supported by both endpoints. It is
   useful to allow for such padding to increase the packet length
   without affecting the payload length, e.g., for UDP DPLPMTUD [Fa21].


*There is NO POINT in having an EOL option if the entire data area
following the EOL contains data that must be checked by the receiver. You
might as well just fill the remaining surplus area with NOPs, which would
force all use of the surplus area to be supported by both endpoints … if,
that is, they both support UDP options, and modulo the "SHOULD NOT" in Sec.
5.2 (which could be adjusted). But I think that is the wrong direction to
go.*

*Allow me to point out that malicious actors who might use the surplus area
to exfiltrate information (e.g., stolen credit card data) in violation of a
security policy can do so NOW unless intermediate systems are present to
monitor the potentially illegitimate uses and filter the packets containing
them. My recommendation would be to say that the sender MUST fill the area
past EOL with zeroes so that network security devices can easily detect
illegitimate uses, but to levy NO requirements on the receiver to verify
this. (For a good explanation of data exfiltration using DNS, see
https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html
<https://blogs.akamai.com/2017/09/introduction-to-dns-data-exfiltration.html>;
certainly in that scenario, the well-behaved receivers have no role to play
in prevention of illegitimate exfiltration of data).*

*Section 5.2, Page 10:*

   >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs
   are intended to assist with alignment, not other padding or fill.


*Assuming that the comments on Section 5.1 do not result in a need for more
extensive surgery, the question arises why it would not be legitimate to
allow for seven consecutive NOPs so as to achieve eight-octet alignment.*

*Section 5.3, Page 11:*

   >> When present, the OCS SHOULD occur as early as possible, preceded
   by only NOP options for alignment and the FRAG option if present.


*This language will need to be adjusted if the forthcoming  FRAG
counter-proposal is accepted.*

   This Internet checksum is computed over the surplus area (including
   EOL, if present)


*s/EOL, if present/EOL and any trailing zeroes, if present/ (unless EOL is
eliminated based on previous comments).*

   As a reminder, use of the UDP checksum is optional when the UDP
   checksum is zero. When not used, the OCS is assumed to be "correct"
   for the purpose of accepting UDP packets at a receiver (see Section
   7).


*s/UDP checksum is optional/option checksum is optional/*

*Section 5.4, Page 13:*

   >> Packets with incorrect ACS checksums MUST be passed to the
   application by default, e.g., with a flag indicating ACS failure.

   Like all non-UNSAFE UDP options, ACS need to be silently ignored
   when failing. Although all UDP option-aware endpoints support ACS
   (being in the required set), this silently-ignored behavior ensures
   that option-aware receivers operate the same as legacy receivers
   unless overridden.


*There should be no prohibition on having a per-socket option to silently
discard datagrams with incorrect ACS, so: **s/ACS need to be silently
ignored when failing/ACS needs to be silently ignored when failing, unless
different behavior has been configured/. Also, please add the following (cf
Section 5, Page 9):*

   >> Packets with unrecognized ACS lengths MUST be receive the same

   treatment as packets with incorrect ACS checksums.


*Section 5.5, Pages 13-16:*

   The Fragmentation option (FRAG) combines properties of IP
   fragmentation and the UDP Lite transport protocol [RFC3828].

[ . . . ]

   >> When FRAG is present, it MUST come first in the UDP options list.

   >> When FRAG is present, the UDP payload MUST be empty. If the
   payload is not empty, all UDP options MUST be silently ignored and
   the payload received to the user.

[ . . . ]

                   +--------+--------+--------+--------+
                   | Kind=4 | Len=10 |      Offset     |
                   +--------+--------+--------+--------+
                   |           Identification          |
                   +--------+--------+--------+--------+
                   |  Frag. Offset   |
                   +--------+--------+

              Figure 11   UDP non-terminal FRAG option format

[ . . . ]

                   +--------+--------+--------+--------+
                   | Kind=4 | Len=12 |      Offset     |
                   +--------+--------+--------+--------+
                   |           Identification          |
                   +--------+--------+--------+--------+
                   |  Frag. Offset   | Reassy. Checksum|
                   +--------+--------+--------+--------+

                Figure 12   UDP terminal FRAG option format


*The Offset field, and the other provisions quoted above, were introduced
in going from -08 to -09. Unfortunately, there is no new text that contains
the definition and usage of the Offset field. I can guess that "Offset" is
intended to mean the offset to the next option (i.e., the number of octets
of fragment data), but this should not be left for the reader to
infer. Without this being clearly specified, it is not possible for an
implementer to know for sure what to implement. The statement in the first
paragraph of the section that partial checksum coverage is provided is, as
far as I can tell, no longer true; with the updated OCS specification (and
specifically the requirement to include OCS whenever the UDP checksum is
present), there is no real possibility of partial checksum coverage (and
indeed, a partial checksum would defeat the middlebox traversal properties
that the updated OCS was designed to provide). Additionally, there is no
longer any need for a reassembly checksum: given that the OCS option covers
the entire surplus area (and is mandatory whenever the UDP checksum is
non-zero), it provides complete segment-by-segment checksum coverage. That
provides coverage for the reassembled datagram payload that is equivalent
to that provided by TCP for an equivalent amount of data. The analogy is
essentially perfect because the fragment offset (in the context of a given
Identification value) is exactly analogous to the TCP sequence number. The
only errors that would be detected by a separate reassembly checksum that
would not be detected by OCS would be two sets of errors, one in the
options overhead and the other in the fragment data, that together happen
to have a zero checksum. That is possible, but it is unlikely, and it is
something that TCP has dealt with successfully over the years. ACS is
available for situations when a stronger checksum for the reassembled data
is desired.*

*In a forthcoming message I will make an alternative proposal that includes
full replacement text for Section 5.2. The basic idea originally appeared
in https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg/
<https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg/>.
The** main features are:*

*- Eliminate the Offset field and the requirement that FRAG appear first.
Instead, require that the FRAG option appear LAST and consume all following
surplus data.*
*- Eliminate the Reassy. Checksum field and replace Len (which would
otherwise have a fixed value of 8) by a More Fragments (MF) flag.*

*Please respond to that message to criticize the alternate FRAG proposal.
It's fair to reply to this message to rebut my critique of the existing
text in Section 5.2.*

*Section 5.7, Page 17:*

   The Maximum Reassembled Segment Size (MRSS, Kind=6) option is a 16-
   bit indicator of the largest reassembled UDP segment that can be
   received. MRSS is the UDP equivalent of IP's EMTU_R but the two are
   not related [RFC1122]. Using the FRAG option (Section 5.5), UDP
   segments can be transmitted as fragments in multiple IP datagrams
   and be reassembled larger than the IP layer allows.


*s/multiple IP datagrams/multiple complete IP datagrams/ ... the current
text agrees with the terminology in RFC 1122, but I think the addition
makes the text a bit clearer.*

*Also, if the capability to reassemble fragments is made optional, a
sentence should be added to this section stipulating that the presence of
the MRSS option indicates that the sender has that capability. This will
allow (e.g.) a DNS client to safely signal to a DNS server that a response
may be sent using UDP fragmentation, and it will tell the server how large
a reply using that mechanism could be. A server that does not have the
capability to send fragmented UDP datagrams -- including a server that does
not support UDP options at all -- would send a conventional UDP response.*

*Section 5.8, Pages 17-18:*

   UNSAFE options are an extended option space, with its own additional
   option types. These are indicated in the first byte after the option
   Kind as shown in Figure 15, which is followed by the Length. Length
   is 1 byte for UKinds whose total length (including Kind, UKind, and
   Length fields) is less than 255 or 2 bytes for larger lengths (in
   the similar style as the extended option format).

                        +--------+--------+--------+
                        | Kind=7 | UKind  | Length |...
                        +--------+--------+--------+
                          1 byte   1 byte  1-2 bytes

                   Figure 15   UDP UNSAFE option format



*IMO it would have been preferable to use a bit (e.g., the MSB) in the
option kind for this purpose. The UNSAFE option as specified will
accomplish the purpose, but it has a more complex encoding with no obvious
advantage. In any case, shouldn't the length be either 1 byte or 3 bytes,
as outlined in  Section 4?*

   >> UNSAFE options MUST be used only as part of UDP fragments, used
   either per-fragment or after reassembly.


*This appears to contradict the wording in  Section 5.5 that "UDP options
MUST NOT follow the FRAG header in non-terminal fragments." It may be
useful to allow per-fragment options other than NOP, OCS, AE, and FRAG, but
I must admit that I cannot think of an example offhand.*

*Section 5.10, Pages 19-20:*

   The Authentication and Encryption (AE) option is intended to allow
   UDP to provide a similar type of authentication as the TCP
   Authentication Option (TCP-AO) [RFC5925]. AE the conventional UDP

   payload and may also cover the surplus area, depending on
   configuration.



*s/AE the/AE covers the/*

   >> Packets with incorrect AE HMACs MUST be passed to the application
   by default, e.g., with a flag indicating AE failure.

   Like all non-UNSAFE UDP options, AE needs to be silently ignored
   when failing. This silently-ignored behavior ensures that option-
   aware receivers operate the same as legacy receivers unless
   overridden.


*Why isn't AE an UNSAFE option? Ignoring the option would lead to accepting
unauthenticated data or accepting cipher text as plaintext. IMO neither of
these outcomes is acceptable, and both are avoidable. In addition, this
section needs to specify whether this option is per-fragment, per complete
UDP datagram, or either, depending on configuration. My sense is that **AE
is most naturally a per-fragment option, and that a per-datagram non-UNSAFE
version is not really needed. That most closely follows the TCP-AO model.*

*Section 5.12, Page 21:*

               +----------+----------+----------+----------+
               | Kind=254 |   Len    |      UDP ExID       |
               +----------+----------+----------+----------+
               |  (option contents, as defined)...         |
               +----------+----------+----------+----------+

                     Figure 19   UDP EXP option format


*Don't we also need to document this format too?*

               +----------+----------+----------+----------+
               | Kind=254 |   255    |         Len         |
               +----------+----------+----------+----------+
               |      UDP ExID       |(cont.,as defined)...|
               +----------+----------+----------+----------+

                     Figure 20   UDP EXP option format


*Section 6, Pages 22-23:*

   The UDP option Kind space allows for the definition of new options,
   however the currently defined options do not allow for arbitrary new
   options. For example, FRAG needs to come first if present; new
   options cannot declare that they need to precede it. The following
   is a summary of rules for new options and their rationales:


*Allowance should be made for OCS and NOP to precede FRAG if the alternate
FRAG proposal is adopted.*

   >> New options MUST NOT depend on option space content, excepting
   only those contained within the UNSAFE option. Only OCS and AE
   depend on the content of the options themselves and their order is
   fixed (on transmission, AE is computed first using a zero-checksum
   OCS if present, and OCS is computed last before transmission, over
   the entire option area, including AE).

   >> UNSAFE options can both depend on and vary option space content
   because they are contained only inside UDP fragments and thus are
   processed only by UDP option capable receivers.


*UNSAFE options cannot depend on option or modify option content if AE and
OCS are to work predictably. IMO the complete ban on such dependence
(except for OCS and AE) that appears in previous drafts is the right way to
go and should be reinstated.*

   Note that only certain of the initially defined options violate
   these rules:

   o  >> FRAG MUST be first, if present, and MUST be processed when
      encountered (e.g., even before security options).

   o  >> Only FRAG and UNSAFE options are permitted to modify the UDP
      body or option areas.


   o  >> OCS SHOULD be the first option, except in the presence of
      FRAG, in which case it SHOULD be the first option after FRAG.


*See above.*

*Section 7, Page 23:*

   >> All options MUST be processed by receivers in the order
   encountered in the options list.


*It is possible to process OCS before the options area is parsed by
calculating the Internet checksum of the surplus area with the surplus
length pseudo-header. That does not in any way depend on where the OCS
option is located. A check of OCS before processing the surplus area should
be both allowed and encouraged. I personally would not countenance an
implementation that did anything else.*

*Section 10, Page 26:*

   The UDP FRAG options option supports a similar service to UDP-Lite.


*The statement that a service like UDP-Lite is offered has to go, it is
untrue. I recommend deleting this entire section as it has been overtaken
by events.*

*Section 15, Page 29:*

   ROHC compresses UDP headers only when this match succeeds. It does
   not prohibit UDP headers where the match fails; in those cases, ROHC
   default rules (Section 5.10) would cause the UDP header to remain
   uncompressed. Upon receivep of a compressed UDP header, Section
   A.1.3 of that document indicates that the UDP length is "INFERRED";
   in uncompressed packets, it would simply be explicitly provided.


*s/receivep/receipt/ (typo).*

*Section 17, Page 30:*

   [ . . . ] Transport security is provided in TCP by the TCP
   Authentication Option (TCP-AO [RFC5925]) or in UDP by the
   Authentication Extension option (Section 5.10). Transport headers
   are also protected as payload when using IP security (IPsec)
   [RFC4301].


*s/Authentication Extension option/Authentication and Encryption option/*

*Thanks for reading to the end. Please look at the upcoming missive on an
alternative version of FRAG if that subject is of interest.*

*Mike Heard*