Subject: Treatment of invalid bundlings in SCTP

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 12 Feb 2004 17:22:47 -0500

Hi

I am new to SCTP and find myself re-reading the SCTP RFC and
implementors guide many-a-time to figure out certain behaviors.

I am currently looking at the results of some the tests I had
and am noticing that a behavior for processing invalid bundlings
has not been specified in either rfc 2960 or the sctpimpguide-10.

I am not sure if this is the right place to bring it up, but I figure
most of the people in the know hang out here.

Anyway, the bundling that I consider invalid are the ones that
are stated in the RFC as 'MUST NOT'.  For example:

Section 3.3.7
"DATA chunks MUST NOT be bundled with ABORT."

Section 6
"Control chunks MUST come before DATA chunks in the packet."

Section 6.10 in it's entirety.

The problem that I see is that there is no enforcement.  It looks
like the implementers guide specified behavior related to INIT chunks,
but what is an implementation to do when processing other invalid
bundles?

Some places in the specification recommend ignoring the packet, others
recommend ignoring the chunk.

Additionally, the Pastel principle can be applied (which seems to be what
Linux is doing).

I am just curious if this has come up before?

-vlad
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Linux and Open Source Lab
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 12 Feb 2004 17:41:21 -0700

Vladislav,

> recommend ignoring the chunk.

Strange.  Could you cite one?  I don't see any recommendations, I only
see requirements.  Such as: "If the receiver detects a partial chunk,
it MUST drop the chunk."

> Additionally, the Pastel principle can be applied (which seems to be what

The requirement in 2960 is "An endpoint MUST process received chunks in
their order in the packet." and I think this is what most do: process
chunks until there is an error beyond which the receiver cannot continue.

Beyond that, aborting the association is brutal and ignoring errors might
be more forgiving (Pastel?), but its up to the implementation.  I prefer
the be strict on what you send and forgiving on what you receive approach.
> I am just curious if this has come up before?

I think the general question comes up quite often and normally
gets a similar answer.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 13 Feb 2004 10:01:48 -0500

[resending to the list. got rejected the first time]

Brian

Thanks for an answer.  What I was trying
to say (and I guess it did not come out right :)
is that there seem to be no enformcement of
certain MUSTs.

As and example, what do you do if you get a bundled
DATA and SHUTDOWN chunks.  The specs essentially says:
"don't bundle them".  Should a robust imlementation:
  1. accept the data
  2. accept shutdown
  3. accept both
  4. ignore both.

I am not saying to abort the association.  That's harsh, as you
said.  I am just wondering what should be done in this case.

MUSTs in an RFC usually require a form of conformance and
that conformance needs to be tested.  By lacking these tests,
we have a potential of introducing interoperability problems.

-vlad

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 13 Feb 2004 09:35:02 -0600

> is that there seem to be no enformcement of

In general if your peer MUST do something it does
NOT mean that you MUST enforce it. Rather it means
that you MAY assume that they comply.

That's the spirit of being flexible in what you
accept. The major exception is that you SHOULD NOT
accept anything that is non compliant, *if* doing
so can create any form of security vulnerability.

So a lot depends on how easy something is to detect.
Only accepting Control Chunks at the beginning of
a packet is very simple. Detecting illegal gaps in
Stream Sequence Numbers (there are 5 missing Stream
Sequence Numbers for stream X, but based on TSNs
there are only 2 missing Data Chunks) would be
quite difficult and something the receiver probably
SHOULD NOT do.

But in general, restrictions on your peer are
supposed to make your task *easier*,  not harder.
That's why the restriction was created.

-- 
Caitlin Bestler - [email-masked] - http://asomi.com/

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 13 Feb 2004 16:29:49 +0100

Hi Vladislav,

see my comments below.

Best regards
Michael

> is that there seem to be no enformcement of
Yes.
> DATA and SHUTDOWN chunks.  The specs essentially says:
First of, it depends on the sequence of the chunks. I'm
assuming SHUTDOWN first, DATA second.
> "don't bundle them".  Should a robust imlementation:
An implementation is free to make plausibility checks first
and find that this is an illegal packet. It is allowed to
drop the packet. You can send an ABORT or an ERROR or nothing.

If you do not do a complete scan first, you process the packet
from the beginning. The first you see is a SHUTDOWN chunk,
you process it and the state of the assoc becomes SHUTDOWN-RECEIVED
if you have outstanding data. If not you can schedule a SHUTDOWN-ACK
chunk for sending and the state of the assoc becomes SHUTDOWN-ACK-SENT.
Now you process the DATA chunk. You receive DATA for an assoc in
SHUTDOWN-RECEIVED state or SHUTDOWN-ACK_SENT state. You can now
decide to ABORT the assoction, send an ERROR or just silently discard
the DATA chunk. In any case, the user DATA should not be accepted and
given to the SCTP user.