idnits 2.17.1 draft-yourtchenko-tcp-loic-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2011) is 4735 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1671' is defined on line 181, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tcpm A. Yourtchenko 3 Internet-Draft Cisco 4 Intended status: Informational April 11, 2011 5 Expires: October 13, 2011 7 Introducing TCP Long Options by Invalid Checksum 8 draft-yourtchenko-tcp-loic-00 10 Abstract 12 This document discusses a possible approach to TCP option space 13 expansion, which allows placing the long TCP options into the TCP SYN 14 segments. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 13, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 52 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Proposed High-level Approach . . . . . . . . . . . . . . . . . 3 54 5. Implementation Details . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 60 9.2. Informational References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 What this document IS NOT: the definitive guide, the review of the 66 existing solutions, the full description of the option space upgrade, 67 the review of the existing solutions. 69 What this document IS: a write-up of an idea for a building block to 70 be used as part of a bigger protocol - intended for information 71 purposes and further development only - verifying the feasibility of 72 this approach will need extensive experiments. 74 2. Notational Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 3. Problem Statement 82 The TCP options are the mechanism which is used to evolve the TCP 83 protocol - thanks to their existence, such additions as Selective 84 Acknowledgements and Timestamps [refs tbd] (to name just a couple) 85 were introduced. However, the space in the TCP segment where the 86 options may be transmitted is very scarce and is currently at the 87 borderline of being exhausted. This practically blocks any further 88 development in the TCP protocol space. 90 In order for the TCP development to continue, we need a way to 91 dedicate a larger storage space for TCP options within the segment - 92 further referred as TCP Long Options. 94 A mechanism for doing that must fulfil at least two prerequisites: 95 transmission of the Long Options within the TCP SYN, and a graceful 96 fallback to the 'legacy' mechanism in case the Long Options can not 97 be used (thus abandoning all of the Long Options). 99 The above two are to certain extent at odds with each other - the SYN 100 is the very first segment within the TCP session, so any drastic 101 change that is misunderstood by the remote party or the middleboxes 102 will cause the segment to be dropped, thus interrupting the 103 communication. 105 4. Proposed High-level Approach 107 The proposal is to transmit two SYN segments instead of one, created 108 with different goals in mind: the first one, aimed at backwards 109 compatibility, would merely signal the sender's desire to use Long 110 Options. The second SYN segment, aimed at the parties that 111 understand the new mechanism, would contain the Long Options 112 themselves. The Long Options would be in place where there normally 113 is data (there's simply no other space) - so this segment, together 114 with the first one, would form a contradiction from the perspective 115 of the TCP protocol, if interpreted by the unaware node. 117 To mitigate the above issue, we can explicitly mark the second SYN as 118 "TCP-invalid". The simplest way to do this is to increment the valid 119 TCP checksum by 2. With such a modification, the second packet will 120 be either dropped by a middlebox that does not support the new 121 method, or by the destination node itself - if the destionation does 122 not support this method. 124 On the other hand, if the stack supports the new method for the Long 125 Options, it can treat the first segment as a partial duplicate of the 126 second - thus allowing to upgrade the protocol behaviour. (NB: the 127 overall upgrade protocol is a much larger problem and is out of scope 128 for this document). 130 5. Implementation Details 132 Allocate two new TCP options: a 4 bytes long "LOIC-FLAG" and a 4 133 bytes long "LOIC-LEN" (Long Options with Invalidated Checksum). 135 The first one is aimed into inclusion into the 'compatible segments' 136 to signal that the system understands the long options mechanism, as 137 well as later possibly be used as a signaling mechanism about the 138 end-to-end connectivity for the Long Options segments. The goal here 139 is to minimize the potential of the disruption for the existing 140 applications. 142 The two bytes of usable payload of the second option will hold the 143 length of the TCP Long Options area (zero being an allowed value and 144 meaning there is no Long Options at all). The TCP Long Options area 145 will be placed between the end of the 'classic' TCP header and the 146 beginning of the TCP segment data. The presence of this option will 147 mean that before verifying the TCP checksum, one MUST decrement the 148 received value by 2 - and only then verify the checksum. To allow 149 more efficiency in the implementations, this option MUST be the first 150 TCP option within the segment - this way the analysis of the TCP 151 checksum would not be impacted too much. 153 6. Security Considerations 155 [[Placeholder.]] 157 7. Acknowledgements 159 The concept of using the invalid checksum came up during one of the 160 discussions with Dan Wing about an unrelated matter. Thanks to 161 following individuals for the initial discussions about this idea: 162 Wesley Eddy, Alan Ford, Anantha Ramaiah, Fernando Gont [[ Please 163 remind me who I forgot, I forgot a few folks for sure ]] 165 8. IANA Considerations 167 This document, being informational, has no IANA actions. However, 168 its derivatives that adopt the described approach, would have an 169 action to update the registry of the TCP options to include the LOIC- 170 FLAG and LOIC-LEN definitions. 172 9. References 174 9.1. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 9.2. Informational References 181 [RFC1671] Carpenter, B., "IPng White Paper on Transition and Other 182 Considerations", RFC 1671, August 1994. 184 Author's Address 186 Andrew Yourtchenko 187 Cisco Systems, Inc. 188 De Kleetlaan, 7 189 Diegem B-1831 190 Belgium 192 Email: ayourtch@cisco.com