tcp congestion control with a misbehaving receiver (1999) stefan savage, neal cardwell, david...

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

Upload: opal-martin

Post on 18-Dec-2015

220 views

Category:

Documents


0 download

TRANSCRIPT

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

TCP Congestion Control with a TCP Congestion Control with a Misbehaving Receiver (1999)Misbehaving Receiver (1999)

Stefan Savage, Neal Cardwell, David Wetherall, Tom Stefan Savage, Neal Cardwell, David Wetherall, Tom AndersonAnderson

ACM Computer Communications ReviewACM Computer Communications Review

Presented by: ilker BasaranPresented by: ilker Basaran

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

RoadmapRoadmap

IntroductionIntroduction Quick Review of TCP congestion Quick Review of TCP congestion

controlcontrol Vulnerabilities – Types of AttackVulnerabilities – Types of Attack Implementation ResultsImplementation Results Proposed SolutionsProposed Solutions Current SituationCurrent Situation ConclusionConclusion

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

Introduction & Previous Introduction & Previous WorkWork TCP end-to-end congestion control mechanism TCP end-to-end congestion control mechanism

implicitly rely on decent endpoints to decide proper implicitly rely on decent endpoints to decide proper data rate.data rate.

But misbehaving senders can send data more quickly, But misbehaving senders can send data more quickly, forcing competing traffic to be delayed or discarded. forcing competing traffic to be delayed or discarded. Interestingly, receivers can do the same, too!Interestingly, receivers can do the same, too!

This problem mentioned before [APS99, PADThis problem mentioned before [APS99, PAD++99] but 99] but not fully appreciated.not fully appreciated.

Note that # of receivers is extremely large (all Note that # of receivers is extremely large (all Internet users) and has both the incentive (Internet users) and has both the incentive (faster faster downloaddownload) and opportunity () and opportunity (open source OSesopen source OSes) to ) to exploit this vulnerability.exploit this vulnerability.

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

Introduction (cont’d)Introduction (cont’d) Previously, the trust between sender and receiver hasn’t been Previously, the trust between sender and receiver hasn’t been

studied in context of congestion control.studied in context of congestion control.

Traditional cryptographic security mechanisms, such as Traditional cryptographic security mechanisms, such as IPSEC [KA98], can provide authentication and confidentiality IPSEC [KA98], can provide authentication and confidentiality but, can not prevent a receiver from violating TCP’s but, can not prevent a receiver from violating TCP’s congestion control specification.congestion control specification.

Since the interests of sender and receiver may differ Since the interests of sender and receiver may differ considerably, they may exploit this vulnerability and considerably, they may exploit this vulnerability and undermine the fairness and stability provided by TCP undermine the fairness and stability provided by TCP congestion control.congestion control.

The potential congestion resulting from aggressive senders The potential congestion resulting from aggressive senders has received significant attention [She94, FF99, RHE99, has received significant attention [She94, FF99, RHE99, VRC98].VRC98].

But it’s unlikely that such mechanisms will be widely But it’s unlikely that such mechanisms will be widely deployed in the near term, so it’s still necessary to consider deployed in the near term, so it’s still necessary to consider the potential impact of misbehaving receivers.the potential impact of misbehaving receivers.

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

Introduction (cont’d)Introduction (cont’d)

What authors propose:What authors propose:

Identify several vulnerabilities of TCP Identify several vulnerabilities of TCP congestion control that can be exploited congestion control that can be exploited by a malicious receiverby a malicious receiver

Modify the design of TCP to eliminate Modify the design of TCP to eliminate this behavior so that a malicious receiver this behavior so that a malicious receiver can at most cause a sender to transmit can at most cause a sender to transmit data at a slower rate.data at a slower rate.

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

Quick Review of TCP Quick Review of TCP Congestion ControlCongestion Control Connection-oriented, reliable, ordered, Connection-oriented, reliable, ordered, byte-stream protocol with explicit flow controlbyte-stream protocol with explicit flow control Divides data into SMSS (Sender Maximum Divides data into SMSS (Sender Maximum

Segment Size), and labels with sequence #s Segment Size), and labels with sequence #s to guarantee ordering and reliabilityto guarantee ordering and reliability

When a host receives in-sequence segment, When a host receives in-sequence segment, it sends an ACK, if an out-of-sequence it sends an ACK, if an out-of-sequence segment is received, it sends next expected segment is received, it sends next expected sequence #sequence #

If no ACK received within a timeout, sender If no ACK received within a timeout, sender transmits againtransmits again

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

TCP Congestion Control TCP Congestion Control AlgorithmsAlgorithms Both Both Slow StartSlow Start and and Congestion AvoidanceCongestion Avoidance

controls sending rate by manipulating a controls sending rate by manipulating a congestion window (congestion window (cwndcwnd))

Slow Start:Slow Start: Quickly increase and decrease cwnd to roughly Quickly increase and decrease cwnd to roughly

approximate the bottleneck capacity (exponential)approximate the bottleneck capacity (exponential)

Congestion Avoidance:Congestion Avoidance: Fine tuning. Increase cwnd more slowly to probe Fine tuning. Increase cwnd more slowly to probe

additional bandwidth that may become available. additional bandwidth that may become available. (linear)(linear)

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

VulnerabilitiesVulnerabilities

Three types of attack:Three types of attack: ACK divisionACK division DupACK spoofingDupACK spoofing Optimistic ACKingOptimistic ACKing

In addition to DoS attacks, these In addition to DoS attacks, these techniques can be used to enhance techniques can be used to enhance attacker’s throughput at the expense attacker’s throughput at the expense of behaving clients.of behaving clients.

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

Attack #1: ACK DivisionAttack #1: ACK Division RFC 2581 (RFC 2581 (most recent TCP congestion control specification most recent TCP congestion control specification

at the time of this paperat the time of this paper) states) statesDuring slow start, TCP increments cwnd by at most During slow start, TCP increments cwnd by at most

SMSS SMSS bytesbytes for each ACK received that for each ACK received that acknowledges new dataacknowledges new data

……During congestion avoidance, cwnd is incremented During congestion avoidance, cwnd is incremented

by one by one full-sized segmentfull-sized segment per RTT (round trip time) per RTT (round trip time) The discord between the byte granularity The discord between the byte granularity

of error control and the segment of error control and the segment granularity of congestion control leads to granularity of congestion control leads to vulnerability.vulnerability.

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

Attack #1: ACK DivisionAttack #1: ACK Division

The Attack:The Attack: When you receive a data segment with When you receive a data segment with

N bytesN bytes Divide corresponding ACK into M Divide corresponding ACK into M

pieces, where M pieces, where M N N Each separate ACK covers one of M Each separate ACK covers one of M

distinct pieces of received datadistinct pieces of received data

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

Attack #1: ACK DivisionAttack #1: ACK Division

Sample time line for ACK division attack.

•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

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

Implementation Results of Implementation Results of ACK DivisionACK Division 24 lines of code added to 24 lines of code added to

original codeoriginal code

HTTP request for HTTP request for index.html from cnn.comindex.html from cnn.com

This attack can convince a This attack can convince a TCP sender to send all of TCP sender to send all of its data in send buffer in a its data in send buffer in a single burst.single burst.

TCP handshake starts and ends

First HTTP data from server and many small

ACKs from receiver

Single burst of data

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

Attack #2: DupACK Attack #2: DupACK SpoofingSpoofing TCP uses two algorithms, fast retransmit and fast TCP uses two algorithms, fast retransmit and fast

recovery, to decrease the effects of packet lossrecovery, to decrease the effects of packet loss Quoted from RFC 2581Quoted 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.

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

Attack #2: DupACK Attack #2: DupACK SpoofingSpoofing Two problems with this approachTwo problems with this approach

Byte vs. segment granularity problemByte vs. segment granularity problem

TCP requires exact duplicate ACKs, TCP requires exact duplicate ACKs, therefore it’s impossible to understand therefore it’s impossible to understand which data segment they correspond to.which data segment they correspond to. There’s no way to differentiate a valid There’s no way to differentiate a valid

duplicate ACK with a spoofed oneduplicate ACK with a spoofed one

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

Attack #2: DupACK Attack #2: DupACK SpoofingSpoofing The AttackThe Attack

When you receive a data segment, send When you receive a data segment, send lots of ACKs for the last sequence # lots of ACKs for the last sequence # received (at a start of a connection, this received (at a start of a connection, this would be for the SYN segment)would be for the SYN segment)

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

Attack #2: DupACK Attack #2: DupACK SpoofingSpoofing The first four ACKs for the The first four ACKs for the

same sequence # cause the same sequence # cause the sender to retransmit the first sender to retransmit the first segment.segment.

However, cwnd is increased However, cwnd is increased by SMSS for each additional by SMSS for each additional duplicate, for a total of 4 duplicate, for a total of 4 segmentssegments

Since duplicate ACKs are Since duplicate ACKs are indistinguishable, this attack indistinguishable, this attack is also valid.is also valid.

Sample time line for DupACK attack.

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

Implementation Results of Implementation Results of DupACKDupACK 11 lines of code added to 11 lines of code added to

original codeoriginal code

The receiver sends sufficient The receiver sends sufficient duplicate ACKs s.t. the duplicate ACKs s.t. the sender enters fast recovery sender enters fast recovery and fills the receiver’s flow and fills the receiver’s flow control window each RTT.control window each RTT.

Like ACK Division, this Like ACK Division, this attack also can convince a attack also can convince a TCP sender to send all of its TCP sender to send all of its data in send buffer in a data in send buffer in a single burstsingle burst

TCP handshake starts and ends

First HTTP data from server and many duplicate

ACKs from receiver

Single burst of data

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

Attack #3: Optimistic Attack #3: Optimistic ACKingACKing Since TCP’s cwnd growth is a function of RTT Since TCP’s cwnd growth is a function of RTT

(exponential during slow start, linear during (exponential during slow start, linear during congestion avoidance), sender-receiver pairs congestion avoidance), sender-receiver pairs with shorter RTT will transfer data more with shorter RTT will transfer data more quicklyquickly

Hence, it’s possible for a receiver to emulate Hence, it’s possible for a receiver to emulate a shorter RTT by sending ACKs optimistically a shorter RTT by sending ACKs optimistically for data it has not received yetfor data it has not received yet

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

Attack #3: Optimistic Attack #3: Optimistic ACKingACKing The Attack:The Attack:

When you receive a data segment, send lots of When you receive a data segment, send lots of ACKs anticipating data that will be sent by the ACKs anticipating data that will be sent by the sendersender

This attack does not preserve end-to-end reliability, This attack does not preserve end-to-end reliability, e.g. if a packet is lost, it’s unrecoverablee.g. if a packet is lost, it’s unrecoverable However, new features in HTTP-1.1 allows However, new features in HTTP-1.1 allows

receivers to request particular byte rangesreceivers to request particular byte ranges So, data is gathered on one connection and lost So, data is gathered on one connection and lost

segments are then collected selectively with segments are then collected selectively with application layer re-transmissionsapplication layer re-transmissions

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

Attack #3: Optimistic Attack #3: Optimistic ACKingACKing What makes Optimistic ACKing more What makes Optimistic ACKing more

dangerousdangerous After reaching to bottleneck rate, a After reaching to bottleneck rate, a

receiver sends ACKs in spite of lossesreceiver sends ACKs in spite of losses By concealing losses, it eliminates the By concealing losses, it eliminates the

only congestion signal available to only congestion signal available to sendersender

A malicious attacker can conceal all A malicious attacker can conceal all losses and leads the sender to increase losses and leads the sender to increase cwnd indefinitelycwnd indefinitely

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

Attack #3: Optimistic Attack #3: Optimistic ACKingACKing Since senders generally Since senders generally

send full-sized segments, send full-sized segments, it’s easy for a receiver to it’s easy for a receiver to guess the correct guess the correct sequence # to use in sequence # to use in ACKs, but this accuracy ACKs, but this accuracy is not mandatoryis not mandatory

If an ACK arrives for the If an ACK arrives for the data that has not yet data that has not yet been sent, this is been sent, this is generally ignored by generally ignored by sender – allowing the sender – allowing the receiver to be more receiver to be more aggressiveaggressive

Sample time line for Optimistic ACKing attack.

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

Implementation Results of Implementation Results of Optimistic ACKingOptimistic ACKing 45 lines of code added to 45 lines of code added to

original codeoriginal code

Whenever the periodic Whenever the periodic timer (10 ms) expires, or a timer (10 ms) expires, or a new data segment arrives, new data segment arrives, receiver sends a new receiver sends a new optimistic ACKoptimistic ACK

The result is that the data The result is that the data transfer using optimistic transfer using optimistic ACKs completes ACKs completes approximately half the approximately half the normal transfer time.normal transfer time.

Stream of early ACKs convinces the sender to send data much earlier

than it normally would

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

ApplicabilityApplicability Vulnerabilities of Vulnerabilities of

nine Web servers nine Web servers running diverse array running diverse array of popular server of popular server operating systemsoperating 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.

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

Roadmap – where are Roadmap – where are we ?we ? IntroductionIntroduction Quick Review of TCP congestion Quick Review of TCP congestion

controlcontrol Vulnerabilities – Types of AttackVulnerabilities – Types of Attack Implementation ResultsImplementation Results Proposed SolutionsProposed Solutions Current SituationCurrent Situation ConclusionConclusion

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

SolutionsSolutions Inspiration from Prudent Engineering Practice for Inspiration from Prudent Engineering Practice for

Cryptographic Protocols [AN96], which we have read Cryptographic Protocols [AN96], which we have read earlier.earlier.

Since the vulnerabilities arise from unstated assumptions, Since the vulnerabilities arise from unstated assumptions, obeying obeying principles principles may solve the problems :may solve the problems : Every message should say what it means: the interpretation Every message should say what it means: the interpretation

of the message should depend only on its contentof the message should depend only on its content The condition for a message to be acted upon should be The condition for a message to be acted upon should be

clearly set out so that someone reviewing a design may see clearly set out so that someone reviewing a design may see whether they are acceptable or not.whether they are acceptable or not.

If the identity of a principal is essential to the meaning of a If the identity of a principal is essential to the meaning of a message, it’s convenient to mention the principal’s name message, it’s convenient to mention the principal’s name explicitly in the messageexplicitly in the message

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

Solution to ACK DivisionSolution to ACK Division Ambiguity about how ACKs should be interpreted Ambiguity about how ACKs should be interpreted

– violation of 2– violation of 2ndnd principle principle

Two obvious solutionsTwo obvious solutions Increment cwnd only proportional to the amount of Increment cwnd only proportional to the amount of

data ACKeddata ACKed Discussed in [All98, All99]Discussed in [All98, All99]

Increment cwnd by one SMSS only when a valid Increment cwnd by one SMSS only when a valid ACK arrives covering the entire data segment sentACK arrives covering the entire data segment sent

This technique is being used by Linux 2.2.xThis technique is being used by Linux 2.2.x

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

Solution to DupACK Solution to DupACK SpoofingSpoofing

Since the meaning of duplicate ACK is implicit and difficult to Since the meaning of duplicate ACK is implicit and difficult to verify, it violates 1verify, it violates 1stst principle. principle.

So the traditional method to guarantee association between So the traditional method to guarantee association between data segments and ACKs is using a data segments and ACKs is using a noncenonce..

Two new fields into TCP packet format; Nonce and Nonce ReplyTwo new fields into TCP packet format; Nonce and Nonce Reply Sender fills Nonce field with unique random numberSender fills Nonce field with unique random number Receiver generates an ACK in response to a particular data segment, Receiver generates an ACK in response to a particular data segment,

and puts the received nonce into Nonce Reply fieldand puts the received nonce into Nonce Reply field

This Singular Nonce approach is similar to Timestamps This Singular Nonce approach is similar to Timestamps option, but with two important differences:option, but with two important differences:

Nonce preserves association for duplicate ACKs, Timestamps does Nonce preserves association for duplicate ACKs, Timestamps does notnot

Timestamps is an option, so misbehaving clients has the choice not Timestamps is an option, so misbehaving clients has the choice not to use itto use it

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

Problem with this Problem with this solutionsolution The fix requires the modification of clients and The fix requires the modification of clients and

servers and addition of two TCP fieldsservers and addition of two TCP fields The purely backward compatible solutions that The purely backward compatible solutions that

are sender only heuristics can mitigate, but not are sender only heuristics can mitigate, but not eliminate, the impact of this attack.eliminate, the impact of this attack. Maintain a count of outstanding segments sent Maintain a count of outstanding segments sent

above the missing segment, then decrease for each above the missing segment, then decrease for each duplicate ACK. After reaching zero, ignore any duplicate ACK. After reaching zero, ignore any additional duplicate ACK.additional duplicate ACK.

But, a clever receiver can ACK the missing segment But, a clever receiver can ACK the missing segment and then repeat the process indefinitelyand then repeat the process indefinitely

Suggestion by [Suggestion by [Flo95Flo95]: sender may refuse to enter ]: sender may refuse to enter fast retransmit multiple times in a single windowfast retransmit multiple times in a single window

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

Solution to Optimistic Solution to Optimistic ACKingACKing ACKs do not contain any proof regarding the identity of ACKs do not contain any proof regarding the identity of

the data segment(s) that caused them to be sent, so the the data segment(s) that caused them to be sent, so the violation of 3violation of 3rdrd principle. principle.

The cumulative property of TCP’s sequence #s ensures The cumulative property of TCP’s sequence #s ensures that the most recent ACK can cover all previously sent that the most recent ACK can cover all previously sent data. In order to use this property, data. In order to use this property, Cumulative Nonce Cumulative Nonce is is described as follows:described as follows: Sender fills Nonce field with unique random numberSender fills Nonce field with unique random number Each side maintains a nonce sum representing the cumulative Each side maintains a nonce sum representing the cumulative

sum of all in-sequence ACKed nonces.sum of all in-sequence ACKed nonces. A receiver either echoes the current value of the nonce sum for A receiver either echoes the current value of the nonce sum for

in-sequence data, or echoes the nonce value sent by the sender in-sequence data, or echoes the nonce value sent by the sender for for out-of-sequence dataout-of-sequence data

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

Example to this solutionExample to this solution The fourth data segment The fourth data segment

is lost and a third ACK is lost and a third ACK attempts to conceal this attempts to conceal this loss by ACKing a later loss by ACKing a later segmentsegment

But the ACK will be But the ACK will be refused since it cannot refused since it cannot provide the correct provide the correct nonce sum (149)nonce sum (149)

Sample time line for a transfer using a cumulative nonce

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

A potential problemA potential problem Segment boundaries may differ between initial Segment boundaries may differ between initial

transmission and subsequent retransmissions, transmission and subsequent retransmissions, such as in dynamic path MTU (maximum such as in dynamic path MTU (maximum transmission unit) changetransmission unit) change

A solution is randomly subdivide the original A solution is randomly subdivide the original nonce in such a way that the sum of new nonce nonce in such a way that the sum of new nonce values is still consistent with original one.values is still consistent with original one. If initially 1460 bytes is sent with nonce 14, then If initially 1460 bytes is sent with nonce 14, then

subsequent retransmissions limited to 536 bytes by a subsequent retransmissions limited to 536 bytes by a path MTU change, data may be sent in three packets path MTU change, data may be sent in three packets with nonces 7, 3 and 4.with nonces 7, 3 and 4.

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

Alternative SolutionsAlternative Solutions Instead of major modifications, sender-side modifications Instead of major modifications, sender-side modifications

that can approximate a singular nonce may limit the that can approximate a singular nonce may limit the impact of optimistic ACK attacks.impact of optimistic ACK attacks.

If sender randomly varies the size of outgoing segments by a If sender randomly varies the size of outgoing segments by a small amount, a misbehaving receiver will not be able to small amount, a misbehaving receiver will not be able to guess correct segment boundaries.guess correct segment boundaries.

So the exact segment boundaries form a nonce and the sender So the exact segment boundaries form a nonce and the sender can filter out optimistic ACKs as those do not fall on the can filter out optimistic ACKs as those do not fall on the appropriate sequence #sappropriate sequence #s

A sender may discourage malicious receivers by sending a A sender may discourage malicious receivers by sending a RST for any ACK that acknowledges data not yet sent. This RST for any ACK that acknowledges data not yet sent. This does not prevent loss concealment but can mitigate does not prevent loss concealment but can mitigate impacts of optimistic ACKs, which may be a more impacts of optimistic ACKs, which may be a more attractive attack for the average userattractive attack for the average user

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

Current SituationCurrent Situation

RFC 3390 – Increasing TCP's Initial RFC 3390 – Increasing TCP's Initial Window Window

Update to RFC 2581 - Proposed Update to RFC 2581 - Proposed Standard, October 2002Standard, October 2002

““This document specifies a small change This document specifies a small change to TCP that will likely be beneficial to to TCP that will likely be beneficial to short-lived TCP connections” [RFC 3390]short-lived TCP connections” [RFC 3390]

Not so much related to misbehaving Not so much related to misbehaving receiversreceivers

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

Current SituationCurrent Situation RFC 3465RFC 3465

TCP Congestion Control with Appropriate Byte Counting TCP Congestion Control with Appropriate Byte Counting (ABC)(ABC)

Experimental Standard, February 2003Experimental Standard, February 2003 Directly related to the problem stated in this paperDirectly related to the problem stated in this paper

““This document proposes a modification to the algorithm This document proposes a modification to the algorithm for increasing TCP's congestion window (cwnd) that for increasing TCP's congestion window (cwnd) that improves both improves both performance and securityperformance and security. Rather than . Rather than increasing a TCP's congestion window based on the increasing a TCP's congestion window based on the number of acknowledgments (ACKs) that arrive at the number of acknowledgments (ACKs) that arrive at the data sender, the congestion window is increased based data sender, the congestion window is increased based on the on the number of bytesnumber of bytes acknowledged by the arriving acknowledged by the arriving ACKs. ” [RFC 3465]ACKs. ” [RFC 3465]

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

ConclusionConclusion TCP has designed for cooperative environments and thus TCP has designed for cooperative environments and thus

contains several vulnerabilities.contains several vulnerabilities.

Authors’ described three types of attack (ACK Division, Authors’ described three types of attack (ACK Division, DupACK Spoofing, Optimistic ACKing) that exploit these DupACK Spoofing, Optimistic ACKing) that exploit these vulnerabilities.vulnerabilities.

The design of TCP can be modified, without changing the The design of TCP can be modified, without changing the nature of congestion control function, to eliminate these nature of congestion control function, to eliminate these vulnerabilities. Authors’ approach is Cumulative Nonce, vulnerabilities. Authors’ approach is Cumulative Nonce, which requires modification of TCP all senders and receivers.which requires modification of TCP all senders and receivers.

Authors also identified and described sender-only Authors also identified and described sender-only modifications that can be used immediately and mitigate the modifications that can be used immediately and mitigate the affect of possible attacksaffect of possible attacks

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

ReferencesReferences [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

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

End Of PresentationEnd Of Presentation

Thanks for your time…Thanks for your time…

Questions Questions || Comments? Comments?