idnits 2.17.1 draft-lvelvindron-ack-throttling-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 11, 2018) is 2053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Velvindron 3 Internet-Draft September 11, 2018 4 Intended status: Informational 5 Expires: March 15, 2019 7 Handling of TCP ACK throttling 8 draft-lvelvindron-ack-throttling-03 10 Abstract 12 The functionality provided by the TCP ACK throttling mechanism can be 13 exploited as a side channel vulnerablity to terminate connections 14 between two arbitrary hosts and inject data in the communication 15 stream. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 15, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Recommendation for ACK throttling mechanism . . . . . . . . . 3 54 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 57 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1. Introduction 62 [RFC5961] defines the challenge ACK response mechanism as a technique 63 to mitigate against blind in-window attacks. Specifically, an ACK 64 packet is sent in response to an incoming segment with a SYN bit to 65 confirm that the preceding connection was lost. Another case is 66 sending an ACK packet if the RST packet is received but the sequence 67 number does not match the next expected sequence number. Lastly, to 68 prevent data injection, the range of valid ACK value is reduced for 69 better strictness, so the likelihood of old ACK values and very new 70 ACK values are discarded. In all of those cases, the ACK packet is 71 referrered to as a "Challenge ACK" through the rest of this document. 73 [RFC5961] also introduces an ACK throttling mechanism to reduce 74 possible wastage of CPU and bandwidth resources by limiting the 75 number of challenge ACK that can be sent in a given interval. 77 An attacker can leverage the Challenge ACK and the ACK throttling 78 mechanism to abuse on the global ACK throttling rate-limit on a 79 target host. Through a series of step, the attacker can send spoofed 80 packets to the target host, affect the the global challenge ACK rate- 81 limiter, count the number of challenge ACK received, and finally 82 compare that number with the target system limit. 84 The attacker can then gather clues about: the existence of a 4-tuple 85 connection, the next expected sequence number, and the expected ACK 86 number. 88 Based on the gathered information, the attacker can mount connection 89 reset attacks and data injection attacks. Those attacks have been 90 demonstrated to work in real-world constraints according to [CBR01]. 92 1.1. Terminology 94 Challenge ACK in this document denotes the ACK packet sent in 95 response to an segment whose RST bit is set and the sequence number 96 does not fully match the next expected sequence value, but is within 97 the current receive window as defined in [RFC5961]. 99 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 101 document, are to be interpreted as described in [RFC2119]. 103 2. Recommendation for ACK throttling mechanism 105 An implementation SHOULD have a per-socket ACK throttling mechanism 106 which is not shared across the system. This makes it more difficult 107 to abuse compared to having a single (global) ACK throttling 108 mechanism. Additionally, an implementation may also introduce a 109 randomized value to the interval defined in Section 7 of [RFC5961]. 110 This makes the attacks defined in section 1 much more difficult. 112 3. Operations 114 It will take time to update all of the TCP implementations that fully 115 implement the ACK throttling mechanism as described in [RFC5961]. 117 An operator can increase the value of the ACK throttling limit to the 118 highest value possible to mitigate the risk of the vulnerabilities 119 defined in section 1. 121 4. IANA Considerations 123 None of the proposed measures have an impact on IANA. 125 5. Security Considerations 127 The purpose of this document is to document security improvements to 128 the ACK throttling mechanism and also how an operator can mitigate 129 side channel vulnerabilities. Specific examples of those 130 vulnerabilities can be found in [CBR01]. In particular, the ACK 131 throttling mechanism leads to a side-channel vulnerability that can 132 be leveraged for connection reset and data injection attacks. A 133 description of this functionality can be found in section 1. 135 6. Normative References 137 [CBR01] Cao, Y., Wang, Z., Dao, T., Krishnamurthy, S., and L. 138 Marvel, "Off-Path TCP Exploits: Global Rate Limit 139 Considered Dangerous", University of California , 2016. 141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 142 Requirement Levels", BCP 14, RFC 2119, 143 DOI 10.17487/RFC2119, March 1997, 144 . 146 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 147 Robustness to Blind In-Window Attacks", RFC 5961, 148 DOI 10.17487/RFC5961, August 2010, 149 . 151 Author's Address 153 Loganaden Velvindron 154 88 Avenue De Plevitz Roches Brunes 155 Rose Hill 71259 156 Mauritius 158 Phone: +230 59762817 159 Email: loganaden@gmail.com