rfc9868v5.txt   rfc9868.txt 
skipping to change at line 175 skipping to change at line 175
UNSAFE Options: UDP Options that are not designed to be safely UNSAFE Options: UDP Options that are not designed to be safely
ignored by a receiver that does not understand them. Such options ignored by a receiver that does not understand them. Such options
could alter the UDP user data or signal a change in what its could alter the UDP user data or signal a change in what its
contents represent, but there are restrictions on how they can be contents represent, but there are restrictions on how they can be
transmitted; these restrictions are noted in Sections 10 and 12. transmitted; these restrictions are noted in Sections 10 and 12.
User: The upper layer application, protocol, or service that User: The upper layer application, protocol, or service that
produces and consumes content that UDP transfers. produces and consumes content that UDP transfers.
User datagram: A UDP packet, composed of a UDP header and UDP User datagram: A UDP packet, composed of a UDP header and UDP
payload; as discussed herein, that payload need not extend to the payload; as discussed herein, the UDP payload need not extend to
end of the IP datagram. In this document, the original intent the end of the IP datagram. In this document, the original intent
that a UDP datagram corresponds to the user portion of a single IP that a UDP datagram corresponds to the user portion of a single IP
datagram is redefined, where a UDP datagram can span more than one datagram is redefined, where a UDP datagram can span more than one
IP datagram through UDP fragmentation. IP datagram through UDP fragmentation.
4. Background 4. Background
Many protocols include a default, invariant header and an area for Many protocols include a default, invariant header and an area for
header options that varies from packet to packet. These options header options that varies from packet to packet. These options
enable the protocol to be extended for use in particular environments enable the protocol to be extended for use in particular environments
or in ways unforeseen by the original designers. Examples include or in ways unforeseen by the original designers. Examples include
skipping to change at line 934 skipping to change at line 934
have been intentionally overwritten, e.g., by a middlebox to update have been intentionally overwritten, e.g., by a middlebox to update
embedded port numbers or IP addresses. Such overwrites could be embedded port numbers or IP addresses. Such overwrites could be
intentional and not widely known; defaulting to silent ignore ensures intentional and not widely known; defaulting to silent ignore ensures
that option-aware endpoints do not change how users or applications that option-aware endpoints do not change how users or applications
operate unless explicitly directed to do otherwise. operate unless explicitly directed to do otherwise.
>> UDP packets with unrecognized APC lengths MUST receive the same >> UDP packets with unrecognized APC lengths MUST receive the same
treatment as UDP packets with incorrect APC Option checksum fields. treatment as UDP packets with incorrect APC Option checksum fields.
Ensuring that unrecognized APC lengths are treated as incorrect Ensuring that unrecognized APC lengths are treated as incorrect
checksums enables future variants of APC to be treated like APC. checksums enables future variants of APC to be treated similarly.
The APC is reported to the user and useful only per-datagram, because The APC is reported to the user and useful only per-datagram, because
fragments have no UDP user data. fragments have no UDP user data.
11.4. Fragmentation (FRAG) 11.4. Fragmentation (FRAG)
The Fragmentation (FRAG, Kind=3) Option supports UDP fragmentation The Fragmentation (FRAG, Kind=3) Option supports UDP fragmentation
and reassembly, which can be used to transfer UDP messages larger and reassembly, which can be used to transfer UDP messages larger
than allowed by the IP Effective MTU for Receiving (EMTU_R) than allowed by the IP Effective MTU for Receiving (EMTU_R)
[RFC1122]. FRAG includes a copy of the same UDP transport ports in [RFC1122]. FRAG includes a copy of the same UDP transport ports in
skipping to change at line 1317 skipping to change at line 1317
>> Endpoints supporting UDP Options MUST support a local MRDS size of >> Endpoints supporting UDP Options MUST support a local MRDS size of
at least 2,926 bytes for IPv4 and 2,886 bytes for IPv6. Support for at least 2,926 bytes for IPv4 and 2,886 bytes for IPv6. Support for
larger values is encouraged. larger values is encouraged.
>> Endpoints supporting UDP Options MUST support a local MRDS segs >> Endpoints supporting UDP Options MUST support a local MRDS segs
value of at least 2. Support for larger values is encouraged. value of at least 2. Support for larger values is encouraged.
These parameters plus the Path MTU (PMTU) allow a sender to compute These parameters plus the Path MTU (PMTU) allow a sender to compute
the size of the largest pre-fragmentation UDP packet that a receiver the size of the largest pre-fragmentation UDP packet that a receiver
will guarantee to accept. Define MMS_S as the PMTU less the size of will guarantee to accept. MMS_S is defined as the PMTU less the size
the IP header and the UDP header, i.e., the maximum UDP message size of the IP header and the UDP header, i.e., the maximum UDP message
that can be successfully sent in a single UDP datagram if there are size that can be successfully sent in a single UDP datagram if there
no IP options or extension headers and no UDP per-fragment options. are no IP options or extension headers and no UDP per-fragment
Then, the size of the largest pre-fragmentation UDP packet that the options. Given the above size definitions, the size of the largest
receiver will guarantee to accept is the smaller of the MRDS size and pre-fragmentation UDP packet that the receiver will guarantee to
accept is the smaller of the MRDS size and the following:
(MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8 (MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8
where Total Per-Frag IP/UDP Options includes the size of all IP In the above expression, the Total Per-Frag IP/UDP Options includes
options and extension headers and all per-fragment UDP Options, the size of all IP options and extension headers and all per-fragment
except for OCS and FRAG, that are in the sequence of UDP fragments. UDP Options, except for OCS and FRAG, that are in the sequence of UDP
fragments.
>> If no MRDS Option has been received, a sender MUST assume that >> If no MRDS Option has been received, a sender MUST assume that
MRDS size is 2,926 bytes for IPv4 and 2,886 bytes for IPv6 and that MRDS size is 2,926 bytes for IPv4 and 2,886 bytes for IPv6 and that
MRDS segs is 2, i.e., the minimum values allowed. MRDS segs is 2, i.e., the minimum values allowed.
MRDS is reported to the user, whether used per-datagram or per- MRDS is reported to the user, whether used per-datagram or per-
fragment (as defined in Section 11.4). When used per-fragment, the fragment (as defined in Section 11.4). When used per-fragment, the
reported value is the minimum of the MRDS values received per- reported value is the minimum of the MRDS values received per-
fragment. fragment.
skipping to change at line 1699 skipping to change at line 1701
The design of the UNSAFE Options ensures that the resulting UDP data The design of the UNSAFE Options ensures that the resulting UDP data
will be silently dropped in both legacy receivers and options-aware will be silently dropped in both legacy receivers and options-aware
receivers that do not recognize those options. Again, note that this receivers that do not recognize those options. Again, note that this
still results in the delivery of a zero-length UDP packet. still results in the delivery of a zero-length UDP packet.
Options-aware receivers can drop UDP packets with option processing Options-aware receivers can drop UDP packets with option processing
errors via either an override of the default UDP processing or at the errors via either an override of the default UDP processing or at the
application layer. application layer.
That is, all options are treated the same, in that the transmitter Put another way, all options are treated the same, in that the
can add it as desired and the receiver has the option to require it transmitter can add each option as desired and the receiver has the
or not. Only if it is required (e.g., by API configuration) would choice to require a given option or not. Only if a particular option
the receiver require it being present and correct. is indicated as mandatory by a receiver (e.g., by API configuration)
would the receiver need to confirm it being present and correct.
That is, for all options: In summary, for all options:
* if the option is not required by the receiver, then UDP packets * if the option is not required by the receiver, then UDP packets
missing the option are accepted. missing the option are accepted.
* if the option is required (e.g., by override of the default * if the option is required (e.g., by override of the default
behavior at the receiver) and missing or incorrectly formed, behavior at the receiver) and missing or incorrectly formed,
silently drop the UDP packet. silently drop the UDP packet.
* if the UDP packet is accepted (either because the option is not * if the UDP packet is accepted (either because the option is not
required or because it was required and correct), then pass the required or because it was required and correct), then pass the
skipping to change at line 2171 skipping to change at line 2174
not expect to receive more than a few unknown option types per not expect to receive more than a few unknown option types per
packet. packet.
25.4. Considerations for Fragmentation 25.4. Considerations for Fragmentation
UDP fragmentation introduces its own set of security concerns, which UDP fragmentation introduces its own set of security concerns, which
can be handled in a manner similar to IP reassembly or TCP segment can be handled in a manner similar to IP reassembly or TCP segment
reordering [CERT18]. In particular, the number of UDP packets reordering [CERT18]. In particular, the number of UDP packets
pending reassembly and effort used for reassembly is typically pending reassembly and effort used for reassembly is typically
limited. In addition, it could be useful to assume a reasonable limited. In addition, it could be useful to assume a reasonable
minimum fragment size, e.g., that non-terminal fragments are never be minimum fragment size, e.g., that non-terminal fragments are never
smaller than 500 bytes. smaller than 500 bytes.
>> Implementations concerned with the potential for UDP fragmentation >> Implementations concerned with the potential for UDP fragmentation
introducing a vulnerability SHOULD implement limits on the number of introducing a vulnerability SHOULD implement limits on the number of
pending fragments. pending fragments.
25.5. Considerations for Providing UDP Security 25.5. Considerations for Providing UDP Security
UDP security is not intended to rely solely on transport layer UDP security is not intended to rely solely on transport layer
processing of options. UNSAFE Options are the only type that share processing of options. UNSAFE Options are the only type that share
 End of changes. 7 change blocks. 
18 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.48.