draft-ietf-tsvwg-udp-options-06.txt   draft-ietf-tsvwg-udp-options-07.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Independent consultant Internet Draft Independent consultant
Intended status: Standards Track March 5, 2019 Intended status: Standards Track March 8, 2019
Intended updates: 768 Intended updates: 768
Expires: September 2019 Expires: September 2019
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-06.txt draft-ietf-tsvwg-udp-options-07.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 1, line 35 skipping to change at page 1, line 35
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 5, 2019. This Internet-Draft will expire on September 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
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....................................................7 5. UDP Options....................................................7
5.1. End of Options List (EOL).................................8 5.1. End of Options List (EOL).................................8
5.2. No Operation (NOP)........................................9 5.2. No Operation (NOP)........................................9
5.3. Option Checksum (OCS).....................................9 5.3. Option Checksum (OCS).....................................9
5.4. Alternate Checksum (ACS).................................10 5.4. Alternate Checksum (ACS).................................11
5.5. Lite (LITE)..............................................11 5.5. Lite (LITE)..............................................11
5.6. Maximum Segment Size (MSS)...............................13 5.6. Maximum Segment Size (MSS)...............................13
5.7. Fragmentation (FRAG).....................................14 5.7. Fragmentation (FRAG).....................................14
5.8. Coupling FRAG with LITE..................................16 5.8. Coupling FRAG with LITE..................................16
5.9. Timestamps (TIME)........................................17 5.9. Timestamps (TIME)........................................17
5.10. Authentication and Encryption (AE)......................18 5.10. Authentication and Encryption (AE)......................18
6. Echo request (REQ) and echo response (RES)....................19 6. Echo request (REQ) and echo response (RES)....................19
6.1. Experimental (EXP).......................................19 6.1. Experimental (EXP).......................................19
7. Rules for designing new options...............................19 7. Rules for designing new options...............................20
8. Option inclusion and processing...............................20 8. Option inclusion and processing...............................21
9. UDP API Extensions............................................22 9. UDP API Extensions............................................23
10. Whose options are these?.....................................22 10. Whose options are these?.....................................23
11. UDP options LITE option vs. UDP-Lite.........................23 11. UDP options LITE option vs. UDP-Lite.........................24
12. Interactions with Legacy Devices.............................24 12. Interactions with Legacy Devices.............................25
13. Options in a Stateless, Unreliable Transport Protocol........24 13. Options in a Stateless, Unreliable Transport Protocol........25
14. UDP Option State Caching.....................................25 14. UDP Option State Caching.....................................26
15. Updates to RFC 768...........................................25 15. Updates to RFC 768...........................................26
16. Multicast Considerations.....................................25 16. Multicast Considerations.....................................26
17. Security Considerations......................................26 17. Security Considerations......................................27
18. IANA Considerations..........................................26 18. IANA Considerations..........................................27
19. References...................................................27 19. References...................................................28
19.1. Normative References....................................27 19.1. Normative References....................................28
19.2. Informative References..................................27 19.2. Informative References..................................28
20. Acknowledgments..............................................29 20. Acknowledgments..............................................30
Appendix A. Implementation Information...........................30 Appendix A. Implementation Information...........................31
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 experimental extension to UDP that provides This document defines an experimental extension to UDP that provides
space for transport options including their generic syntax and space for transport options including their generic syntax and
semantics for their use in UDP's stateless, unreliable message semantics for their use in UDP's stateless, unreliable message
protocol. protocol.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
attack, but IMO there are other equivalent ways (e.g., using attack, but IMO there are other equivalent ways (e.g., using
RESERVED or other UNASSIGNED values) and the "no more than 3" RESERVED or other UNASSIGNED values) and the "no more than 3"
creates its own DOS vulnerability) creates its own DOS vulnerability)
5.3. Option Checksum (OCS) 5.3. Option Checksum (OCS)
The Option Checksum (OCS) is conventional Internet checksum that The Option Checksum (OCS) is conventional Internet checksum that
covers all of the UDP options. The primary purpose of OCS is to covers all of the UDP options. The primary purpose of OCS is to
detect non-standard (i.e., non-option) uses of the options area. detect non-standard (i.e., non-option) uses of the options area.
OCS is calculated by computing the ones-complement of the 8-bit OCS is calculated by computing the Internet checksum options area
ones-complement checksum (i.e., Internet checksum) sum of the [RFC1071]. OCS protects the option area from errors in a similar way
options area. OCS protects the option area from errors in a similar that the UDP checksum protects the UDP user data (when not zero).
way that the UDP checksum protects the UDP user data (when not
zero).
+--------+--------+ +--------+--------+
| Kind=2 |checksum| | Kind=2 |checksum|
+--------+--------+ +--------+--------+
Figure 7 UDP OCS option format Figure 7 UDP OCS option format
>> When present, the option checksum SHOULD occur as early as >> When present, the option checksum SHOULD occur as early as
possible, preferably preceded by only NOP options for alignment and possible, preceded by only NOP options for alignment and the LITE
the LITE option if present. option if present.
>> OCS SHOULD be half-word aligned to the start of the UDP packet. >> The OCS checksum MUST be half-word coordinated with the start of
This is to help ensure that the option, together with the other the UDP options area.
options, result in an overall zero ones-complement sum, which may
help the UDP options traverse devices that incorrectly attempt to
checksum the surplus area (as originally proposed as the Checksum
Compensation Option [Fa18]).
OCS covers the UDP option area, including the Lite option as This coordination is accomplished by computing the Internet checksum
formatted before swapping (or relocation) for transmission (or, over the UDP options area (including EOL, if present) and then
equivalently, after the swap/relocation after reception). adjusting the result before storing it into the OCS checksum field.
If that field is aligned to the start of the options area, then the
checksum is inserted as-is, otherwise the checksum bytes are swapped
before inserting them into the field.
>> If the option checksum fails, all options MUST be ignored and any The adjustment above helps enable that OCS, together with the other
trailing surplus data (and Lite data, if used) silently discarded. options, result in an overall zero ones-complement sum. This feature
is intended to potentially help the UDP options traverse devices
that incorrectly attempt to checksum the surplus area (as originally
proposed as the Checksum Compensation Option, i.e., CCO [Fa18]).
Note that this incorrect checksum traversal feature is defeated by
the use of LITE, whether alone or with FRAG, because the LITE area
is deliberately not covered by OCS. It also is defeated by the use
of a zero UDP checksum (i.e., UDP checksum disabled).
OCS covers the UDP option area, including the Lite option (but not
LITE data area) as formatted before swapping (or relocation) for
transmission (or, equivalently, after the swap/relocation after
reception), as the LITE option would occur at the beginning of the
original (prior to rearrangement for transmission) or restored
(after rearrangement upon reception) UDP option area.
>> If OCS fails, all options MUST be ignored and any trailing
surplus data (and Lite data, if used) silently discarded.
>> UDP data that is validated by a correct UDP checksum MUST be >> UDP data that is validated by a correct UDP checksum MUST be
delivered to the application layer, even if the UDP option checksum delivered to the application layer, even if OCS fails, unless the
fails, unless the endpoints have negotiated otherwise for this endpoints have negotiated otherwise for this segment's socket pair.
segment's socket pair.
Note that use of the UDP checksum is optional. When not used, the As a reminder, use of the UDP checksum is optional. When not used,
field is zero, where it is also assumed to be "correct" for these i.e., when the field is zero, that checksum is assumed to be
purposes. "correct" for the purpose of accepting UDP packets at a receiver.
Note also that OCS is intended to check for accidental errors, not OCS is intended to check for accidental errors, not for attacks.
for attacks.
5.4. Alternate Checksum (ACS) 5.4. Alternate Checksum (ACS)
The Alternate Checksum (ACS) provides a stronger alternative to the The Alternate Checksum (ACS) provides a stronger alternative to the
checksum in the UDP header, using a 16-bit CRC of the conventional checksum in the UDP header, using a 16-bit CRC of the conventional
UDP payload only (excluding the IP pseudoheader, UDP header, and UDP UDP payload only (excluding the IP pseudoheader, UDP header, and UDP
options, and not include the LITE area). Because it does not include options, and not include the LITE area). Because it does not include
the IP pseudoheader or UDP header, it need not be updated by NATs the IP pseudoheader or UDP header, it need not be updated by NATs
when IP addresses or UDP ports are rewritten. Its purpose is to when IP addresses or UDP ports are rewritten. Its purpose is to
detect errors that the UDP checksum, when used, might not detect. detect errors that the UDP checksum, when used, might not detect.
skipping to change at page 17, line 35 skipping to change at page 18, line 5
TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar
manner to the TCP TS option [RFC7323]. On transmitted segments using manner to the TCP TS option [RFC7323]. On transmitted segments using
the option, TS Value is always set based on the local "time" value. the option, TS Value is always set based on the local "time" value.
Received TSval and TSecr values are provided to the application, Received TSval and TSecr values are provided to the application,
which can pass the TSval value to be used as TSecr on UDP messages which can pass the TSval value to be used as TSecr on UDP messages
sent in response (i.e., to echo the received TSval). A received sent in response (i.e., to echo the received TSval). A received
TSecr of zero indicates that the TSval was not echoed by the TSecr of zero indicates that the TSval was not echoed by the
transmitter, i.e., from a previously received UDP packet. transmitter, i.e., from a previously received UDP packet.
>> UDP MAY use an RTT estimate based on nonzero Timestamp values as >> TIME MAY use an RTT estimate based on nonzero Timestamp values as
a hint for fragmentation reassembly, rate limiting, or other a hint for fragmentation reassembly, rate limiting, or other
mechanisms that benefit from such an estimate. mechanisms that benefit from such an estimate.
>> UDP SHOULD make this RTT estimate available to the user >> TIME SHOULD make this RTT estimate available to the user
application. application.
These UDP timestamps are modeled after TCP timestamps and have UDP timestamps are modeled after TCP timestamps and have similar
similar expectations. In particular, they are expected to be: expectations. In particular, they are expected to be:
o Values are monotonic and non-decreasing o Values are monotonic and non-decreasing
o Values should increase according to a typical 'tick' time o Values should increase according to a typical 'tick' time
o A request is defined as "reply=0" and a reply is defined as both o A request is defined as "reply=0" and a reply is defined as both
fields being non-zero. fields being non-zero.
o A receiver should always respond to a request with the highest o A receiver should always respond to a request with the highest
TSval received, which is not necessarily the most recently TSval received, which is not necessarily the most recently
received. received.
5.10. Authentication and Encryption (AE) 5.10. Authentication and Encryption (AE)
The Authentication and Encryption option (AE) is intended to allow The Authentication and Encryption option (AE) is intended to allow
UDP to provide a similar type of authentication as the TCP UDP to provide a similar type of authentication as the TCP
Authentication Option (TCP-AO) [RFC5925]. It uses the same format as Authentication Option (TCP-AO) [RFC5925]. It uses the same format as
specified for TCP-AO, except that it uses a Kind of 8. UDP-AO specified for TCP-AO, except that it uses a Kind of 8. AE supports
supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- NAT traversal in a similar manner as TCP-AO [RFC6978]. AE can also
AO can also be extended to provide a similar encryption capability be extended to provide a similar encryption capability as TCP-AO-
as TCP-AO-ENC, in a similar manner [To18ao]. For these reasons, the ENC, in a similar manner [To18ao].
option is known as UDP-AE.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=8 | Len | Digest... | | Kind=8 | Len | Digest... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Digest (con't)... | | Digest (con't)... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 19 UDP non-terminal FRAG option format Figure 19 UDP AE option format
Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both Like TCP-AO, AE is not negotiated in-band. Its use assumes both
endpoints have populated Master Key Tuples (MKTs), used to exclude endpoints have populated Master Key Tuples (MKTs), used to exclude
non-protected traffic. non-protected traffic.
TCP-AO generates unique traffic keys from a hash of TCP connection TCP-AO generates unique traffic keys from a hash of TCP connection
parameters. UDP lacks a three-way handshake to coordinate parameters. UDP lacks a three-way handshake to coordinate
connection-specific values, such as TCP's Initial Sequence Numbers connection-specific values, such as TCP's Initial Sequence Numbers
(ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses (ISNs) [RFC793], thus AE's Key Derivation Function (KDF) uses zeroes
zeroes as the value for both ISNs. This means that the UDP-AE reuses as the value for both ISNs. This means that the AE reuses keys when
keys when socket pairs are reused, unlike TCP-AO. socket pairs are reused, unlike TCP-AO.
UDP-AE can be configured to either include or exclude UDP options, AE can be configured to either include or exclude UDP options, the
the same way as can TCP-AO. When UDP options are covered, the OCS same way as can TCP-AO. When UDP options are covered, the OCS option
option area checksum and UDP-AE hash areas are zeroed before area checksum and AE hash areas are zeroed before computing the AE
computing the UDP-AE hash. It is important to consider that options hash. It is important to consider that options not yet defined might
not yet defined might yield unpredictable results if not confirmed yield unpredictable results if not confirmed as supported, e.g., if
as supported, e.g., if they were to contain other hashes or they were to contain other hashes or checksums that depend on the
checksums that depend on the option area contents. This is why such option area contents. This is why such dependencies are not
dependencies are not permitted except as defined for OCS and UDP-AE. permitted except as defined for OCS and UDP-AE.
Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT Similar to TCP-AO-NAT, AE can be configured to support NAT
traversal, excluding one or both of the UDP ports [RFC6978]. traversal, excluding one or both of the UDP ports [RFC6978].
6. Echo request (REQ) and echo response (RES) 6. Echo request (REQ) and echo response (RES)
The echo request (REQ, kind=9) and echo response (RES, kind=10) The echo request (REQ, kind=9) and echo response (RES, kind=10)
options provide a means for UDP options to be used to provide options provide a means for UDP options to be used to provide
packet-level acknowledgements. Their use is described as part of the packet-level acknowledgements. Their use is described as part of the
UDP variant of packetization layer path MTU discovery (PLPMTUD) UDP variant of packetization layer path MTU discovery (PLPMTUD)
[Fa19]. The options both have the format indicated in Figure 20. [Fa19]. The options both have the format indicated in Figure 20.
+--------+--------+------------------+ +--------+--------+------------------+
| Kind | Len=6 | nonce | | Kind | Len=6 | nonce |
+--------+--------+------------------+ +--------+--------+------------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
Figure 20 Echo option format Figure 20 UDP REQ and RES options format
6.1. Experimental (EXP) 6.1. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP) is reserved for experiments [RFC3692].
It uses a Kind value of 254. Only one such value is reserved because It uses a Kind value of 254. Only one such value is reserved because
experiments are expected to use an Experimental ID (ExIDs) to experiments are expected to use an Experimental ID (ExIDs) to
differentiate concurrent use for different purposes, using UDP ExIDs differentiate concurrent use for different purposes, using UDP ExIDs
registered with IANA according to the approach developed for TCP registered with IANA according to the approach developed for TCP
experimental options [RFC6994]. experimental options [RFC6994].
skipping to change at page 20, line 5 skipping to change at page 20, line 25
identifier (similar to TCP ExIDs [RFC6994]). identifier (similar to TCP ExIDs [RFC6994]).
7. Rules for designing new options 7. Rules for designing new options
The UDP option Kind space allows for the definition of new options, The UDP option Kind space allows for the definition of new options,
however the currently defined options do not allow for arbitrary new however the currently defined options do not allow for arbitrary new
options. For example, LITE needs to come first if present; new options. For example, LITE needs to come first if present; new
options cannot declare that they need to precede it. The following options cannot declare that they need to precede it. The following
is a summary of rules for new options and their rationales: is a summary of rules for new options and their rationales:
>> New options MUST NOT depend on option space content. Only OCS, >> New options MUST NOT depend on option space content. Only OCS and
ACS, and AE depend on the content of the options themselves, and AE depend on the content of the options themselves and their order
their order is fixed (on transmission, AE is computed first using a is fixed (on transmission, AE is computed first using a zero-
zero-checksum OCS or ACS if present, and OCS or ACS is computed checksum OCS if present, and OCS is computed last before
second over the entire option area, including AE). transmission, over the entire option area, including AE).
>> New options MUST NOT declare their order relative to other >> New options MUST NOT declare their order relative to other
options, whether new or old. options, whether new or old.
>> New options MUST NOT modify content anywhere except within their >> At the sender, new options MUST NOT modify UDP packet content
option field; areas that need to remain unmodified include the IP anywhere except within their option field; areas that need to remain
header, IP options, the UDP body, the UDP option area (i.e., other unmodified include the IP header, IP options, the UDP body, the UDP
options), and the post-option area. option area (i.e., other options), and the post-option area.
>> Options MUST NOT be modified in transit. This includes those
already defined as well as new options. New options MUST NOT require
or intend optionally for modification of any UDP options, including
their new areas, in transit.
Note that only certain of the initially defined options violate Note that only certain of the initially defined options violate
these rules: these rules:
o >> LITE MUST be first, if present, and MUST be processed when o >> LITE MUST be first, if present, and MUST be processed when
encountered (e.g., even before security options). encountered (e.g., even before security options).
o >> LITE is the only option that modifies the UDP body or option o >> LITE is the only option that modifies the UDP body or option
areas. areas.
o >> OCS or ACS MUST be the first option, except in the presence of o >> OCS SHOULD be the first option, except in the presence of
LITE, in which case they MUST be the first option after LITE. LITE, in which case it SHOULD be the first option after LITE.
o >> OCS and ACS MUST be processed by receivers when encountered in
the options list.
o >> AE MUST be processed by receivers when encountered in the
options list.
8. Option inclusion and processing 8. Option inclusion and processing
The following rules apply to option inclusion by senders and The following rules apply to option inclusion by senders and
processing by receivers. processing by receivers.
>> Senders MAY add any option, as configured by the API. >> Senders MAY add any option, as configured by the API.
>> All mandatory options MUST be processed by receivers, if present >> All mandatory options MUST be processed by receivers, if present
(presuming UDP options are supported at that receiver). (presuming UDP options are supported at that receiver).
>> Non-mandatory options MAY be ignored by receivers, if present, >> Non-mandatory options MAY be ignored by receivers, if present,
based on API settings. based on API settings.
>> All options MUST be processed by receivers in the order
encountered in the options list.
The basic premise is that the sender decides what options to add and The basic premise is that the sender decides what options to add and
the receiver decides what options to handle. Simply adding an option the receiver decides what options to handle. Simply adding an option
does not force work upon a receiver, with the exception of the does not force work upon a receiver, with the exception of the
mandatory options. mandatory options.
Upon receipt, the receiver checks various properties of the UDP Upon receipt, the receiver checks various properties of the UDP
packet and its options to decide whether to accept or drop the packet and its options to decide whether to accept or drop the
packet and whether to accept or ignore some its options as follows packet and whether to accept or ignore some its options as follows
(in order): (in order):
if the UDP checksum fails then if the UDP checksum fails then
silently drop (per RFC1122) silently drop (per RFC1122)
if the UDP checksum passes then if the UDP checksum passes then
if OCS is present and fails then if OCS is present and fails then
deliver the UDP payload but ignore all options deliver the UDP payload but ignore all options
(this is required to emulate legacy behavior) (this is required to emulate legacy behavior)
if OCS is present and passes then if OCS is present and passes then
deliver the UDP payload after parsing deliver the UDP payload after parsing
and processing the rest of the options and processing the rest of the options
if both sender and receiver choose to use ACS then (for other options 'OPT' when encountered in sequence):
if ACS passes then if both sender and receiver choose to use OPT then
if OPT passes then
deliver the UDP payload after parsing deliver the UDP payload after parsing
and processing the rest of the options and processing the rest of the options
if ACS fails then if OPT fails then
silently drop the packet silently drop the packet
if ACS is not present when received then if OPT is not present when received then
silently drop the packet silently drop the packet
if the sender includes OPT
if the sender includes ACS and the receiver does not indicate OPT is required then
and the receiver does not indicate ACS is required then
the receiver accepts all UDP payloads that pass the receiver accepts all UDP payloads that pass
the UDP checksum and indicate for each packet the UDP checksum and indicate for each packet
whether ACS succeeded, but never drop when ACS fails whether OPT succeeded, but never drop when OPT fails
I.e., ACS should be treated like any other option, in that the I.e., all options other than OCS are treated the same, in that the
transmitter can add it as desired and the receiver has the option to transmitter can add it as desired and the receiver has the option to
require it or not. Only if it is required (by API configuration) require it or not. Only if it is required (by API configuration)
should the receiver require it being present and correct. should the receiver require it being present and correct.
I.e., for all options other than OCS: I.e., for all options other than OCS:
o if the option is not required by the receiver, then packets o if the option is not required by the receiver, then packets
missing the option are accepted. missing the option are accepted.
o if the option is required and missing or incorrectly formed, o if the option is required and missing or incorrectly formed,
skipping to change at page 23, line 23 skipping to change at page 24, line 15
field to indicate the boundary between data covered by the transport field to indicate the boundary between data covered by the transport
checksum and data not covered, and so there is no remaining area checksum and data not covered, and so there is no remaining area
where the length of the UDP-Lite payload as a whole can be indicated where the length of the UDP-Lite payload as a whole can be indicated
[RFC3828]. [RFC3828].
UDP options are intended for use only by the transport endpoints. UDP options are intended for use only by the transport endpoints.
They are no more (or less) appropriate to be modified in-transit They are no more (or less) appropriate to be modified in-transit
than any other portion of the transport datagram. than any other portion of the transport datagram.
UDP options are transport options. Generally, transport datagrams UDP options are transport options. Generally, transport datagrams
are not intended to be modified in-transit. However, the UDP option are not intended to be modified in-transit. UDP options are no
mechanism provides no specific protection against in-transit exception and here are specified as "MUST NOT" be altered in
modification of the UDP header, UDP payload, or UDP option area, transit. However, the UDP option mechanism provides no specific
except as provided by the options selected (e.g., OCS, ACS, or AE). protection against in-transit modification of the UDP header, UDP
payload, or UDP option area, except as provided by the options
selected (e.g., OCS or AE).
11. UDP options LITE option vs. UDP-Lite 11. UDP options LITE option vs. UDP-Lite
UDP-Lite provides partial checksum coverage, so that packets with UDP-Lite provides partial checksum coverage, so that packets with
errors in some locations can be delivered to the user [RFC3828]. It errors in some locations can be delivered to the user [RFC3828]. It
uses a different transport protocol number (136) than UDP (17) to uses a different transport protocol number (136) than UDP (17) to
interpret the UDP Length field as the prefix covered by the UDP interpret the UDP Length field as the prefix covered by the UDP
checksum. checksum.
UDP (protocol 17) already defines the UDP Length field as the limit UDP (protocol 17) already defines the UDP Length field as the limit
skipping to change at page 26, line 46 skipping to change at page 27, line 44
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. Note that when a three in a row), this limits their DOS impact. Note that when a
packet's options cannot be processed, it MUST be discarded; the packet's options cannot be processed, it MUST be discarded; the
packet and its options should always share the same fate. packet and its options should always share the same fate.
18. IANA Considerations 18. IANA Considerations
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Option Kind numbers, similar to that for TCP Option Kinds. for UDP Option Kind numbers, similar to that for TCP Option Kinds.
Initial values of this registry are as listed in Section 5. Initial values of this registry are as listed in Section 5.
Additional values in this registry are to be assigned by IESG Additional values in this registry are to be assigned from the
Approval or Standards Action [RFC8126]. UNASSIGNED values Section 5 in by IESG Approval or Standards Action
[RFC8126]. Those assignments are subject to the conditions set forth
in this document, particularly (but not limited to) those in Section
7.
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for
use in a similar manner as TCP ExIDs [RFC6994]. This registry is use in a similar manner as TCP ExIDs [RFC6994]. This registry is
initially empty. Values in this registry are to be assigned by IANA initially empty. Values in this registry are to be assigned by IANA
using first-come, first-served (FCFS) rules [RFC8126]. using first-come, first-served (FCFS) rules [RFC8126]. Options using
these ExIDs are subject to the same conditions as new options, i.e.,
they too are subject to the conditions set forth in this document,
particularly (but not limited to) those in Section 7.
19. References 19. References
19.1. Normative References 19.1. Normative References
[Fa19] Fairhurst, G., T. Jones, M. Tuexen, I. Ruengeler, T. [Fa19] Fairhurst, G., T. Jones, M. Tuexen, I. Ruengeler, T.
Voelker, "Packetization Layer Path MTU Discovery for Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports," draft-ietf-tsvwg-datagram-plpmtud, Datagram Transports," draft-ietf-tsvwg-datagram-plpmtud,
Feb. 2019. Feb. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC768] Postel, J., "User Datagram Protocol," RFC 768, August [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August
1980. 1980.
[RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
[RFC1071] Braden, R., D. Borman, C. Partridge, "Computing the
Internet Checksum", RFC 1071, Sep. 1988.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989. Communication Layers," RFC 1122, Oct. 1989.
[RFC1662] Simpson, W. Ed., "PPP in HDLC-like Framing," RFC 1662, [RFC1662] Simpson, W. Ed., "PPP in HDLC-like Framing," RFC 1662,
Oct. 1994. Oct. 1994.
19.2. Informative References 19.2. Informative References
[Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation
Options for UDP Options", draft-fairhurst-udp-options-cco, Options for UDP Options", draft-fairhurst-udp-options-cco,
skipping to change at page 30, line 5 skipping to change at page 31, line 5
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
Manhattan Beach, CA 90266 USA Manhattan Beach, CA 90266 USA
Phone: +1 (310) 560-0334 Phone: +1 (310) 560-0334
Email: touch@strayalpha.com Email: touch@strayalpha.com
Appendix A. Implementation Information Appendix A. Implementation Information
The following information is provided to encourage interoperable API The following information is provided to encourage interoperable API
implementations. implementations.
System-level variables (sysctl): System-level variables (sysctl):
Name default meaning Name default meaning
---------------------------------------------------- ----------------------------------------------------
net.ipv4.udp_opt 0 UDP options available net.ipv4.udp_opt 0 UDP options available
net.ipv4.udp_opt_ocs 1 Default include OCS net.ipv4.udp_opt_ocs 1 Default include OCS
 End of changes. 38 change blocks. 
105 lines changed or deleted 129 lines changed or added

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