Subject: Dynamic data in notifications

From: Anders Torger <[email-masked]>
Date: Sun, 22 Apr 2007 10:22:24 +0200

I have a few questions about the dynamic data in the notifications:

sac_info in SCTP_ASSOC_CHANGE, when it has the abort chunk, will it 
contain the type and length fields of it, or just the error codes?

The same question applies to SCTP_REMOTE_ERROR sre_data.

For the SCTP_SEND_FAILED event, it says that ssf_data contains:

"The undelivered message, exactly as delivered by the caller to the 
original send*() call."

If a large message has been sent using partial sending, how much of the 
message will be returned? The first or the last fragment sent?

/Anders Torger

---

From: Randall Stewart <[email-masked]>
Date: Sun, 22 Apr 2007 06:55:33 -0400

> contain the type and length fields of it, or just the error codes?
Hmm.. you should get the error cause/error message that came
in an abort.. and any user specified info (if it was passed).
Some stacks also will include a protocol-violation code and
some internal numbering that indicates where in their
stack the abort came from...

So there will be a type/length/data type thing here if
available .. but it may not be from the other end user
app .. unless the cause is USER_INITIATED_ABORT.

> The same question applies to SCTP_REMOTE_ERROR sre_data.

This should be quite rare.. but if you do get one it will
include the error cause and error number.. in the type/length
value format..
> message will be returned? The first or the last fragment sent?

Well.. I cannot speak for other stacks. BSD literally gives you
all of the message. Which means if you don't provide enough space
to read it in.. you get a PD-API scenario.. and no MSG_EOR on the
first read.. :-D

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Anders Torger <[email-masked]>
Date: Mon, 23 Apr 2007 11:47:38 +0200

> app .. unless the cause is USER_INITIATED_ABORT.

Perhaps I was not clear in the question, this is an abort chunk:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 6    |Reserved     |T|           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                   zero or more Error Causes                   /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What I'm wondering is if the first four bytes are included, that is 
Type, flags, length fields of the SCTP chunk, or if it is only the 
section with Error Causes (which themselves are type/length/value as 
you say).

It seems to me that the most natural thing would be to skip the first 
four bytes, since we from the notification already know the total 
length and that it is an abort chunk.

However, the Socket API draft says:

  "If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received
   for this association, sac_info[] contains the complete ABORT chunk as
   defined in the SCTP specification RFC2960 [RFC2960] section 3.3.7."

"complete ABORT chunk" indicates that these first four bytes really are 
included. In any case, I think it would be worthwhile to make this 
statement in the socket API even more clear (same counts for 
SCTP_REMOTE_ERROR).

> > If a large message has been sent using partial sending, how much of
> > the message will be returned? The first or the last fragment sent?
>

Is this really true? Say if I am really bad and use the partial sending 
API, will the kernel really buffer and keep the full message? So an 
easy way to make the machine run out of mbufs would be to send an SCTP 
message that never ends? If so, wouldn't some people consider that to 
be a DoS issue, although local?

/Anders Torger

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Apr 2007 06:15:37 -0400

> Perhaps I was not clear in the question, this is an abort chunk:

I would think that the first 4 bytes are not presented as well..

> statement in the socket API even more clear (same counts for 

Ahh.. yes.. it really should not have the first 4 bytes..

We probably need to adjust the text to say
"will contain any error causes included in the abort" or something
like that.

What do the rest of y'all think?

R

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 23 Apr 2007 10:06:15 -0400

Randall Stewart wrote:
>> "complete ABORT chunk" indicates that these first four bytes really
>> are included. In any case, I think it would be worthwhile to make this

I recently coded that up in lksctp and interpreted the spec literally.
To me, "complete ABORT chunk" includes the chunk header.  I kinda questioned
the requirement, but didn't really see a reason not to include the header.

> What do the rest of y'all think?

Either way is fine, but it does need to be clarified.  The way the spec is
written now, I interpreted it as "include the header".

-vlad

---

From: Janardhan Iyengar <[email-masked]>
Date: Mon, 23 Apr 2007 14:25:45 -0400

> What do the rest of y'all think?

Sounds reasonable to me.

- jana

-- 
Janardhan R. Iyengar
Visiting Assistant Professor
Connecticut College
http://cs.conncoll.edu/iyengar/

---

From: Anders Torger <[email-masked]>
Date: Tue, 24 Apr 2007 16:33:25 +0200

Randall, 

you missed the question I had at the bottom of the mail (the 'Is this 
really true'-thing):

On Monday 23 April 2007 12:15, Randall Stewart wrote:
> >>> "The undelivered message, exactly as delivered by the caller to
> >>> the original send*() call."
> >>>
> >>> If a large message has been sent using partial sending, how much
> >>> of the message will be returned? The first or the last fragment
> >>> sent?
> >>
> > Is this really true? Say if I am really bad and use the partial
> > sending API, will the kernel really buffer and keep the full
> > message? So an easy way to make the machine run out of mbufs would
> > be to send an SCTP message that never ends? If so, wouldn't some
> > people consider that to be a DoS issue, although local?

/Anders Torger

---

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Apr 2007 10:56:41 -0400

Anders Torger wrote:

So I did...

>>> people consider that to be a DoS issue, although local?

Well, this is no different than TCP.. Think of a sender that says
I will start at byte 1.. in its SYN/SYN-ACK.
Now it sends bytes 2 - N.. The limit here, for both TCP and SCTP, is
the rwnd. The receiver will begin dropping segments after the rwnd
is reached. So lets say.. the sender has a rwnd of 100k. It now can
occupy 100k (- 1 byte) of mbuf/skbuf etc ..

The one-2-many model aggravates this more (which is why the draft
says FRAGMENT INTERLEAVE is at level 1).. since if I had
10 assoc's under a socket, one could do this and start the pd-api
and then stop sending.. now the other 9 are blocked... even though
you are not taking up kernel mbufs... of course with level 1 only
your assoc is blocked.. ;-D

This case is a bit different though.. but you have the same issue.
one-2-one or one-2-many.. the sender never ends its message.. of
course if everything is in sequence the pd-api will start and then
the local user will receive the data.. so the "evil sender" would need
to skip the first "FIRST bit" fragment and send all the rest until
the rwnd is full...

But you are looking at the very same scenario TCP has..

This is another reason for the PD-API delivery point set.. you can
set that down.. to some arbitrary lower value.. so that you will
start getting data from such an evil sender.. and if you know
your message size (some may not .. but most apps I am aware of
do) then you set it down to the max msg size you will ever
get.. and if you start to get a message that is larger than this..
aka you get N bytes (your limit) and no MSG_EOR is set.. you can
abort the peer..

TCP has a similar mechanism.. since it never looks for a EOR.. and
  always delivers when it can.. in order. In fact if you set
your PD-API point to 1 byte, you get TCP like service... Especially
if the peer sets EXPLICT_EOR mode.. and ta-da, your SCTP association
just became some number of multiple streams of bytes... if the
sender never sends MSG_EOR, then you have 1 stream of bytes for the
whole association...

R

---

From: Mark Butler <[email-masked]>
Date: Tue, 24 Apr 2007 16:08:26 -0600

>>>people consider that to be a DoS issue, although local?

In the case of send failed notifications, I think it is clear at some 
point there has to be a limit, otherwise a stack could never send a 
message larger than the buffer size.

- Mark B.