idnits 2.17.1 draft-herbert-udp-space-hdr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 104: '... Padding bytes MUST be set to zero o...' RFC 2119 keyword, line 141: '... A sender MAY set a UDP surplus spac...' RFC 2119 keyword, line 146: '... The sender MUST insert up to three ...' RFC 2119 keyword, line 149: '... The sender MUST set the Type field ...' RFC 2119 keyword, line 152: '...The Length field MUST be set to reflec...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: September 2019 6 March 11, 2019 8 UDP Surplus Space Header 9 draft-herbert-udp-space-hdr-00 11 Abstract 13 This draft defines a header for surplus space in UDP. The UDP surplus 14 space is bytes between the end of the UDP payload and the end of the 15 IP packet. The purpose of the header is to disambiguate uses of the 16 surplus space. The UDP surplus space header includes a type, length, 17 and checksum field that covers the space. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2 UDP surplus space header format . . . . . . . . . . . . . . . . 3 59 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1 Sender operation . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2 Receiver operation . . . . . . . . . . . . . . . . . . . . . 6 62 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 66 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1 Introduction 71 This specification defines a UDP surplus header to provide an 72 extensible and generic format of the UDP surplus space. The UDP 73 surplus space is bytes between the end of the UDP payload and the end 74 of the IP packet. The UDP surplus space is possible since UDP 75 contains its own length field for the UDP datagram that is not 76 required to coincide with the end of the IP packet. 78 The UDP surplus space header includes a type, length, and checksum 79 field that covers the space. UDP options [UDPOPT] are being defined 80 as the first standard use of the UDP surplus space. This draft 81 permits other uses, including private uses of the space. 83 2 UDP surplus space header format 85 The format of the UDP surplus space header is shown below. 87 0 1 2 3 88 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Padding (0 to 3 bytes) | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | Type | Length | Checksum | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | 95 ~ Type Specific Data ~ 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 The fields are: 101 o Padding: Aligns the header to four bytes. The number of padding 102 bytes required is: 3 - ((udp_length - 1) % 4) where the 103 udp_length is the length of the UDP header and UDP payload. 104 Padding bytes MUST be set to zero on transmission, and MUST be 105 verified to be zero when received. 107 o Type: The type of the UDP surplus space. One type is defined for 108 UDP options. 110 o Length: Length of the Type Specific Data in units of four byte 111 words. The length of the Type Specific Data is thus zero to 1020 112 bytes. 114 o Checksum: The standard one's complement checksum that covers the 115 UDP surplus space starting from the Type field through the end 116 of the Type Specific Data as indicated in the Length field. 118 Preceding Padding Bytes are not included in the checksum 119 coverage. 121 o Type specific data: Data corresponding to the Type of the 122 surplus data. For instance, in the case of UDP options, the Type 123 specific data would contain the UDP options including any 124 padding options to align the length of the Type Specific Data to 125 four bytes. 127 Defined Type values are: 129 o 0: Reserved 131 o 1: UDP options 133 0 2-127: Reserved 135 0 128-255: Available for private use or experimentation 137 3 Operation 139 3.1 Sender operation 141 A sender MAY set a UDP surplus space header and data in the surplus 142 space when sending a UDP packet. The UDP surplus header immediately 143 follows the UDP payload at the offset of UDP Length from the start of 144 the UDP header. 146 The sender MUST insert up to three bytes of padding to align the UDP 147 surplus header to four bytes. 149 The sender MUST set the Type field to the type of the data to be 150 processed. 152 The Length field MUST be set to reflect the length of the Type 153 Specific Data. 155 The Checksum MUST be set. To compute the checksum: 157 1) Set the Checksum field to zero. Compute the standard one's 158 complement two byte checksum starting from the Type field 159 through the end of the Type Specific Data. 161 2) Set the value of the Checksum field to the bitwise "not" of the 162 checksum computed in the previous step. 164 Note that a sender MAY set multiple UDP surplus area headers in a 165 packet. If more than one is set, then they are consecutive where one 166 immediately follows another. 168 3.2 Receiver operation 170 The following steps are for processing a UDP packet with surplus 171 space: 173 1) Check for minimum length to contain a surplus option header. If 174 the surplus space length is less than 3 - ((udp_length - 1) % 175 4) + 4, then the UDP surplus space header is not present. 177 2) Check padding bytes. If the UDP Length is not a multiple of 178 four bytes then verify that the padding bytes following the UDP 179 payload are set to zero. Then expected number of padding bytes 180 is 3 - ((udp_length - 1) % 4). 182 3) Check the Length field. If the length determined from the 183 Length field plus the starting offset of the Type specific data 184 exceeds the length of the packet then the surplus area header 185 is considered invalid. 187 4) Verify the checksum. Compute the one's complement checksum 188 starting from the Type field through the end of the Type 189 specific data as indicated by the Length field. If the result 190 of the computation ~0 (-0 checksum value) then the checksum is 191 verified. If the checksum is not verified then the surplus area 192 header is invalid. 194 5) Check the Type. If the Type is unknown to the receiver then the 195 surplus header is considered invalid. 197 6) Process the Type Specific Data per the Type in the UDP surplus 198 space header. In the course of processing the Type specific 199 data, the receiver may determine that the surplus data is 200 invalid. 202 7) If there are additional bytes beyond the surplus header, a 203 receiver MAY attempt to process those bytes as an additional 204 surplus header. Processing would the same as how the first 205 header was processed (although note that subsequent UDP surplus 206 headers would not need Padding bytes since they would already 207 be aligned to four bytes). 209 If the number surplus bytes in a UDP packet are non-zero and 210 determined to not contain a valid UDP surplus header, the surplus 211 bytes SHOULD be ignored following existing protocol processing 212 convention. An implementation MAY allow configuration that would 213 discard such packets. 215 4 Security Considerations 217 The UDP surplus space header does not address nor introduce any new 218 security considerations. 220 5 IANA Considerations 222 IANA is requested to create a registry for the Type of UDP surplus 223 options. 225 6 References 227 6.1 Normative References 229 6.2 Informative References 231 [UDPOPT] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 232 udp-options-07 234 Author's Address 236 Tom Herbert 237 Quantonium 238 Santa Clara, CA 239 USA 241 Email: tom@quantonium.net