idnits 2.17.1 draft-shepard-tcp-reassign-port-number-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 9. -- Found old boilerplate from RFC 3978, Section 5.5 on line 262. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 254), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 175: '...r, and the server MUST ensure that the...' RFC 2119 keyword, line 182: '... The client MAY, upon any retransmis...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2004) is 7225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tim Shepard 3 INTERNET DRAFT July 12, 2004 4 Expires: January 13, 2005 6 By submitting this Internet-Draft, I certify that any applicable 7 patent or other IPR claims of which I am aware have been disclosed, 8 or will be disclosed, and any of which I become aware will be 9 disclosed, in accordance with RFC 3668. 11 Reassign Port Number option for TCP 12 draft-shepard-tcp-reassign-port-number-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 Most TCP connections are protected from spoofing attacks from off- 42 path attackers by their obscurity. This memo suggests that the few 43 TCP connections that aren't so protected today may be protected by 44 making them obscure by using random values for both port numbers. 45 The obvious difficulty with this approach is that the well-known port 46 number is required on the initial SYN to connect to the desired 47 service. A TCP option is proposed which can be used during the SYN 48 and SYN-ACK exchange to request (and accomplish) reassignment of the 49 well known port number to a random value. 51 Introduction 53 Communication on the Internet today typically involves no end-to-end 54 cryptography and is therefore secured only as much as the entire path 55 of routers and links between the two communicating parties is 56 secured. More robust methods of securing end-to-end communication 57 involving cryptography have been developed but have only seen limited 58 deployment. Most communication on the Internet today remains 59 vulnerable to an attacker who is located somewhere along the path of 60 communication. 62 In the past few months a vulnerability of TCP connections to an off- 63 path attacker has raised concern. An attacker who merely knows of or 64 can surmise the existence of an active TCP connection can inject 65 packets into the connection with forged source addresses (making 66 packets arrive at one host with a source address which makes it 67 appear to have come from the other host), disrupting communication in 68 a variety of ways. These injected packets could come from distant 69 parts of the Internet, and tracing the true origin of packets with 70 forged source addresses can be difficult. 72 Even if the attacker's knowledge of the existence of the connection 73 is imperfect, the attacker may cover the unknown space rather quickly 74 by injecting many packets covering all of the possibilities. 76 To know completly of the existence of a TCP connection, an attacker 77 would need to know the IP addresses of the two endpoints and the two 78 16-bit TCP port numbers in use by the TCP connection. If this much 79 is known to an attacker, then the only hurdle remaining for the 80 attacker's forged packets is the sequence number acceptability test 81 where the 32-bit sequence number in the TCP header of the arriving 82 packet is tested to see if it is in-window. 84 The RFC1323 window scale option, makes the fraction of TCP sequence 85 space that is acceptable potentially quite large (as much as 1/4 of 86 the 32-bit sequence number space). 88 The RFC1323 timestamp option would seem to help, but packets without 89 the RFC1323 timestamp option can still cause disruption---RSTs 90 without a timestamp option generally need to be accepted and 91 processed (e.g. in case a dialup user hangs up and a new dialup user 92 sends RSTs in response to arriving TCP packets). Also note that no 93 known implementations include a timestamp option on RST packets. 95 In most cases, TCP connections as implemented and used by 96 applications today are robust against spoofing attacks simply because 97 the attacker has no way of learning or knowing of the existence of 98 the TCP connection (identified by the two IP addresses and the two 99 16-bit port numbers). The vulnerability comes when the off-path 100 attacker can, for a long-lived TCP connection, obtain or surmise the 101 IP addresses and port numbers involved, or sufficiently narrow the 102 possibilities so that the search space is small enough to allow the 103 attacker to exhaustively enumerate the remaining possibilities. In 104 particular, this can happen if the IP addresses involved and one of 105 the port numbers are known, leaving only one 16-bit port number 106 unknown. In the case of some services listening on a well-known port 107 (such as BGP, SSH, or XMPP), this situation is typical. 109 This memo suggest that the way to secure TCPs from spoofed packets 110 sent by off-path attackers is: 112 1. Don't reveal the port numbers, and 114 2. Use good random values for both port numbers. 116 The difficulty with doing this today is that typically a well-known 117 port number is used to find the server, and this would be difficult 118 to change. The remainder of this memo describes a TCP option which 119 can be used to negotiate a reassignment of the well-known port number 120 to a randomly assigned value as part of the SYN/SYN-ACK handshake 121 that occurs at the beginning of the connection. 123 The Reassign Port Number option carried on the SYN 125 A client wishing to have the server reassign the well-known port 126 number to a random value may include a Reassign Port Number option on 127 the segment that carries the SYN. 129 +---------+---------+ 130 | Kind=99 |Length=2 | 131 +---------+---------+ 133 (note: 99 is here as a place holder until an IANA assignment) 135 This option requests that the server reassign the port it will use 136 for this connection to a random value. The Destination Port field in 137 the TCP header itself will carry the normal well-known port number on 138 which the server is expected to be listening. 140 If the server does not implement this option, it will be ignored, and 141 the TCP connection will continue without any reassignment of port 142 numbers. 144 The Reassign Port Number option carried on the SYN ACK 146 If a server receives a SYN carrying the Reassign Port Number option, 147 then it will (as usual) use the Destination Port field in the segment 148 carrying the SYN to identify which listening socket it should be 149 associated with, but when creating the established socket, it may (if 150 it implements this option) reassign a random value to the local port 151 number, and return a SYN ACK with the newly assigned port number, and 152 include the Reassign Port Number option with the SYN ACK: 154 +---------+---------+---------+---------+ 155 | Kind=99 |Length=4 | original port num | 156 +---------+---------+---------+---------+ 158 (note: 99 is here as a place holder until an IANA assignment) 160 This SYN ACK will be received by the host that sent the SYN with the 161 Reassign Port Number request, and will have a pair of port numbers in 162 the TCP header which will not correspond to the port numbers in any 163 connection block the host has. The option, however, will provide the 164 client with the original port number of the server and allow the 165 connection block to be found. The client should process this 166 option on a SYN ACK when it fails to find a corresponding connection 167 block for TCP segment with both the SYN and ACK control bits turned 168 on. If the ACK of the client's SYN is correct, then the connection 169 block on the client can have the foreign port number overwritten with 170 the Source Port number from the TCP header. 172 Note that until the server receives an ACK of its SYN, and for some 173 time after that, it will need to be prepared to process any received 174 retransmissions of the original SYN which would still be directed at 175 the listening port number, and the server MUST ensure that the 176 processing of any such duplicate SYNs gets the same reassignment, 177 even if the duplicate SYNs do not carry the Reassign Port Number 178 option. 180 Steps a client may take to ensure robustness 182 The client MAY, upon any retransmission of the SYN, try removing the 183 Reassign Port Number option. A better strategy to cope with a broken 184 path (e.g. containing a NAT or some other connection tracking 185 middlebox that does not understand the remapping) would be for the 186 client, upon failure to establish a connection with the Reassign Port 187 Number option, would be to retry the connection from a new port 188 number without the Reassign Port Number option. 190 Implementors should carefully consider whether or not this option 191 should be on by default for all TCP connections. Most TCP 192 connections are already protected by their natural obscurity and/or 193 short lifetime. Setting this option on by default in a general 194 purpose operating system would probably cause many more failed 195 connections due to the meddling of middleboxes than connections saved 196 from spoofing attacks. In other words, there is potential to do more 197 harm then good. 199 Applications (such as BGP, JABBER, and perhaps SSH) may benefit from 200 code which explicitly requests the use of this option and carefully 201 manages the fallback to a connection attempt without this option. 203 Firewall and NAT considerations 205 (More thought may be needed here.) 207 Simple sorts of firewalls that disallow incoming TCP segments which 208 do not have an ACK control bit set (to disallow the initiation of TCP 209 connections from machines beyond the firewall) should not cause any 210 problem for this scheme. 212 Firewalls that track TCP connections, and NATs, will need to be aware 213 of this option and track the connection to the new port number. Any 214 such firewalls or NATs on the path that have not been upgraded to 215 handle this option will likely cause connection attempts using this 216 option to fail. 218 Upgrading firewalls and NATs to track this option should be 219 straightforward. (The simplest upgrade to a firewall that avoids 220 blocking connection attempts carrying this option would be to simply 221 strip this option from the TCP SYN segment, though that would leave 222 such connections more vulnerable to spoofed packets.) 224 Security Considerations 226 This memo describes a method of making it more difficult for an off- 227 path attacker to slip a spoofed packet into a TCP connection by 228 randomizing the port numbers involved (including what would normally 229 be a well-known port number), and recommends that the port numbers 230 not be revealed publicly (e.g. through any publicly-readable network 231 management databases). This method provides only a limited 232 enhancement of security, and does not come close to the robustness 233 that can be achieved by techniques employing end-to-end encryption of 234 the TCP segments (such as IPSEC). 236 IANA Considerations 238 A single new TCP option value will need to be assigned for the 239 Reassign Port Number option described above. 241 Author's Address: 243 Tim Shepard 244 122 Beech Street 245 Belmont, MA 02478 247 +1 617 489 7135 248 shep@alum.mit.edu 250 Full Copyright Statement 252 Copyright (C) The Internet Society (2004). This document is subject 253 to the rights, licenses and restrictions contained in BCP 78, and 254 except as set forth therein, the authors retain all their rights. 256 This document and the information contained herein are provided on an 257 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 258 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 259 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 260 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 261 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 262 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.