draft-ietf-tsvwg-udp-options-11.txt   draft-ietf-tsvwg-udp-options-12.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Independent consultant Internet Draft Independent consultant
Intended status: Standards Track May 2, 2021 Intended status: Standards Track May 2, 2021
Intended updates: 768 Intended updates: 768
Expires: November 2021 Expires: November 2021
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-11.txt draft-ietf-tsvwg-udp-options-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Background.....................................................3 3. Background.....................................................3
4. The UDP Option Area............................................4 4. The UDP Option Area............................................4
5. UDP Options....................................................8 5. UDP Options....................................................8
5.1. End of Options List (EOL).................................9 5.1. End of Options List (EOL).................................9
5.2. No Operation (NOP).......................................10 5.2. No Operation (NOP).......................................10
5.3. Option Checksum (OCS)....................................10 5.3. Option Checksum (OCS)....................................10
5.4. Alternate Checksum (ACS).................................12 5.4. Alternate Checksum (ACS).................................12
5.5. Fragmentation (FRAG).....................................13 5.5. Fragmentation (FRAG).....................................13
5.6. Maximum Segment Size (MSS)...............................17 5.6. Maximum Segment Size (MSS)...............................16
5.7. Maximum Reassembled Segment Size (MRSS)..................17 5.7. Maximum Reassembled Segment Size (MRSS)..................17
5.8. Unsafe (UNSAFE)..........................................18 5.8. Unsafe (UNSAFE)..........................................17
5.9. Timestamps (TIME)........................................19 5.9. Timestamps (TIME)........................................18
5.10. Authentication and Encryption (AE)......................20 5.10. Authentication and Encryption (AE)......................19
5.11. Echo request (REQ) and echo response (RES)..............21 5.11. Echo request (REQ) and echo response (RES)..............21
5.12. Experimental (EXP)......................................21 5.12. Experimental (EXP)......................................21
6. Rules for designing new options...............................22 6. Rules for designing new options...............................22
7. Option inclusion and processing...............................23 7. Option inclusion and processing...............................23
8. UDP API Extensions............................................25 8. UDP API Extensions............................................24
9. Whose options are these?......................................25 9. Whose options are these?......................................25
10. UDP options FRAG option vs. UDP-Lite.........................26 10. UDP options FRAG option vs. UDP-Lite.........................26
11. Interactions with Legacy Devices.............................27 11. Interactions with Legacy Devices.............................26
12. Options in a Stateless, Unreliable Transport Protocol........27 12. Options in a Stateless, Unreliable Transport Protocol........27
13. UDP Option State Caching.....................................28 13. UDP Option State Caching.....................................28
14. Updates to RFC 768...........................................28 14. Updates to RFC 768...........................................28
15. Interactions with other RFCs (and drafts)....................28 15. Interactions with other RFCs (and drafts)....................28
16. Multicast Considerations.....................................30 16. Multicast Considerations.....................................29
17. Security Considerations......................................30 17. Security Considerations......................................30
18. IANA Considerations..........................................31 18. IANA Considerations..........................................31
19. References...................................................32 19. References...................................................31
19.1. Normative References....................................32 19.1. Normative References....................................31
19.2. Informative References..................................32 19.2. Informative References..................................32
20. Acknowledgments..............................................34 20. Acknowledgments..............................................34
Appendix A. Implementation Information...........................36 Appendix A. Implementation Information...........................35
1. Introduction 1. Introduction
Transport protocols use options as a way to extend their Transport protocols use options as a way to extend their
capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340]
include space for these options but UDP [RFC768] currently does not. include space for these options but UDP [RFC768] currently does not.
This document defines an extension to UDP that provides space for This document defines an extension to UDP that provides space for
transport options including their generic syntax and semantics for transport options including their generic syntax and semantics for
their use in UDP's stateless, unreliable message protocol. their use in UDP's stateless, unreliable message protocol.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
Figure 7 UDP NOP option format Figure 7 UDP NOP option format
>> If options longer than one byte are used, NOP options SHOULD be >> If options longer than one byte are used, NOP options SHOULD be
used at the beginning of the UDP options area to achieve alignment used at the beginning of the UDP options area to achieve alignment
as would be more efficient for active (i.e., non-NOP) options. as would be more efficient for active (i.e., non-NOP) options.
>> Segments SHOULD NOT use more than three consecutive NOPs. NOPs >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs
are intended to assist with alignment, not other padding or fill. are intended to assist with alignment, not other padding or fill.
[NOTE: Tom Herbert suggested we declare "more than 3 consecutive This issue is discussed further in Section 17.
NOPs" a fatal error to reduce the potential of using NOPs as a DOS
attack, but IMO there are other equivalent ways (e.g., using
RESERVED or other UNASSIGNED values) and the "no more than 3"
creates its own DOS vulnerability)
5.3. Option Checksum (OCS) 5.3. Option Checksum (OCS)
The Option Checksum (OCS) option is conventional Internet checksum The Option Checksum (OCS) option is conventional Internet checksum
[RFC791] that covers all of the surplus area and a pseudoheader [RFC791] that covers all of the surplus area and a pseudoheader
composed of the 16-bit length of the surplus area (Figure 8). The composed of the 16-bit length of the surplus area (Figure 8). The
primary purpose of OCS is to detect non-standard (i.e., non-option) primary purpose of OCS is to detect non-standard (i.e., non-option)
uses of that area. The surplus area pseudoheader is included to uses of that area. The surplus area pseudoheader is included to
enable traversal of errant middleboxes that incorrectly compute the enable traversal of errant middleboxes that incorrectly compute the
UDP checksum over the entire IP payload rather than only the UDP UDP checksum over the entire IP payload rather than only the UDP
skipping to change at page 16, line 43 skipping to change at page 16, line 39
followed by the per-fragment options, with the final option being followed by the per-fragment options, with the final option being
the FRAG option followed by the FRAG data chunk. the FRAG option followed by the FRAG data chunk.
The last chunk includes the non-FRAG options noted in step #1 The last chunk includes the non-FRAG options noted in step #1
after the end of the FRAG data. These UDP options apply to the after the end of the FRAG data. These UDP options apply to the
reassembled data as a whole when received. reassembled data as a whole when received.
5. Process the UDP options of each fragment, e.g., computing its 5. Process the UDP options of each fragment, e.g., computing its
OCS. OCS.
<<TBD: decide whether it is useful to encode fragments so they can
be zero-copied>>
Receivers reverse the above sequence. They process all received Receivers reverse the above sequence. They process all received
options in each fragment. When the FRAG option is encountered, the options in each fragment. When the FRAG option is encountered, the
FRAG data is used in reassembly. After all fragments are received, FRAG data is used in reassembly. After all fragments are received,
the entire packet is processed with any trailing UDP options the entire packet is processed with any trailing UDP options
applying to the reassembled data. applying to the reassembled data.
5.6. Maximum Segment Size (MSS) 5.6. Maximum Segment Size (MSS)
The Maximum Segment Size (MSS, Kind = 5) option is a 16-bit hint of The Maximum Segment Size (MSS, Kind = 5) option is a 16-bit hint of
the largest unfragmented UDP segment that an endpoint believes can the largest unfragmented UDP segment that an endpoint believes can
skipping to change at page 27, line 39 skipping to change at page 27, line 24
This feature is also inconsistent with the UDP application interface This feature is also inconsistent with the UDP application interface
[RFC768] [RFC1122]. [RFC768] [RFC1122].
It has been reported that Alcatel-Lucent's "Brick" Intrusion It has been reported that Alcatel-Lucent's "Brick" Intrusion
Detection System has a default configuration that interprets Detection System has a default configuration that interprets
inconsistencies between UDP Length and IP Length as an attack to be inconsistencies between UDP Length and IP Length as an attack to be
reported. Note that other firewall systems, e.g., CheckPoint, use a reported. Note that other firewall systems, e.g., CheckPoint, use a
default "relaxed UDP length verification" to avoid falsely default "relaxed UDP length verification" to avoid falsely
interpreting this inconsistency as an attack. interpreting this inconsistency as an attack.
(TBD: test with UDP checksum offload and UDP fragmentation offload)
12. Options in a Stateless, Unreliable Transport Protocol 12. Options in a Stateless, Unreliable Transport Protocol
There are two ways to interpret options for a stateless, unreliable There are two ways to interpret options for a stateless, unreliable
protocol -- an option is either local to the message or intended to protocol -- an option is either local to the message or intended to
affect a stream of messages in a soft-state manner. Either affect a stream of messages in a soft-state manner. Either
interpretation is valid for defined UDP options. interpretation is valid for defined UDP options.
It is impossible to know in advance whether an endpoint supports a It is impossible to know in advance whether an endpoint supports a
UDP option. UDP option.
skipping to change at page 28, line 25 skipping to change at page 28, line 9
The above requirements prevent using any option that cannot be The above requirements prevent using any option that cannot be
safely ignored unless it is hidden inside the FRAG area (i.e., safely ignored unless it is hidden inside the FRAG area (i.e.,
UNSAFE options). Legacy systems also always need to be able to UNSAFE options). Legacy systems also always need to be able to
interpret the transport payload fragments as individual transport interpret the transport payload fragments as individual transport
datagrams. datagrams.
13. UDP Option State Caching 13. UDP Option State Caching
Some TCP connection parameters, stored in the TCP Control Block, can Some TCP connection parameters, stored in the TCP Control Block, can
be usefully shared either among concurrent connections or between be usefully shared either among concurrent connections or between
connections in sequence, known as TCP Sharing [RFC2140][To20cb]. connections in sequence, known as TCP Sharing [RFC2140][To21cb].
Although UDP is stateless, some of the options proposed herein may Although UDP is stateless, some of the options proposed herein may
have similar benefit in being shared or cached. We call this UCB have similar benefit in being shared or cached. We call this UCB
Sharing, or UDP Control Block Sharing, by analogy. Sharing, or UDP Control Block Sharing, by analogy. Just as TCB
sharing is not a standard because it is consistent with existing TCP
[TBD: extend this section to indicate which options MAY vs. MUST NOT specifications, UCB sharing would be consistent with existing UDP
be shared and how, e.g., along the lines of To20cb] specifications, including this one. Both are implementation issues
that are outside the scope of their respective specifications, and
so UCB sharing is outside the scope of this document.
14. Updates to RFC 768 14. Updates to RFC 768
This document updates RFC 768 as follows: This document updates RFC 768 as follows:
o This document defines the meaning of the IP payload area beyond o This document defines the meaning of the IP payload area beyond
the UDP length but within the IP length. the UDP length but within the IP length.
o This document extends the UDP API to support the use of options. o This document extends the UDP API to support the use of options.
skipping to change at page 30, line 20 skipping to change at page 30, line 7
UDP options are primarily intended for unicast use. Using these UDP options are primarily intended for unicast use. Using these
options over multicast IP requires careful consideration, e.g., to options over multicast IP requires careful consideration, e.g., to
ensure that the options used are safe for different endpoints to ensure that the options used are safe for different endpoints to
interpret differently (e.g., either to support or silently ignore) interpret differently (e.g., either to support or silently ignore)
or to ensure that all receivers of a multicast group confirm support or to ensure that all receivers of a multicast group confirm support
for the options in use. for the options in use.
17. Security Considerations 17. Security Considerations
There are a number of security issues raised by the introduction of
options to UDP. Some are specific to this variant, but others are
associated with any packet processing mechanism; all are discussed
in this section further.
The use of UDP packets with inconsistent IP and UDP Length fields The use of UDP packets with inconsistent IP and UDP Length fields
has the potential to trigger a buffer overflow error if not properly has the potential to trigger a buffer overflow error if not properly
handled, e.g., if space is allocated based on the smaller field and handled, e.g., if space is allocated based on the smaller field and
copying is based on the larger. However, there have been no reports copying is based on the larger. However, there have been no reports
of such vulnerability and it would rely on inconsistent use of the of such vulnerability and it would rely on inconsistent use of the
two fields for memory allocation and copying. two fields for memory allocation and copying.
UDP options are not covered by DTLS (datagram transport-layer UDP options are not covered by DTLS (datagram transport-layer
security). Despite the name, neither TLS [RFC8446] (transport layer security). Despite the name, neither TLS [RFC8446] (transport layer
security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the
skipping to change at page 30, line 48 skipping to change at page 30, line 40
[RFC4301]. [RFC4301].
UDP options use the TLV syntax similar to that of TCP. This syntax UDP options use the TLV syntax similar to that of TCP. This syntax
is known to require serial processing and may pose a DOS risk, e.g., is known to require serial processing and may pose a DOS risk, e.g.,
if an attacker adds large numbers of unknown options that must be if an attacker adds large numbers of unknown options that must be
parsed in their entirety. Implementations concerned with the parsed in their entirety. Implementations concerned with the
potential for this vulnerability MAY implement only the required potential for this vulnerability MAY implement only the required
options and MAY also limit processing of TLVs. Because required options and MAY also limit processing of TLVs. Because required
options come first and at most once each (with the exception of options come first and at most once each (with the exception of
NOPs, which should never need to come in sequences of more than NOPs, which should never need to come in sequences of more than
three in a row), this limits their DOS impact. three in a row), this limits their DOS impact. Note that TLV formats
for options does require serial processing, but any format that
allows future options, whether ignored or not, could introduce a
similar DOS vulnerability.
UDP security should never rely solely on transport layer processing UDP security should never rely solely on transport layer processing
of options. UNSAFE options are the only type that share fate with of options. UNSAFE options are the only type that share fate with
the UDP data, because of the way that data is hidden in the surplus the UDP data, because of the way that data is hidden in the surplus
area until after those options are processed. All other options area until after those options are processed. All other options
default to being silently ignored at the transport layer but may be default to being silently ignored at the transport layer but may be
dropped either if that default is overridden (e.g., by dropped either if that default is overridden (e.g., by
configuration) or discarded at the application layer (e.g., using configuration) or discarded at the application layer (e.g., using
information about the options processed that are passed along with information about the options processed that are passed along with
the packet). the packet).
skipping to change at page 34, line 37 skipping to change at page 34, line 26
Compression and Fragmentation," RFC 8724, Apr. 2020. Compression and Fragmentation," RFC 8724, Apr. 2020.
[RFC8899] Fairhurst, G., T. Jones, M. Tuxen, I. Rungeler, T. Volker, [RFC8899] Fairhurst, G., T. Jones, M. Tuxen, I. Rungeler, T. Volker,
"Packetization Layer Path MTU Discovery for Datagram "Packetization Layer Path MTU Discovery for Datagram
Transports," RFC 8899, Sep. 2020. Transports," RFC 8899, Sep. 2020.
[To18ao] Touch, J., "A TCP Authentication Option Extension for [To18ao] Touch, J., "A TCP Authentication Option Extension for
Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. Payload Encryption," draft-touch-tcp-ao-encrypt, Jul.
2018. 2018.
[To20cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block [To21cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block
Interdependence," draft-touch-tcpm-2140bis, Apr. 2020. Interdependence," draft-touch-tcpm-2140bis, Apr. 2021.
20. Acknowledgments 20. Acknowledgments
This work benefitted from feedback from Bob Briscoe, Ken Calvert, This work benefitted from feedback from Bob Briscoe, Ken Calvert,
Ted Faber, Gorry Fairhurst (including OCS for misbehaving middlebox Ted Faber, Gorry Fairhurst (including OCS for misbehaving middlebox
traversal), C. M. Heard (including combining previous FRAG and LITE traversal), C. M. Heard (including combining previous FRAG and LITE
options into the new FRAG), Tom Herbert, Mark Smith, and Raffaele options into the new FRAG), Tom Herbert, Mark Smith, and Raffaele
Zullo, as well as discussions on the IETF TSVWG and SPUD email Zullo, as well as discussions on the IETF TSVWG and SPUD email
lists. lists.
 End of changes. 16 change blocks. 
29 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/