TCP%20Congestion%20Control%20with%20a%20Misbehaving%20Receiver%20(1999)%20Stefan%20Savage,%20Neal%20Cardwell,%20David%20Wetherall,%20Tom%20Anderson%20ACM%20Computer%20Communications%20Review - PowerPoint PPT Presentation

Title: TCP%20Congestion%20Control%20with%20a%20Misbehaving%20Receiver%20(1999)%20Stefan%20Savage,%20Neal%20Cardwell,%20David%20Wetherall,%20Tom%20Anderson%20ACM%20Computer%20Communications%20Review


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, PAD99 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 (contd)

• Previously, the trust between sender and receiver
  hasnt 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 TCPs 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 its unlikely that such mechanisms will be
  widely deployed in the near term, so its still
  necessary to consider the potential impact of
  misbehaving receivers.

5
Introduction (contd)

• 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 attackers 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 3SMSS. 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 its
  impossible to understand which data segment they
  correspond to.
• Theres 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
  receivers 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 TCPs 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, its 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, its
  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,
  its 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, its convenient to
  mention the principals 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 TCPs 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/fas
  tretrans.ps, May 1995.
• KA98 S. Kent and R. Atkinson. Security
  architecture for the internet protocol. RFC 2401,
  November 1998.
• PAD99 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 4757,
  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?