Subject: [Tsvwg] SCTP reaction on wrong behaviour from remote side.

From: "Andrey Konstantinov" <[email-masked]>
Date: Mon, 30 Jul 2007 13:05:49 +0400

Hi,

I have a question, because I can not find the answer in RFC 2960.

SCTP have installed association with remote side.
Reported Initiation Tag is 657476287 (in INIT ACK chunk),
First incoming DATA chunk from remote side has Transmission Sequence Number
657476287 and Stream Sequence Number: 4 (HAVE TO be equal to 0).
It is a fault from remote side, but how SCTP should respond on this on local
side?

We have applied (while) solution when SCTP sends ABORT chunk (reason:
protocol violation), but it is required much CPU time to detect this
situation. Should SCTP detect and check this situation/condition?
Without solution SCTP collects incoming data (does not provide this to SCTP
user) unless receiveSpace is null (after that zero probe state (arwnd =
0) reported to remote side according to RFC).

Could you explain right solution?

Best regards,
Andrey Konstantinov

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 30 Jul 2007 11:39:54 +0200

Hi Andrey,

I think an SCTP implementation should check for this and send
an ABORT with error cause 'Protocol Violation'. It may take some
CPU time to handle this, but your other solution would take
memory on your side for an indefinite amount of time...

Best regards
Michael

On Jul 30, 2007, at 11:05 AM, Andrey Konstantinov wrote:

> First incoming DATA chunk from remote side has Transmission  
> Sequence Number 657476287 and Stream Sequence Number: 4 (HAVE TO be  
> equal to 0).
> It is a fault from remote side, but how SCTP should respond on this  
> on local side?
>
> We have applied (while) solution when SCTP sends ABORT chunk  
> (reason: protocol violation), but it is required much CPU time to  
> detect this situation. Should SCTP detect and check this situation/ 
> condition?
> Without solution SCTP collects incoming data (does not provide this  
> to SCTP user) unless receiveSpace is null (after that zero probe  
> state (arwnd = 0) reported to remote side according to RFC).
>

---

From: Stephane Chazelas <[email-masked]>
Date: Mon, 30 Jul 2007 10:56:51 +0100

> memory on your side for an indefinite amount of time...

Hi Andrey, Michael,

why is it so bad and why should a stack care that the ssn
doesn't start with 0. I thought that to insure in sequence
delivery, looking at TSNs (and B,E,U bits) should be enough. Why
would you wait for SSNs 0, 1, 2, 3 here? Is a stack allowed to
send ssn 4 before ssn 3 (that is with a lower TSN in the chunks
of ssn 4 than in ssn 3)?

> >First incoming DATA chunk from remote side has Transmission Sequence Number 657476287 and Stream Sequence Number: 4 (HAVE TO be equal to 0).
> >It is a fault from remote side, but how SCTP should respond on this on local side?
> >
> >We have applied (while) solution when SCTP sends ABORT chunk (reason: protocol violation), but it is required much CPU time to detect this situation. Should SCTP detect and check 
> >this situation/condition?
> >Without solution SCTP collects incoming data (does not provide this to SCTP user) unless receiveSpace is null (after that zero probe state (arwnd = 0) reported to remote side 
> >according to RFC).

Cheers,
Stephane

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 30 Jul 2007 08:48:17 -0600

Stephane,

Stephane Chazelas wrote:                                          (Mon, 30 Jul 2007 10:56:51)
> send ssn 4 before ssn 3 (that is with a lower TSN in the chunks

It does not make sense to do so in the first TSN sent.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 30 Jul 2007 17:39:34 +0200

Hi Stephane,

you must know where your sequence numbers start to identify
the first message.

Assume that you do not know where the SSN starts, and you
are missing the first TSN, then you are not able to deliver
any message on any stream, because you do not know for
which message you have to waiting.

The initial value for the TSNs is negotiated during the
association setup, the initial value for the SSN is
defined by the protocol specification as 0.

Best regards
Michael

On Jul 30, 2007, at 11:56 AM, Stephane Chazelas wrote:

>>> Sequence Number 657476287 and Stream Sequence Number: 4 (HAVE TO  
>>> be equal to 0).
>>> detect this situation. Should SCTP detect and check
>>> Without solution SCTP collects incoming data (does not provide  
>>> this to SCTP user) unless receiveSpace is null (after that zero  
>>> probe state (arwnd = 0) reported to remote side
>>> according to RFC).
>
> Cheers,
> Stephane
>
>
>

---

From: Stephane Chazelas <[email-masked]>
Date: Mon, 30 Jul 2007 16:55:18 +0100

On Mon, Jul 30, 2007 at 05:39:34PM +0200, Michael Tuexen wrote:
[...]
> which message you have to waiting.
[...]

Thanks, yes, of course, that makes sense.

However, if one sends its first tsn with a non-zero ssn, then
it's broken, same if one sends tsn x with ssn y and tsn x+1 with
ssn y+2, I don't think there's a point in checking that as that
won't happen in real life, and if it does happen, aborting the
association is yes smarter than hanging it with a full window
but the end result will be the same: the peer stack needs to be
fixed.

And if one wants to fill up a receive window in some DOS
attempt, then there are plenty of other ways to do it, so why
bother avoiding this one?

Cheers,
Stephane

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 30 Jul 2007 18:25:55 +0200

Hi Stephane,

comments in-line.

Best regards
Michael

> but the end result will be the same: the peer stack needs to be
I agree, the peer stack needs to be fixed.
> bother avoiding this one?
There are two points here:
1. I guess that the peer stack will not figure out that
    it has a problem. The local stack can figure that out.
    So I think the best behaviour is to abort the association.
    The only alternative would be to let the association
    stay forever, if the the application layer does not
    resolve it or to wait until the application layer aborts
    the association.
2. Yes there are plenty of ways for a malicious attacker
    but I think the best way to handle this is to abort
    the association as soon as you figured out that you
    peer is an attacker.