idnits 2.17.1 draft-mcquistin-augmented-tcp-example-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 150: '... The window size MUST be treated as an...' RFC 2119 keyword, line 152: '...(MUST-1). It is RECOMMENDED that impl...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Options' is mentioned on line 97, but not defined == Outdated reference: A later version (-13) exists of draft-mcquistin-augmented-ascii-diagrams-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. McQuistin 3 Internet-Draft V. Band 4 Intended status: Experimental D. Jacob 5 Expires: 6 May 2021 C. S. Perkins 6 University of Glasgow 7 2 November 2020 9 Describing TCP with Augmented Packet Header Diagrams 10 draft-mcquistin-augmented-tcp-example-00 12 Abstract 14 This document describes TCP, and a number of its extensions, using 15 Augmented Packet Header Diagrams. This document is an example of the 16 Augmented Packet Header Diagram language: it is not intended as a 17 contribution to any ongoing or future work on maintaining or 18 extending TCP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 6 May 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. TCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Comparison with draft-ietf-tcpm-rfc793bis . . . . . . . . . . 7 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 60 8. Informative References . . . . . . . . . . . . . . . . . . . 8 61 Appendix A. Source code repository . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 This document uses Augmented Packet Header Diagrams 67 [AUGMENTED-DIAGRAMS] to describe TCP [RFC793], and is intended to 68 further discussion about the design and implementation of the 69 Augmented Packet Header Diagram language and tooling. Given this 70 purpose, this document is not intended as a contribution to any 71 ongoing or future work on maintaining or extending TCP. Further, 72 this document does not necessarily reflect TCP, and its extensions, 73 as presently standardised. 75 2. TCP Header 77 This document describes the TCP protocol. The TCP protocol uses TCP 78 Headers. 80 A TCP Header is formatted as follows: 82 0 1 2 3 83 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 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 | Source Port | Destination Port | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 | Sequence Number | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Acknowledgment Number | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | Data | |C|E|U|A|P|R|S|F| | 92 | Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window Size | 93 | | |R|E|G|K|H|T|N|N| | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Checksum | Urgent Pointer | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | [Options] | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | : 100 : Payload : 101 : | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 where: 106 Source Port: 16 bits. The source port number. 108 Destination Port: 16 bits. The destination port number. 110 Sequence Number: 32 bits. The sequence number of the first data 111 octet in this segment (except when the SYN flag is set). If SYN 112 is set the sequence number is the initial sequence number (ISN) 113 and the first data octet is ISN+1. 115 Acknowledgment Number: 32 bits. If the ACK control bit is set, this 116 field contains the value of the next sequence number the sender of 117 the segment is expecting to receive. Once a connection is 118 established, this is always sent. 120 Data Offset (DOffset): 4 bits. The number of 32 bit words in the TCP 121 Header. This indicates where the data begins. The TCP header 122 (even one including options) is an integral number of 32 bits 123 long. 125 Reserved (Rsrvd): 4 bits. A set of control bits reserved for future 126 use. Must be zero in generated segments and must be ignored in 127 received segments, if corresponding future features are 128 unimplemented by the sending or receiving host. 130 CWR: 1 bit. Congestion Window Reduced 132 ECE: 1 bit. ECN-Echo 134 URG: 1 bit. Urgent Pointer field significant 136 ACK: 1 bit. Acknowledgment field significant. 138 PSH: 1 bit. Push Function (see the Send Call description) 140 RST: 1 bit. Reset the connection 142 SYN: 1 bit. Synchronize sequence numbers 144 FIN: 1 bit. No more data from sender. 146 Window Size: 16 bits. The number of data octets beginning with the 147 one indicated in the acknowledgment field that the sender of this 148 segment is willing to accept. 150 The window size MUST be treated as an unsigned number, or else 151 large window sizes will appear like negative windows and TCP will 152 not work (MUST-1). It is RECOMMENDED that implementations will 153 reserve 32-bit fields for the send and receive window sizes in the 154 connection record and do all window computations with 32 bits 155 (REC- 1). 157 Checksum: 16 bits. The checksum field is the 16 bit one's complement 158 of the one's complement sum of all 16 bit words in the header and 159 text. The checksum computation needs to ensure the 16-bit 160 alignment of the data being summed. If a segment contains an odd 161 number of header and text octets, alignment can be achieved by 162 padding the last octet with zeros on its right to form a 16 bit 163 word for checksum purposes. The pad is not transmitted as part of 164 the segment. While computing the checksum, the checksum field 165 itself is replaced with zeros. 167 Urgent Pointer: 16 bits. This field communicates the current value 168 of the urgent pointer as a positive offset from the sequence 169 number in this segment. The urgent pointer points to the sequence 170 number of the octet following the urgent data. This field is only 171 be interpreted in segments with the URG control bit set. 173 Options: [TCP Option]; Options#Size == (DOffset-5)*32; present 174 only when DOffset > 5. Options may occupy space at the end of the 175 TCP header and are a multiple of 8 bits in length. All options 176 are included in the checksum. 178 Payload. Payload. 180 3. TCP Options 182 A TCP Option is one of: a EOL Option, a NOOP Option, a Maximum 183 Segment Size Option, a Window Scale Factor Option, a Timestamp 184 Option, or a SACK Permitted Option. 186 An EOL Option is formatted as follows: 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | 0 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 where: 196 Option Kind (Kind): 1 byte; Kind == 0. This option code indicates 197 the end of the option list. 199 A NOOP Option is formatted as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | 1 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 where: 209 Option Kind (Kind): 1 byte; Kind == 1. This option code can be used 210 between options, for example, to align the beginning of a 211 subsequent option on a word boundary. 213 A Maximum Segment Size Option is formatted as follows: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | 2 | Length | Maximum Segment Size (MSS) | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 where: 223 Option Kind (Kind): 1 byte; Kind == 2. If this option is present, 224 then it communicates the maximum receive segment size at the TCP 225 endpoint that sends this segment. 227 Option Length (Length): 1 byte; Length == 4. Option length. 229 Maximum Segment Size (MSS): 2 bytes. The maximum segment size 230 allowed. 232 A Window Scale Factor Option is formatted as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | 3 | Length | Window Scale Factor | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 where: 242 Option Kind (Kind): 1 byte; Kind == 3. If present, this option 243 carries the window scale factor. 245 Option Length (Length): 1 byte; Length == 3. Option length. 247 Window Scale Factor: 1 byte. Window scale factor. 249 A Timestamp Option is formatted as follows: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | 8 | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Timestamp value (TSval) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Timestamp echo reply (TSecr) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 where: 263 Option Kind (Kind): 1 byte; Kind == 8. If present, this option 264 carries a timestamp and an echoed timestamp. 266 Option Length (Length): 1 byte; Length == 10. Option length. 268 Timestamp value (TSval): 4 bytes. TSval. 270 Timestamp echo reply (TSecr): 4 bytes. TSecr. 272 A SACK Permitted Option is formatted as follows: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 4 | Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 where: 282 Option Kind (Kind): 1 byte; Kind == 4. If present, this option 283 indicates that SACK is permitted. 285 Option Length (Length): 1 byte; Length == 2. Option length. 287 4. Comparison with draft-ietf-tcpm-rfc793bis 289 While the purpose of this document is to give an example use of the 290 Augmented Packet Header Diagrams, and not to contribute to ongoing or 291 future TCP standardisation efforts, it is instructive to draw 292 comparisons with documents that describe the same protocol. In 293 particular, the descriptions of the TCP header (Section 2) and TCP 294 options (Section 3) from this document can be compared with 295 Section 3.1 of [draft-ietf-tcpm-rfc793bis]. We have adopted the same 296 field descriptions to help with this comparison. 298 Beyond the broad similarities, there are a number of elements where 299 this document describes the protocol differently. For example, the 300 TCP header as defined in [draft-ietf-tcpm-rfc793bis] contains a 301 variable-length padding field which is not present in the description 302 contained in this document. The Padding field is used to pad the TCP 303 header to a 32-bit boundary, and to ensure that the Payload begins on 304 a 32-bit boundary. The length of the Padding field is the difference 305 between the value of the Data Offset field and the length of the 306 Options field. However, the length of the Options field is itself 307 dependent on the value of the Data Offset field and the particular 308 set of options contained within an instance of the TCP header. The 309 Augmented Packet Header Diagram format cannot express this logic: the 310 lengths of both the Padding and Payload fields would be variable. To 311 overcome this, as shown in Section 2, the description of TCP given in 312 this document relies upon End of List options being syntactically 313 identical to Padding (i.e., being all zeroes). This highlights the 314 limitations of the Augmented Packet Header Diagram format: prose text 315 is much more expressive. 317 However, the precision required by the Augmented Packet Header 318 Diagram can be beneficial. For example, the description of the 319 Options field in this document sets out an explicit length and 320 presence constraint, where [draft-ietf-tcpm-rfc793bis] indicates that 321 it is "variable". Similar constraints exist in the description given 322 in [draft-ietf-tcpm-rfc793bis], but they are contained with the prose 323 description of the field. 325 In summary, the most striking comparison to be made is that the 326 description of TCP given in this document is largely similar to that 327 given in [draft-ietf-tcpm-rfc793bis]. By retaining the overall 328 structure of a packet header diagram and an accommpanying list of 329 descriptions for each field, the Augmented Packet Header Diagram 330 format is close to that already in use. This is encouraging: it 331 indicates that the Augmented Packet Header Diagram language can be 332 used to describe realistic protocols, without introducing a format 333 that is unfamiliar or difficult to write. 335 5. IANA Considerations 337 This document contains no actions for IANA. 339 6. Security Considerations 341 The security implications of the Augmented Packet Header Diagrams 342 format are considered in [AUGMENTED-DIAGRAMS]. 344 7. Acknowledgements 346 This work has received funding from the UK Engineering and Physical 347 Sciences Research Council under grant EP/R04144X/1. 349 8. Informative References 351 [AUGMENTED-DIAGRAMS] 352 McQuistin, S., Band, V., Jacob, D., and C. S. Perkins, 353 "Describing Protocol Data Units with Augmented Packet 354 Header Diagrams", Work in Progress, Internet-Draft, draft- 355 mcquistin-augmented-ascii-diagrams-07, 2 November 2020, 356 . 359 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 360 September 1981, . 362 [draft-ietf-tcpm-rfc793bis] 363 Eddy, W., "Transmission Control Protocol (TCP) 364 Specification", Work in Progress, Internet-Draft, draft- 365 ietf-tcpm-rfc793bis-19, 27 October 2020, 366 . 369 Appendix A. Source code repository 371 The source code for tooling that can be used to parse this document, 372 and generate parser code for the protocol it describes, is available 373 from https://github.com/glasgow-ipl/ips-protodesc-code. 375 Authors' Addresses 377 Stephen McQuistin 378 University of Glasgow 379 School of Computing Science 380 Glasgow 381 G12 8QQ 382 United Kingdom 384 Email: sm@smcquistin.uk 386 Vivian Band 387 University of Glasgow 388 School of Computing Science 389 Glasgow 390 G12 8QQ 391 United Kingdom 393 Email: vivianband0@gmail.com 395 Dejice Jacob 396 University of Glasgow 397 School of Computing Science 398 Glasgow 399 G12 8QQ 400 United Kingdom 402 Email: d.jacob.1@research.gla.ac.uk 403 Colin Perkins 404 University of Glasgow 405 School of Computing Science 406 Glasgow 407 G12 8QQ 408 United Kingdom 410 Email: csp@csperkins.org