Subject: [Tsvwg] Question: the right way to update ARWND in "zero window probe" phase

From: "Andrey Konstantinov" <[email-masked]>
Date: Mon, 27 Oct 2008 19:58:39 +0300

Hi experts!

In RFC4960 we can see the rule:
   An SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data.
And my questions are:

For receiving side:
Does it mean that SCTP MAY generate SACK even DATA chunk is not received
previously but user consumed the data covered by receive space?
So, SCTP generates two SACKs: the first with arwnd=0 and the second with the
same CumACK but we nonzero arwnd.
It is actual question for zero probing because interval could be long and
cause additional delays in data transmission.

For sending side:
Does it mean that SCTP SHALL be able to process more than one SACK per sent
packet with DATA? Currently our SCTP drops the second packet even if it
provides updated arwnd (SCTP considers it as stale, because there are no
data in flight and TSN is already reported in the previous SACK)

Also I am interested how the situation is regulated with the possible attack
on resources if SCTP should process more than one SACK per packet.
(Maybe I am not right, because I have not tried to reproduce it myself)
For example, how the case is protected in theory?
1. Side A sends to side B packets, Side B is congested. So, side A stops
traffic (zero probing is activated).
2. Attacker sends SACK to side A (emulating source IP address from side B)
with nonzero arwnd and Side A begins to send a lot of data to side B to
consume new arwnd, side B drops the incoming DATA reporting arwnd=0.
3. Attacker repeats the action => the same flood.
Suppose that it is unreal case, due to it is difficult to match and control
actually valid CumACK point for all times when SACK is emulated by the
attacker. Is it only one limitation for attacker which allows to avoid the
attack scenario in practice?

Thanks in advance,
Andrey Konstantinov

---

From: Randy Stewart <[email-masked]>
Date: Mon, 27 Oct 2008 13:27:02 -0400

Andrey:

On Oct 27, 2008, at 12:58 PM, Andrey Konstantinov wrote:

> Does it mean that SCTP MAY generate SACK even DATA chunk is not  
> received previously but user consumed the data covered by receive  
> space?
> So, SCTP generates two SACKs: the first with arwnd=0 and the second  
> with the same CumACK but we nonzero arwnd.
> It is actual question for zero probing because interval could be  
> long and cause additional delays in data transmission.

Yes, an SCTP receiver can send additional "rwnd update" sacks even  
though no changes
have occurred in the CUM-ACK or GAP-ACK blocks that the last sack  
reported.

In the BSD implementation we do this on a proportion of the rwnd..  
every time
we have updated the rwnd more than a set percentage we send a window  
update sack
that does not report any new information about received data, but  
instead
tells the sender the app has read more so more data can be sent.

>
> For sending side:
> Does it mean that SCTP SHALL be able to process more than one SACK  
> per sent packet with DATA? Currently our SCTP drops the second  
> packet even if it provides updated arwnd (SCTP considers it as  
> stale, because there are no data in flight and TSN is already  
> reported in the previous SACK)

Yes, an SCTP sender SHOULD ALWAYS process the SACK if the cumack is >  
or == to the
last cumack. Even if the sack is identical, the rwnd should be updated  
so that
the sender can send more (potentially). Note that the sender SHOULD  
NOT update
the rwnd or anything if the cumack is smaller than the last cumack  
received..

i.e.

send             rcv
TSN1 ->
TSN2 ->
TSN3 ->
TSN4 ->
   <---SACK(4)
  (delayed) <----SACK(2)

The second SACK should be ignored.

If its
TSN1 ->
TSN2 ->
  <-- SACK(2)
  <-- SACK(2)

Then both sack's should be processed the second would only update
the rwnd..

>
> Also I am interested how the situation is regulated with the  
> possible attack on resources if SCTP should process more than one  
> SACK per packet.
> 1. Side A sends to side B packets, Side B is congested. So, side A  
> stops traffic (zero probing is activated).
> 2. Attacker sends SACK to side A (emulating source IP address from  
> side B) with nonzero arwnd and Side A begins to send a lot of data  
> to side B to consume new arwnd, side B drops the incoming DATA  
> reporting arwnd=0.

And where did Attacker get the V-tag to do this?

If you tell me that attacker is sniffing, you have greater problems
then this attack. If you tell me that they guessed the vtag I would
say the attacker is a very lucky guy to be able to guess 1 in 4billion  
value
(either that or the implementation does not use good quality random  
numbers).

> 3. Attacker repeats the action => the same flood.

The vtag protects you for blind attacks.. also note that TCP has the  
same issue only
they don't have a vtag here.

R

>
> Suppose that it is unreal case, due to it is difficult to match and  
> control actually valid CumACK point for all times when SACK is  
> emulated by the attacker. Is it only one limitation for attacker  
> which allows to avoid the attack scenario in practice?