draft-ietf-tsvwg-udp-options-04.txt   draft-ietf-tsvwg-udp-options-05.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Internet Draft
Intended status: Standards Track July 1, 2018 Intended status: Standards Track July 19, 2018
Intended updates: 768 Intended updates: 768
Expires: January 2019 Expires: January 2019
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-04.txt draft-ietf-tsvwg-udp-options-05.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 January 1, 2019. This Internet-Draft will expire on January 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 34 skipping to change at page 2, line 34
5.3. Option Checksum (OCS).....................................9 5.3. Option Checksum (OCS).....................................9
5.4. Alternate Checksum (ACS).................................10 5.4. Alternate Checksum (ACS).................................10
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.7.1. Coupling FRAG with LITE.............................16 5.7.1. Coupling FRAG with LITE.............................16
5.8. Timestamps (TIME)........................................17 5.8. Timestamps (TIME)........................................17
5.9. Authentication and Encryption (AE).......................17 5.9. Authentication and Encryption (AE).......................17
5.10. Experimental (EXP)......................................18 5.10. Experimental (EXP)......................................18
6. UDP API Extensions............................................19 6. UDP API Extensions............................................19
7. Whose options are these?......................................19 7. Whose options are these?......................................20
8. UDP options LITE option vs. UDP-Lite..........................20 8. UDP options LITE option vs. UDP-Lite..........................20
9. Interactions with Legacy Devices..............................21 9. Interactions with Legacy Devices..............................21
10. Options in a Stateless, Unreliable Transport Protocol........21 10. Options in a Stateless, Unreliable Transport Protocol........22
11. UDP Option State Caching.....................................22 11. UDP Option State Caching.....................................22
12. Updates to RFC 768...........................................22 12. Updates to RFC 768...........................................22
13. Multicast Considerations.....................................22 13. Multicast Considerations.....................................23
14. Security Considerations......................................22 14. Security Considerations......................................23
15. IANA Considerations..........................................23 15. IANA Considerations..........................................23
16. References...................................................24 16. References...................................................24
16.1. Normative References....................................24 16.1. Normative References....................................24
16.2. Informative References..................................24 16.2. Informative References..................................24
17. Acknowledgments..............................................26 17. Acknowledgments..............................................26
Appendix A. Implementation Information...........................28 Appendix A. Implementation Information...........................28
1. Introduction 1. Introduction
Transport protocols use options as a way to extend their Transport protocols use options as a way to extend their
skipping to change at page 9, line 38 skipping to change at page 9, line 38
[NOTE: Tom Herbert suggested we declare "more than 3 consecutive [NOTE: Tom Herbert suggested we declare "more than 3 consecutive
NOPs" a fatal error to reduce the potential of using NOPs as a DOS 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 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 an 8-bit ones-complement sum (Ones8) The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8)
that covers all of the UDP options. OCS is 8-bits to allow the that covers all of the UDP options. OCS is 8-bits to allow the
entire option to occupy a total of 16 bits. entire option to occupy a total of 16 bits. The primary purpose of
OCS is to detect non-standard (i.e., non-option) uses of the surplus
area.
OCS can be calculated by computing the 16-bit ones-complement sum OCS can be calculated by computing the 16-bit ones-complement sum
and "folding over" the result (using carry wraparound). Note that and "folding over" the result (using carry wraparound). Note that
OCS is direct, i.e., it is not negated or adjusted if zero (unlike OCS is direct, i.e., it is not negated or adjusted if zero (unlike
the Internet checksum as used in IPv4, TCP, and UDP headers). OCS the Internet checksum as used in IPv4, TCP, and UDP headers). OCS
protects the option area from errors in a similar way that the UDP protects the option area from errors in a similar way that the UDP
checksum protects the UDP user data. checksum protects the UDP user data.
+--------+--------+ +--------+--------+
| Kind=2 | Ones8 | | Kind=2 | Ones8 |
+--------+--------+ +--------+--------+
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, preferably preceded by only NOP options for alignment and
the LITE option if present. the LITE option if present.
OCS covers the entire UDP option area, including the Lite option as OCS covers the entire UDP option area, including the Lite option as
formatted before swapping for transmission (or, equivalently, after formatted before swapping (or relocation) for transmission (or,
the swap after reception). equivalently, after the swap/relocation after reception).
>> If the option checksum fails, all options MUST be ignored and any >> If the option checksum fails, all options MUST be ignored and any
trailing surplus data (and Lite data, if used) silently discarded. 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 the UDP option checksum
fails, unless the endpoints have negotiated otherwise for this fails, unless the endpoints have negotiated otherwise for this
segment's socket pair. segment's socket pair.
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
UDP header checksum, using a 16-bit CRC of the conventional UDP checksum in the UDP header, using a 16-bit CRC of the conventional
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). It does not include the IP options, and not include the LITE area). Because it does not include
pseudoheader or UDP header, and so need not be updated by NATs when the IP pseudoheader or UDP header, it need not be updated by NATs
IP addresses or UDP ports are rewritten. Its purpose is to detect when IP addresses or UDP ports are rewritten. Its purpose is to
errors that the UDP checksum might not detect. CRC-CCITT (polynomial detect errors that the UDP checksum might not detect.
x^16 + x^12 + x^5 + x) has been chosen because of its ubiquity and
use in other packet protocols, such as X.25, HDLC, and Bluetooth. CRC-CCITT (polynomial x^16 + x^12 + x^5 + 1) has been chosen because
The option contains the remainder of the calculation of the of its ubiquity and use in other packet protocols, such as X.25,
polynomial over the UDP payload data (i.e., not inverted). HDLC, and Bluetooth. The option contains FCS-16 as defined in
Appendix C of [RFC1662], except that it is not inverted in the final
step and that it is stored in the ACS option in network byte order.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=3 | Len=4 | CRC16sum | | Kind=3 | Len=4 | CRC16sum |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 8 UDP ACS option format Figure 8 UDP ACS option format
When present, the ACS always contains a valid CRC checksum. There When present, the ACS always contains a valid CRC checksum. There
are no reserved values, including the value of zero. If the CRC is are no reserved values, including the value of zero. If the CRC is
zero, this must indicate a valid checksum (i.e., it does not zero, this must indicate a valid checksum (i.e., it does not
skipping to change at page 17, line 14 skipping to change at page 17, line 14
5.8. Timestamps (TIME) 5.8. Timestamps (TIME)
The UDP Timestamp option (TIME) exchanges two four-byte timestamp The UDP Timestamp option (TIME) exchanges two four-byte timestamp
fields. It serves a similar purpose to TCP's TS option [RFC7323], fields. It serves a similar purpose to TCP's TS option [RFC7323],
enabling UDP to estimate the round trip time (RTT) between hosts. enabling UDP to estimate the round trip time (RTT) between hosts.
For UDP, this RTT can be useful for establishing UDP fragment For UDP, this RTT can be useful for establishing UDP fragment
reassembly timeouts or transport-layer rate-limiting [RFC8085]. reassembly timeouts or transport-layer rate-limiting [RFC8085].
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
| Kind=7 | Len=10 | TS Value | TS Echo Reply | | Kind=7 | Len=10 | TSval | TSecr |
+--------+--------+------------------+------------------+ +--------+--------+------------------+------------------+
1 byte 1 byte 4 bytes 4 bytes 1 byte 1 byte 4 bytes 4 bytes
Figure 18 UDP TIME option format Figure 18 UDP TIME option format
TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar
the TCP TS option [RFC7323]. A host using the Timestamp option sets manner to the TCP TS option [RFC7323]. On transmitted segments using
TS Value on all UDP segments issued. Received TSval values are the option, TS Value is always set based on the local "time" value.
provided to the application, which passes this value as TSecr on UDP Received TSval and TSecr values are provided to the application,
messages sent in response to such a message. 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
TSecr of zero indicates that the TSval was not echoed by the
transmitter, i.e., from a previously received UDP packet.
>> UDP MAY use an RTT estimate based on nonzero Timestamp values as >> UDP 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 >> UDP SHOULD make this RTT estimate available to the user
application. application.
5.9. Authentication and Encryption (AE) 5.9. Authentication and Encryption (AE)
skipping to change at page 24, line 20 skipping to change at page 24, line 29
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.
[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,
Oct. 1994.
16.2. Informative References 16.2. Informative References
[Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User
Datagrams (SPUD) Prototype," draft-hildebrand-spud- Datagrams (SPUD) Prototype," draft-hildebrand-spud-
prototype-03, Mar. 2015. prototype-03, Mar. 2015.
[RFC793] Postel, J., "Transmission Control Protocol" RFC 793, [RFC793] Postel, J., "Transmission Control Protocol" RFC 793,
September 1981. September 1981.
[RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191,
 End of changes. 12 change blocks. 
26 lines changed or deleted 36 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/