Subject: RFC 2960, section 6.5 - response to bogus stream ID

From: David Lehmann <[email-masked]>
Date: Mon, 27 Oct 2003 14:52:27 -0500

RFC 2960 states:
   6.5 Stream Identifier and Stream Sequence Number

   Every DATA chunk MUST carry a valid stream identifier.  If an
   endpoint receives a DATA chunk with an invalid stream identifier, it
   shall acknowledge the reception of the DATA chunk following the
   normal procedure, immediately send an ERROR chunk with cause set to
   "Invalid Stream Identifier" (see Section 3.3.10) and discard the DATA
   chunk. The endpoint may bundle the ERROR chunk in the same packet as
   the SACK as long as the ERROR follows the SACK.

IMHO, this response (SACK+ERROR) is not strong enough.  The
sending endpoint is violating the protocol by sending on a stream 
ID which is beyond the agreed limits.   The SACK is telling the
sender that the data has been accepted.  The ERROR chunk shows that
there was some problem, but there is no guarrantee that the endpoint
receiving the ERROR will do anything with the ERROR.  So the
receiving endpoint will have a "hole" in its received data.

I think that the association should be aborted by the endpoint 
which receives the bogus stream ID. i.e. Don't send a SACK+ERROR;
rather send an ABORT with an error clause.

Opinions?

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 27 Oct 2003 14:22:52 -0600

On Monday, October 27, 2003, at 01:52 PM, David Lehmann wrote:

> sending endpoint is violating the protocol by sending on a stream ID
> which is beyond the agreed limits.   The SACK is telling the
> I think that the association should be aborted by the endpoint which
> receives the bogus stream ID. i.e. Don't send a SACK+ERROR;

I do not view the SACK as deceiving the sending side. It correctly lets
the sender know that it no longer has to buffer that data for possible
retransmit.

The ERROR is to provide information, hopefully filtered up to the
application, that it did something wrong.

Terminating the association accomplishes nothing more, other than
discouraging any opportunities at sharing an association across
applications.

On the receiving side the application is still free to terminate
the association, if it believes that is the correct response.
Automatically terminating it merely does so more promptly.
Because the Data Chunks are being discarded there is no
security benefit in closing the association more promptly.

Keep in mind that there is no "hole", an entire stream is
being discarded. The Stream ID cannot be valid for some
of the chunks and valid for others. And if the sender
is spraying data chunks into the wrong streams then the
application is going to fail anyway, whether or not the
incorrectly designated stream is "valid" or not.

And since the number of applications attempting to communicate
on an invalid stream within any given millisecond will never
be very high, I can't see how this would be a performance issue.

In my opinion, allowing the receiving application to determine
whether the association should stay open, as allowed under the
current spec, is the correct solution.

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

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 28 Oct 2003 08:27:18 -0600

> rather send an ABORT with an error clause.
1) A SACK tells the sender.. Hey, I got this .. so you can stop your T3 
and you
    no longer need to retransmit the data....

     In this case.. it is true.. the receiver got the data.

2) The Stream/Seq dictate ordering and delivery to the upper layer... so 
when
     the Stream found is invalid the correct response is to send an error.

3) There is no "hole" of data here since everything the sender sends to 
stream X is
    going to be dumped.

4) The other end is free to abort the assocaition...after all it is it 
that is

   a) accepting stream no's outside the legal bounds
   b) sending them irrespective of the agreed upon range.

5) I don't see that the rest of the association is broken in this case.

Overall I just don't see that sending an ABORT will do anything that 
helps us
get on .. and NOT sending ABORT allows the receiver of the ERROR to make
a choice...

I don't see a problem with the current guidelines..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 Oct 2003 12:10:42 -0700

Randall,

I don't see a problem with them either.  However, there is another
alternative to sending ERROR or ABORT: accepting the message.
When stream id state structures are dynamically allocated and the
association has not reached its allocation limit, some implementations
should be permitted to acknowledge the chunk as normal.  This would
make an implementation able to forgive a mistake in stream numbers
made early in the association initialization process.

--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: David Lehmann <[email-masked]>
Date: Thu, 30 Oct 2003 09:05:02 -0500

>     In this case.. it is true.. the receiver got the data.

...depending on who you call the receiver.  I think the sending app
believes the receiver is the receiving app, not the receiving SCTP
driver.

If the app sends data which is accepted by SCTP, it has reason to
believe that it will be delivered to the peer user.

>     the Stream found is invalid the correct response is to send an error.

The error should have been caught by the sending SCTP driver.
It should have immediately rejected the send request.
However, if SCTP lets the message through, the SCTP has a bug.
It has indeed violated the protocol by sending a data chunk on
a invalid stream.

I am suggesting that the receiving side, abort the association
in this _extremely_ rare case.

> 3) There is no "hole" of data here since everything the sender sends to 

I see your point here.  However, I am looking at the data in total.

Moreover, there is a bug in both the app and the SCTP driver.  
The bug in the app may be due to it overwriting the memory which
held the stream id.  The bug in the driver is that it accepted the
bogus stream id.

In this situation, there is the possibility that an app (e.g. ftp) will 
send a bunch of data to the receiving app.  When the sending app closes
the association, it assumes that all the data has been delivered to 
the receiving app. It will not know that some data never made because
the data was silently dropped.

> 4) The other end is free to abort the association...after all it is it 
> that is
> 
> get on .. 

It helps identify flaw in the sending SCTP. It prevents data from
being dropped without notification.  It forces the protocol violation
to be corrected.

> and NOT sending ABORT allows the receiver of the ERROR to make
> a choice...

The receiver (defined as the app) gets no choice because the receiving
SCTP driver dropped it.  The receiver (defined as the SCTP driver) can
not make an intelligent choice for each app.

The choice should be made at the sending side.  The sending SCTP
driver should have rejected the data from the app. At this point,
the sending app could make the decision of what to do.  _If_ an
implementation does not do this and sends the data over the wire,
violating the protocol, the receiving side has an obligation to
abort the association, rather than risk the possibility of
introducing a hole in the data. (ie hole in the total data,
not just one stream).

I don't see why we would want to give flexibility on this
very rare condition which should never have happened in the first place.

... just my opinion.

--

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 30 Oct 2003 08:32:18 -0600

David Lehmann wrote:

>> 1) A SACK tells the sender.. Hey, I got this .. so you can stop your 
>> T3 and you
>> 2) The Stream/Seq dictate ordering and delivery to the upper layer... 
>> so when
>> 3) There is no "hole" of data here since everything the sender sends 
>> to stream X is
>>    going to be dumped.
>
>
> Moreover, there is a bug in both the app and the SCTP driver.  The bug 
> in the app may be due to it overwriting the memory which
> In this situation, there is the possibility that an app (e.g. ftp) 
> will send a bunch of data to the receiving app.  When the sending app 
> closes

>
>
>> 4) The other end is free to abort the association...after all it is 
>> it that is
>>

And why would an error not do the same thing?  I don't agree with you.. 
I am sorry
I just don't see the point. You are also thinking in terms of one 
application using
the association. In the case of RDMA, as I understand things, the RDMA 
may be
used by multiple applications sharing the same association... in such a 
case you are
willing to kill all the applications using the association not just the 
single one at fault.

The error is a far better choice IMO..

> introducing a hole in the data. (ie hole in the total data,
Again, the sender will get to choose an action. If it gets the ERROR it can
abort the assocaition as well.

> very rare condition which should never have happened in the first place.
Sorry we disagree.

R

---

From: David Lehmann <[email-masked]>
Date: Thu, 30 Oct 2003 10:19:21 -0500

> And why would an error not do the same thing?  I don't agree with you.. 

IMHO, an ERROR chunk is not a strong enough response to a protocol
violation.  An ABORT can't be ignored.

> willing to kill all the applications using the association not just the 

I see your point.  

I am not familar with RDMA. I will guess that RDMA is the SCTP user; 
the applications are RDMA users.  If RDMA gets an ABORT due to a bogus
stream ID, it does not have to interrupt its applications. It can
just create a new association to replace the aborted one.  In any event,
that's a RDMA problem.  (It has to handle this problem anyway, because
the peer implementation may abort the association in response to
the bogus stream ID, even with the current RFC wording.)

> abort the assocaition as well.

The sending SCTP driver should have never sent the data on the wrong stream.
It already knows what streams the receiver is willing to accept.
It also knows that the DATA chunk will never get to the receiving application.
Why should it waste bandwidth sending data which will only be discarded?
Therefore, it should have made the decision _before_ sending the data to IP.

>> very rare condition which should never have happened in the first place.

It happens. :-)

--

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 30 Oct 2003 10:36:43 -0600

David Lehmann wrote:

>> the association. In the case of RDMA, as I understand things, the 
>> RDMA may be
>> used by multiple applications sharing the same association... in such 
>> a case you are
>> willing to kill all the applications using the association not just 
>> the single one at fault.
>
>
> I see your point. 
No it does not since the spec does NOT call for an ABORT.

> The sending SCTP driver should have never sent the data on the wrong 

Yes this is true.

> Therefore, it should have made the decision _before_ sending the data 

Ok. but an error serves the SAME purpose.

>>> very rare condition which should never have happened in the first 
I do not see this as a problem... nor something that requires change to the
spec. Neither have I seen any other responses besides yours supporting the
idea of sending an ABORT.

So for now, I don't see it as something headed towards the I-G...

R

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 30 Oct 2003 10:35:37 -0600

-----Original Message-----
From: David Lehmann [mailto:[email-masked]]
Sent: Thursday, October 30, 2003 9:19 AM
To: SCTP Implementors
Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID

I see your point.  

--------------------------- END CLIP from Original Message------------

The RDMA mapping to SCTP is designed to allow multiple thread/
objects within a single process to each have their own RDMA "connection"
over a pair of SCTP streams.

Mistakes *within* a session should not effect other sessions.

However, using the "wrong" stream ID would be an error by the
RDMA middleware and not the application thread/object.

That, and the recommended practice is to allow all 64K streams
up front, and then just track which of them have a session attached.
Messages delivered to an "Out of session" SCTP stream will simply
be discarded (with a possible warning event on the local interface)
because they are not "legal sessions".

Pre-allocating all 64K streams is possible for an RDMA application
because all Data Chunks are unordered. That means that the resources
required for each stream are almost non-existent. Real resource
allocation is not required until a stream is "in session".

That said, I will repeat my earlier opinion. The fact that your
peer MUST NOT do X in no way requires that you MUST immediately
cease and desist all contact with the peer should such behavior
be detected. It does mean that you MAY do so.

The decision on whether to be fault tolerant even in the face
of a peer violating a "MUST" rule is, in my opinion, best left
to the application. The SCTP layer should not force a fault
intolerance policy on its own unless a scenario is identified
where SCTP layer action is required to prevent a security
vulnerability.

---

From: David Lehmann <[email-masked]>
Date: Thu, 30 Oct 2003 12:06:17 -0500

> No it does not since the spec does NOT call for an ABORT.

It does not forbid it either.  You, yourself, stated in your 10/28 post:
"The other end is free to abort the association.".
Moreover, the app MUST be able to deal with the abort at any time.

> Ok. but an error serves the SAME purpose.

...after a roundtrip, including the sending of useless data.

> So for now, I don't see it as something headed towards the I-G...

As you wish... I don't want to continue to debate this issue.
I said my piece and you seem to understand my issue.

--

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 30 Oct 2003 11:27:04 -0600

> Moreover, the app MUST be able to deal with the abort at any time.
Your implementation is most welcome to send an abort if it so desires.. 
I just
do NOT want a MUST send an abort in the spec...

R

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 30 Oct 2003 16:24:22 -0600

David,

David Lehmann wrote:
....
> believe that it will be delivered to the peer user.

This belief is rather based on a shaky ground by the app sender. If the
app sender needs to know for sure whether the data reached the app
receiver, it must then rely an app layer ack, rather to assume SCTP ack
is the equivalent because it is not.

If your app does use an app layer ack, then your problem is gone - if a
wrong stream ID is used to send data, your app sender will never mistake
the data was delivered since it will never receive its app layer ack. 

regards,
-Qiaobing