TCP Daytona and Fragroute?!?

From: Jeremy Junginger (jjungingerat_private)
Date: Tue Oct 29 2002 - 08:28:59 PST

  • Next message: Federico Romeo: "Fw: wu-ftpd glob vulnerability"

    Hey guys,
    
    In playing with fragroute, I got curious about this "TCP Daytona" and
    began researching the ability to take advantage of the operation of
    TCP's congestion control, slow start, fast retransmit, and fast recovery
    to "hog bandwidth" for tcp sessions. I've read the following links:
    
    http://cgi.cs.duke.edu/~rebecca/HyperNews/get.cgi/eval_26/22.html?nogifs
    http://www.cs.washington.edu/homes/savage/papers/CCR99.pdf
    http://www.iaands.org/FTN/PI_Meetings/Jan_01/UWashington-Wetherall.ppt
    
    In summary, it appears that there are basically three ways to take
    advantage of the TCP stack to accomplish this, ACK division, DupACK
    spoofing, and Optimistic ACKing.  They are described briefly below:
    
    ACK Division:
    
    Mechanism:
    Slow Start: TCP can only increase the congestion window by SMSS (Sender
    Maximum Segment Size) bytes for each ACK received that acknowledges new
    data.
    Congestion Avoidance:  TCP increases the congestion window by 1 full
    sized segment per RTT (round-trip time).
    
    Exploit:
    By configuring a receiver to send x number of fragmented ACKs back to
    the host, the congestion window can be incremented a factor of x.
    
    DupACK spoofing:
    
    Mechanism:
    TCP uses fast retransmit and fast recovery to mitigate the risk of
    packet loss.
    Receipt of duplicate ACKs suggest that segments are leaving the network.
    For each additional duplicate ACK received, increment the congestion
    window by SMSS, artificially inflating the conestion window.
    
    Exploit:
    By configuring the receiver to send a long stream of acknowledgements
    for the last sequence number received (SYN segment), it is possible to
    increase the congestion window by 3 x SMSS.
    
    I'm not certain I understand the Optimistic ACKing, though.  It appears
    to be very similar to DupACK spoofing, but it appears to have more to do
    with acking for future sequence numbers rather than sending duplicate
    ACK's.  
    
    Have any of you played with the TCP stack on a Linux machine in order to
    demonstrate this capability?  The authors mention modifying the TCP
    subsystem on a 2.2.10 kernel, using:
    
    ACK division: 		24 lines of code
    DupACK spoofing: 		11 lines of code
    Optimistic ACKing: 	45 lines of code
    
    I seem to remember the folks at monkey.org working on a similar
    project....but I may just be crazy.  Anyhow, I'd be curious to hear your
    thoughts on the subject.
    
    
    -Jeremy
    



    This archive was generated by hypermail 2b30 : Tue Oct 29 2002 - 14:23:51 PST