Subject: [Tsvwg] U-SCTP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 12 Mar 2001 06:16:55 -0800

Hi,

I would like to suggest a change to the U-SCTP draft. 

I would like to suggest that the U-SCTP draft allow the option of media
being sent before the COOKIE exchange has completed. The receiving side is
not forced to process these early DATA chunks (and the transport is after
all unreliable).

Motivations: Many media streams are time-sensitive and the 4 way handshake
may result in clipped voice (or whatever). In these streaming applications
it is often not critical if a small number of packets are processed even if
the COOKIE authentication fails.

In particular I am suggesting that 
-When a TCB is waiting for a COOKIE ECHO chunk, DATA chunks maybe sent on
U-SCTP streams if the ULP has indicated this desire. 
-Any U-SCTP data received before the COOKIE ECHO/COOKIE ACK is received MAY
be passed to the ULP if the ULP has indicated its willingness to receive
such data. 

These changes would also be combined with the RECOMMENDATION that
- Before accepting early DATA chunks, an SCTP stack should also check if
there has been high failure rate in recent associations attempts on this
SCTP port or across all SCTP ports. [Eg, undergoing recent masquerade or DOS
attacks]
- The ULP must be able to control whether it receives or sends data before
the COOKIE exchange completes.
- If the cookie exchange subsequently fails, the ULP is obviously informed
and the connection aborted (unchanged). 

The default action would be to enforce the COOKIE exchange but providing the
socket option to streaming applications is in my mind very important.

As I see it, it will be these applications using USCTP to send streaming
media that are more likely to need to setup an association dynamically
(rather than at start time). For instance, SDP bodies in MGCP messages could
be used to instruct the media gateway to establish an SCTP media connection
(for which no association may be currently established).

I'll be interested to hear your comments.

Regards,

Robert.

---

From: Randall Stewart <[email-masked]>
Date: Mon, 12 Mar 2001 09:33:23 -0600

Robert:

Comments below...

> "Fairlie-Cuninghame, Robert" wrote:
> 
> Hi,
> 
> I would like to suggest that the U-SCTP draft allow the option of
> media being sent before the COOKIE exchange has completed. The
> receiving side is not forced to process these early DATA chunks (and
> the transport is after all unreliable).
> 
> Motivations: Many media streams are time-sensitive and the 4 way
> handshake may result in clipped voice (or whatever). In these
> streaming applications it is often not critical if a small number of
> packets are processed even if the COOKIE authentication fails.
>

> -When a TCB is waiting for a COOKIE ECHO chunk, DATA chunks maybe sent
> on U-SCTP streams if the ULP has indicated this desire.

But here in lies the problem.. you do NOT have a TCB when you
are waiting for a Cookie Echo chunk... you DO NOT BUILD a TCB
until the Cookie Echo arrives. This means that there is NO way
that you can accept data until the handshake takes place (at least
2 legs and the arrival of the Cookie Echo).

If on the other hand you are advocating changing RFC2960 to have the
receiver of an INIT build a TCB and then send a INIT-ACK, then you
have defeated the whole purpose of the Cookie-Echo. 

This is just plain un-wise and opens you up to DOS attacks.. .the whole
reason the Cookie exists to begin with...

> 
> -Any U-SCTP data received before the COOKIE ECHO/COOKIE ACK is
> received MAY be passed to the ULP if the ULP has indicated its
> willingness to receive such data.

Again, there is no upper layer to pass the data to, since there is
no TCB to find an upper layer (aka socket).

> - Before accepting early DATA chunks, an SCTP stack should also check
> if there has been high failure rate in recent associations attempts on
> this SCTP port or across all SCTP ports. [Eg, undergoing recent
> masquerade or DOS attacks]
> 
> - The ULP must be able to control whether it receives or sends data
> before the COOKIE exchange completes.
> - If the cookie exchange subsequently fails, the ULP is obviously
> informed and the connection aborted (unchanged).
> 
> The default action would be to enforce the COOKIE exchange but
> providing the socket option to streaming applications is in my mind
> very important.
> 
Which would mean you would need to allow the upper layer to say, hey, go
ahead
and build TCB's in response to INIT's... I just don't see that 2-4
frames
of speech up front at the start of an association are that critical. 

1 - 4 clipped speech frames at the start of a call are not really going
to be detectable from a user perspecitive... in the middle of a call,
yes
more likely, at the setup ... I am not conviced..

R

> As I see it, it will be these applications using USCTP to send
> streaming media that are more likely to need to setup an association
> dynamically (rather than at start time). For instance, SDP bodies in
> MGCP messages could be used to instruct the media gateway to establish
> an SCTP media connection (for which no association may be currently
> established).
> 

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg