Presented by: ilker Basaran

1. TCP Congestion Control with a Misbehaving Receiver (1999)Stefan Savage, Neal Cardwell, David Wetherall, Tom AndersonACM Computer Communications Review Presented by: ilker Basaran

2. Roadmap • Introduction • Quick Review of TCP congestion control • Vulnerabilities – Types of Attack • Implementation Results • Proposed Solutions • Current Situation • Conclusion

3. Introduction & Previous Work • TCP end-to-end congestion control mechanism implicitly rely on decent endpoints to decide proper data rate. • But misbehaving senders can send data more quickly, forcing competing traffic to be delayed or discarded. Interestingly, receivers can do the same, too! • This problem mentioned before [APS99, PAD+99] but not fully appreciated. • Note that # of receivers is extremely large (all Internet users) and has both the incentive (faster download) and opportunity (open source OSes) to exploit this vulnerability.

4. Introduction (cont’d) • Previously, the trust between sender and receiver hasn’t been studied in context of congestion control. • Traditional cryptographic security mechanisms, such as IPSEC [KA98], can provide authentication and confidentiality but, can not prevent a receiver from violating TCP’s congestion control specification. • Since the interests of sender and receiver may differ considerably, they may exploit this vulnerability and undermine the fairness and stability provided by TCP congestion control. • The potential congestion resulting from aggressive senders has received significant attention [She94, FF99, RHE99, VRC98]. • But it’s unlikely that such mechanisms will be widely deployed in the near term, so it’s still necessary to consider the potential impact of misbehaving receivers.

5. Introduction (cont’d) • What authors propose: • Identify several vulnerabilities of TCP congestion control that can be exploited by a malicious receiver • Modify the design of TCP to eliminate this behavior so that a malicious receiver can at most cause a sender to transmit data at a slower rate.

6. Quick Review of TCP Congestion Control • Connection-oriented, reliable, ordered, byte-stream protocol with explicit flow control • Divides data into SMSS (Sender Maximum Segment Size), and labels with sequence #s to guarantee ordering and reliability • When a host receives in-sequence segment, it sends an ACK, if an out-of-sequence segment is received, it sends next expected sequence # • If no ACK received within a timeout, sender transmits again

7. TCP Congestion Control Algorithms • Both Slow Start and Congestion Avoidance controls sending rate by manipulating a congestion window (cwnd) • Slow Start: • Quickly increase and decrease cwnd to roughly approximate the bottleneck capacity (exponential) • Congestion Avoidance: • Fine tuning. Increase cwnd more slowly to probe additional bandwidth that may become available. (linear)

8. Vulnerabilities • Three types of attack: • ACK division • DupACK spoofing • Optimistic ACKing • In addition to DoS attacks, these techniques can be used to enhance attacker’s throughput at the expense of behaving clients.

9. Attack #1: ACK Division • RFC 2581 (most recent TCP congestion control specification at the time of this paper) states During slow start, TCP increments cwnd by at most SMSS bytes for each ACK received that acknowledges new data … During congestion avoidance, cwnd is incremented by one full-sized segment per RTT (round trip time) • The discord between the byte granularity of error control and the segment granularity of congestion control leads to vulnerability.

10. Attack #1: ACK Division • The Attack: • When you receive a data segment with N bytes • Divide corresponding ACK into M pieces, where M  N • Each separate ACK covers one of M distinct pieces of received data

11. Attack #1: ACK Division • Each ACK is valid since it covers data that was sent and previously unacknowledged • This leads the sender to grow cwnd M times faster than usual • Receiver can control this rate of growth, maximum M = N • As seen in the example, after one RTT, cwnd = 4, instead of the expected value of 2 Sample time line for ACK division attack.

12. Implementation Results of ACK Division • 24 lines of code added to original code • HTTP request for index.html from cnn.com • This attack can convince a TCP sender to send all of its data in send buffer in a single burst. Single burst of data TCP handshake starts and ends First HTTP data from server and many small ACKs from receiver

13. Attack #2: DupACK Spoofing • TCP uses two algorithms, fast retransmit and fast recovery, to decrease the effects of packet loss • Quoted from RFC 2581 Set cwnd to ssthresh plus 3*SMSS. This artificially “inflates” the congestion window by the number of segments (3) that have left the network and which the receiver has buffered. … For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the cwnd in order to reflect the additional segment that has left the network.

14. Attack #2: DupACK Spoofing • Two problems with this approach • Byte vs. segment granularity problem • TCP requires exact duplicate ACKs, therefore it’s impossible to understand which data segment they correspond to. • There’s no way to differentiate a valid duplicate ACK with a spoofed one

15. Attack #2: DupACK Spoofing • The Attack • When you receive a data segment, send lots of ACKs for the last sequence # received (at a start of a connection, this would be for the SYN segment)

16. Attack #2: DupACK Spoofing • The first four ACKs for the same sequence # cause the sender to retransmit the first segment. • However, cwnd is increased by SMSS for each additional duplicate, for a total of 4 segments • Since duplicate ACKs are indistinguishable, this attack is also valid. Sample time line for DupACK attack.

17. Implementation Results of DupACK • 11 lines of code added to original code • The receiver sends sufficient duplicate ACKs s.t. the sender enters fast recovery and fills the receiver’s flow control window each RTT. • Like ACK Division, this attack also can convince a TCP sender to send all of its data in send buffer in a single burst Single burst of data First HTTP data from server and many duplicate ACKs from receiver TCP handshake starts and ends

18. Attack #3: Optimistic ACKing • Since TCP’s cwnd growth is a function of RTT (exponential during slow start, linear during congestion avoidance), sender-receiver pairs with shorter RTT will transfer data more quickly • Hence, it’s possible for a receiver to emulate a shorter RTT by sending ACKs optimistically for data it has not received yet

19. Attack #3: Optimistic ACKing • The Attack: • When you receive a data segment, send lots of ACKs anticipating data that will be sent by the sender • This attack does not preserve end-to-end reliability, e.g. if a packet is lost, it’s unrecoverable • However, new features in HTTP-1.1 allows receivers to request particular byte ranges • So, data is gathered on one connection and lost segments are then collected selectively with application layer re-transmissions

20. Attack #3: Optimistic ACKing • What makes Optimistic ACKing more dangerous • After reaching to bottleneck rate, a receiver sends ACKs in spite of losses • By concealing losses, it eliminates the only congestion signal available to sender • A malicious attacker can conceal all losses and leads the sender to increase cwnd indefinitely

21. Attack #3: Optimistic ACKing • Since senders generally send full-sized segments, it’s easy for a receiver to guess the correct sequence # to use in ACKs, but this accuracy is not mandatory • If an ACK arrives for the data that has not yet been sent, this is generally ignored by sender – allowing the receiver to be more aggressive Sample time line for Optimistic ACKing attack.

22. Implementation Results of Optimistic ACKing • 45 lines of code added to original code • Whenever the periodic timer (10 ms) expires, or a new data segment arrives, receiver sends a new optimistic ACK • The result is that the data transfer using optimistic ACKs completes approximately half the normal transfer time. Stream of early ACKs convinces the sender to send data much earlier than it normally would

23. Applicability • Vulnerabilities of nine Web servers running diverse array of popular server operating systems • Linux 2.2 is not vulnerable to ACK Division, because it increases its cwnd only if at least one whole previously unACKed segment is ACKed • Linux 2.0 refuses to count duplicate ACKs until cwnd is greater than 3, therefore DupACK fails if initiated on connection startup. But this attack works if started later, so an N is also put. • Windows NT is immune to DupACK attacks, because of its apparent bug that causes it to rarely enter fast recovery.

24. Roadmap – where are we ? • Introduction • Quick Review of TCP congestion control • Vulnerabilities – Types of Attack • Implementation Results • Proposed Solutions • Current Situation • Conclusion

25. Solutions • Inspiration from Prudent Engineering Practice for Cryptographic Protocols [AN96], which we have read earlier. • Since the vulnerabilities arise from unstated assumptions, obeying principles may solve the problems : • Every message should say what it means: the interpretation of the message should depend only on its content • The condition for a message to be acted upon should be clearly set out so that someone reviewing a design may see whether they are acceptable or not. • If the identity of a principal is essential to the meaning of a message, it’s convenient to mention the principal’s name explicitly in the message

26. Solution to ACK Division • Ambiguity about how ACKs should be interpreted – violation of 2nd principle • Two obvious solutions • Increment cwnd only proportional to the amount of data ACKed • Discussed in [All98, All99] • Increment cwnd by one SMSS only when a valid ACK arrives covering the entire data segment sent • This technique is being used by Linux 2.2.x

27. Solution to DupACK Spoofing • Since the meaning of duplicate ACK is implicit and difficult to verify, it violates 1st principle. • So the traditional method to guarantee association between data segments and ACKs is using a nonce. • Two new fields into TCP packet format; Nonce and Nonce Reply • Sender fills Nonce field with unique random number • Receiver generates an ACK in response to a particular data segment, and puts the received nonce into Nonce Reply field • This Singular Nonce approach is similar to Timestamps option, but with two important differences: • Nonce preserves association for duplicate ACKs, Timestamps does not • Timestamps is an option, so misbehaving clients has the choice not to use it

28. Problem with this solution • The fix requires the modification of clients and servers and addition of two TCP fields • The purely backward compatible solutions that are sender only heuristics can mitigate, but not eliminate, the impact of this attack. • Maintain a count of outstanding segments sent above the missing segment, then decrease for each duplicate ACK. After reaching zero, ignore any additional duplicate ACK. • But, a clever receiver can ACK the missing segment and then repeat the process indefinitely • Suggestion by [Flo95]: sender may refuse to enter fast retransmit multiple times in a single window

29. Solution to Optimistic ACKing • ACKs do not contain any proof regarding the identity of the data segment(s) that caused them to be sent, so the violation of 3rd principle. • The cumulative property of TCP’s sequence #s ensures that the most recent ACK can cover all previously sent data. In order to use this property, Cumulative Nonce is described as follows: • Sender fills Nonce field with unique random number • Each side maintains a nonce sum representing the cumulative sum of all in-sequence ACKed nonces. • A receiver either echoes the current value of the nonce sum for in-sequence data, or echoes the nonce value sent by the sender for out-of-sequence data

30. Example to this solution • The fourth data segment is lost and a third ACK attempts to conceal this loss by ACKing a later segment • But the ACK will be refused since it cannot provide the correct nonce sum (149) Sample time line for a transfer using a cumulative nonce

31. A potential problem • Segment boundaries may differ between initial transmission and subsequent retransmissions, such as in dynamic path MTU (maximum transmission unit) change • A solution is randomly subdivide the original nonce in such a way that the sum of new nonce values is still consistent with original one. • If initially 1460 bytes is sent with nonce 14, then subsequent retransmissions limited to 536 bytes by a path MTU change, data may be sent in three packets with nonces 7, 3 and 4.

32. Alternative Solutions • Instead of major modifications, sender-side modifications that can approximate a singular nonce may limit the impact of optimistic ACK attacks. • If sender randomly varies the size of outgoing segments by a small amount, a misbehaving receiver will not be able to guess correct segment boundaries. • So the exact segment boundaries form a nonce and the sender can filter out optimistic ACKs as those do not fall on the appropriate sequence #s • A sender may discourage malicious receivers by sending a RST for any ACK that acknowledges data not yet sent. This does not prevent loss concealment but can mitigate impacts of optimistic ACKs, which may be a more attractive attack for the average user

33. Current Situation • RFC 3390 – Increasing TCP's Initial Window • Update to RFC 2581 - Proposed Standard, October 2002 • “This document specifies a small change to TCP that will likely be beneficial to short-lived TCP connections” [RFC 3390] • Not so much related to misbehaving receivers

34. Current Situation • RFC 3465 • TCP Congestion Control with Appropriate Byte Counting (ABC) • Experimental Standard, February 2003 • Directly related to the problem stated in this paper • “This document proposes a modification to the algorithm for increasing TCP's congestion window (cwnd) that improves both performance and security. Rather than increasing a TCP's congestion window based on the number of acknowledgments (ACKs) that arrive at the data sender, the congestion window is increased based on the number of bytes acknowledged by the arriving ACKs. ” [RFC 3465]

35. Conclusion • TCP has designed for cooperative environments and thus contains several vulnerabilities. • Authors’ described three types of attack (ACK Division, DupACK Spoofing, Optimistic ACKing) that exploit these vulnerabilities. • The design of TCP can be modified, without changing the nature of congestion control function, to eliminate these vulnerabilities. Authors’ approach is Cumulative Nonce, which requires modification of TCP all senders and receivers. • Authors also identified and described sender-only modifications that can be used immediately and mitigate the affect of possible attacks

36. References • [All98] Mark Allman. On the generation and use of TCP acknowledgments. Computer Communications Review,28(5), October 1998. • [All99] Mark Allman. TCP byte counting refinements. Computer Communications Review, 29(3), July 1999. • [AN96] Martin Abadi and Roger Needham. Prudent engineering practice for cryptographic protocols. IEEE Transactions on Software Engineering, 22(1), January 1996. • [APS99] M. Allman, V. Paxson, and W. Stevens. TCP congestion control. RFC 2581, April 1999. • [FF99] Sally Floyd and Kevin Fall. Promoting the use of end-to-end congestion control in the Internet. IEEE/ACM Transactions on Networking, August 1999. • [Flo95] Sally Floyd. TCP and successive fast retransmits. http://www.aciri.org/floyd/papers/fastretrans.ps, May 1995. • [KA98] S. Kent and R. Atkinson. Security architecture for the internet protocol. RFC 2401, November 1998. • [PAD+99] V. Paxson, M. Allman, S. Dawson, W. Fenner,J. Griner, I. Heavens, K. Lahey, J. Semke, and B. Volz.Known TCP implementation problems. RFC 2525, March 1999. • [RHE99] Reza Rejaie, Mark Handley, and Deborah Estrin. RAP: An end-to-end rate-based congestion control mechanism for real-time streams in the Internet. In INFOCOM '99 • [She94] Scott Shenker. Making greed work in networks: A game-theoretic analysis of switch service disciplines. In SIGCOMM '94, pages 47–57, August 1994. • [VRC98] L. Vivisano, L. Rizzo, and J. Crowcroft. TCP-like congestion control for layered multicast data transfer. In INFOCOM '98, April 1998. • http://www.zvon.org – for RFC documents

37. End Of Presentation Thanks for your time… Questions | Comments?