Datagram PLPMTUD for UDP Options
draft-fairhurst-tsvwg-udp-options-dplpmtud-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Gorry Fairhurst , Tom Jones | ||
| Last updated | 2019-04-25 | ||
| Replaced by | draft-ietf-tsvwg-udp-options-dplpmtud | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fairhurst-tsvwg-udp-options-dplpmtud-00
Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones
Intended status: Standards Track University of Aberdeen
Expires: October 27, 2019 April 25, 2019
Datagram PLPMTUD for UDP Options
draft-fairhurst-tsvwg-udp-options-dplpmtud-00
Abstract
This document describes how a UDP Options sender may implement
Datagram Packetization Layer Path Maximum Transmission Unit Discovery
(DPLPMTUD) as a robust method for Path Maximum Transmission Unit
Discovery.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Fairhurst & Jones Expires October 27, 2019 [Page 1]
Internet-Draft UDPO DPLPMTUD April 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DPLPMTUD for UDP Options . . . . . . . . . . . . . . . . . . 3
3.1. Sending Packet Probes using Control Information . . . . . 4
3.2. Sending Packet Probes using Application Data . . . . . . 5
3.3. Validating the Path with UDP Options . . . . . . . . . . 5
3.4. Handling of PTB Messages by UDP Options . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 7
Appendix B. Informative Description of new UDP Options . . . . . 7
B.1. UDP Probe Request Option . . . . . . . . . . . . . . . . 7
B.2. UDP Probe Response Option . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The User Datagram Protocol [RFC0768] offers a minimal transport
service on top of IP and is frequently used as a substrate for other
protocols. Applications using UDP frequently have to implement basic
transport services such as Path Maximum Transmission Unit Discovery
(PMTUD) themselves. Section 3.5 of UDP Guidelines ([RFC8085])
recommends that applications implement some form of Path MTU
Discovery to avoid the generation of IP fragments:
"Consequently, an application SHOULD either use the path MTU
information provided by the IP layer or implement Path MTU Discovery
(PMTUD)".
The UDP API [RFC8304] offers calls for applications to receive ICMP
Packet Too Big (PTB) messages and to control the size of messages
that are sent, but does not offer any automatic mechanisms for an
application to discover the maximum packet size supported by a path.
Applications and upper layer protocols are left to implement robust
PMTUD mechanisms of their own.
Packetization Layer PMTUD (PLPMTUD) [RFC4821] describes a method for
a Packetization Layer (such as UDP with options) to search for the
largest MTU supported on a path in the absence of ICMP PTB messages.
Datagram PLPMTUD [I-D.ietf-tsvwg-datagram-plpmtud] describes PMTUD
probing and search algorithms for datagram transports that does not
solely rely on ICMP PTB messages. This allows the Packetization
Fairhurst & Jones Expires October 27, 2019 [Page 2]
Internet-Draft UDPO DPLPMTUD April 2019
Layer to offer a probing mechanism which works in the presence of
lost probes. However, UDP is unable itself to offer the required
probing mechanisms to implement DPLPMTUD without some additional
transport services. This document specifies the additional
functionality required to perform DPLPMTUD with UDP Options as a
service to upper-layer protocols.
The authors solicit comments from the TSV working group. The working
group could decide to incorporate the text in the current
contribution into subsequent versions of the UDP Options
Specification.
The structure of the present document follows the structure used to
describe DPLPMTUD for other transports
[I-D.ietf-tsvwg-datagram-plpmtud].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
3. DPLPMTUD for UDP Options
UDP Options[I-D.ietf-tsvwg-udp-options] supplies additional
functionality that can be used to implement DPLPMTUD within the UDP
transport service. Implementing DPLPMTUD using UDP Options avoids
the need for each upper layer protocol or application to implement
the DPLPMTUD method.
Section 5.6 of[I-D.ietf-tsvwg-udp-options] defines the Maximum
Segment Size (MSS) option, which allows the local sender to indicate
the EMTU_R to the peer. The value received in this option can be
used to initialise MAX_PMTU used by DPLPMTUD.
The DPLPMTUD method [I-D.ietf-tsvwg-datagram-plpmtud] relies upon the
sender Packetization Layer to be able to generate probe packets with
a specific size. UDP Options enables padding to be added to a UDP
datagram that is used as these Probe Packets. Feedback confirming
reception of each Probe Packet is provided by two UDP Options
described in section 6 of [I-D.ietf-tsvwg-udp-options]:
o The Probe Request Option (Appendix B.1) is set by a sending PL to
solicit a response from a remote endpoint. A four-byte token
identifies each request.
Fairhurst & Jones Expires October 27, 2019 [Page 3]
Internet-Draft UDPO DPLPMTUD April 2019
o The Probe Response Option (Appendix B.2 is generated by the UDP
Options receiver in response to reception of a previously received
Probe Request Option. Each Probe Response Option echoes a
previously received four-byte token.
The token value allows implementations to be distinguish between
acknowledgements for initial probe packets and acknowledgements
confirming receipt of subsequent probe packets (e.g., travelling
along alternate paths with a larger RTT). Each probe packet needs to
be uniquely identifiable by the UDP Options sender within the Maximum
Segment Lifetime (MSL). The UDP Options sender therefore needs to
not recycle token values until they have expired or have been
acknowledged. A four byte value for the token field provides
sufficient space for multiple unique probes to be made within the
MSL.
The initial value of the four byte token field SHOULD be assigned to
a randomised value, as described in section 5.1 of [RFC8085]) to
enhance protection from off-path attacks.
Implementations ought to only send a probe packet with a Request
Probe Option when required by their local state machine, i.e., when
probing to grow the PLPMTU or to confirm the current PLPMTU. The
procedure to handle the loss of a response packet is the
responsibility of the sender of the request. Implementations are
allowed to track multiple requests and respond to them with a single
packet.
A PL needs to determine that the current path can still support the
size of datagram that the application is currently sending in the
DPLPMTUD search_done state (i.e., to detect black-holing of data).
One way to achieve this is to send probe packets of size PLPMTU or to
utilise a higher-layer method that provides explicit feedback
indicating any packet loss.
3.1. Sending Packet Probes using Control Information
The recommended approach to implementing DPLPMTUD sends a Probe
Packet that contains only control information together with any
padding that is needed to be inflated to the size required for the
probe packet. These probe packets do not carry an application-
supplied data block and therefore they do not typically require
retransmission, although they do still consume network capacity and
incur endpoint processing (see Section 4.1 of
[I-D.ietf-tsvwg-datagram-plpmtud]).
Fairhurst & Jones Expires October 27, 2019 [Page 4]
Internet-Draft UDPO DPLPMTUD April 2019
3.2. Sending Packet Probes using Application Data
Another possibility is to utilise data packets for Probe Packets
(Section 4.1 of [I-D.ietf-tsvwg-datagram-plpmtud] discusses the
merits and demerits of this approach). A probe packet then contains
a data block supplied by an application that is combined with padding
to inflate the length of the datagram to the size required for the
probe and additionally contains a Timestamp Option.
Reception of a valid Timestamp Option that was echoed by the remote
endpoint can also be used to infer connectivity. This can provide
useful feedback even over paths with asymmetric capacity and/or that
carry UDP Option flows that have very asymmetric datagram rates,
because an echo of the most recent Timestamp still indicates
reception of at least one packet of the transmitted size. This is
sufficient to confirm there is no black hole.
If the application/transport needs protection from the loss of this
Probe Packet, the application/ transport could perform transport-
layer retransmission/repair of the data block (e.g., by
retransmission after loss is detected or by duplicating the data
block in a datagram without the padding) [RFC8085].
When sending a probe to increase the PLPMTU, a Timestamp might be
unable to unambiguously identify that a specific probe packet has
been received. Timestamp mechanisms cannot be used to confirm the
reception of individual probe messages and cannot be used to
stimulate a response from the remote peer.
3.3. Validating the Path with UDP Options
The UDP sender validates the responses to a Packet Probe
[I-D.ietf-tsvwg-datagram-plpmtud] using the UDP port information in
combination with the token and/or Timestamp value contained in the
UDP Option.
3.4. Handling of PTB Messages by UDP Options
The UDP sender validates any received ICMP PTB message that is
received in response to a Packet Probe
[I-D.ietf-tsvwg-datagram-plpmtud] using the quoted packet to validate
the UDP port information in combination with the token and/or
timestamp value contained in the UDP Option.
Fairhurst & Jones Expires October 27, 2019 [Page 5]
Internet-Draft UDPO DPLPMTUD April 2019
4. Acknowledgements
Gorry Fairhurst and Tom Jones are supported by funding provided by
the University of Aberdeen.
5. IANA Considerations
This memo includes no requests to IANA.
6. Security Considerations
The security considerations for are described in
[I-D.ietf-tsvwg-udp-options]. The proposed new method does not
change the integrity protection offered by the UDP options method.
7. References
7.1. Normative References
[I-D.ietf-tsvwg-datagram-plpmtud]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-07
(work in progress), February 2019.
[I-D.ietf-tsvwg-udp-options]
Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
udp-options-07 (work in progress), March 2019.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
Fairhurst & Jones Expires October 27, 2019 [Page 6]
Internet-Draft UDPO DPLPMTUD April 2019
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the
User Datagram Protocol (UDP) and Lightweight UDP (UDP-
Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018,
<https://www.rfc-editor.org/info/rfc8304>.
Appendix A. Revision Notes
XXX Note to RFC-Editor: please remove this entire section prior to
publication. XXX
Individual draft-00.
o This version contains a description for consideration and comment
by the TSVWG.
Appendix B. Informative Description of new UDP Options
XXX Note to RFC-Editor: please remove this entire section prior to
publication (including subsections) before publication. XXX
This annexe contains a provisional description of the UDP Options
that will be specified in [I-D.ietf-tsvwg-udp-options]. The
information is provided for information only, to enable understanding
of the algorithm and will be superseded by text in the UDP Options
specification.
B.1. UDP Probe Request Option
The Probe Request Option allows a sending endpoint to solicit a
response from a destination endpoint.
The Probe Request Option carries a four byte token set by the sender.
This token can be set to a value that is likely to be known only to
the sender (and is sent along the end-to-end path). The initial
value of the token SHOULD be assigned to a randomised value, as
described in section 5.1 of [RFC8085]) to enhance protection from
off-path attacks.
The sender needs to then check the value returned in the UDP Probe
Response Option. The value of the Token field, uniquely identifies a
probe within the maximum segment lifetime.
Fairhurst & Jones Expires October 27, 2019 [Page 7]
Internet-Draft UDPO DPLPMTUD April 2019
+----------+--------+-----------------+
| Kind=TBD | Len=6 | Token |
+----------+--------+-----------------+
1 byte 1 byte 4 bytes
Figure 1: UDP Probe REQ Option Format
B.2. UDP Probe Response Option
The Probe Response Option is generated in response to reception of a
previously received Probe Request Option. This response is generated
by the UDP Option processing.
The Probe Response Option carries a four byte Token field. The Token
field associates the response with the token value carried in the
most recently-received Echo Request. The rate of generation of UDP
packets carrying a Probe Response Option is expected to be less than
once per RTT and SHOULD be rate-limited (see Section 6).
+----------+--------+-----------------+
| Kind=TBD | Len=6 | Token |
+----------+--------+-----------------+
1 byte 1 byte 4 bytes
Figure 2: UDP Probe RES Option Format
Authors' Addresses
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
UK
Email: gorry@erg.abdn.ac.uk
Tom Jones
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
UK
Email: tom@erg.abdn.ac.uk
Fairhurst & Jones Expires October 27, 2019 [Page 8]