Subject: [Tsvwg] RE: U-SCTP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 12 Mar 2001 08:25:54 -0800

Hi Randall, 

Thanks for the response. I had forgotten the temporary TCB was destroyed
after the INIT ACK is sent - so yes RFC2920 changes would be required. I
disagree that this _defeats_ the purpose of the COOKIE because
	- SCTP would refuse early USTCP DATA chunks if it has detected a
high level of DOS attacks recently (regardless of what the application
requested). Hence no denial of service (systemwide). 
	- I would tentatively say that streaming media applications care a
little less about (time-limited) masquading attacks or unautheticated packet
attacks causing system-wide damage. The attack will be shortly detected and
the connection closed when the COOKIE times-out; if the attack continues
then the early USCTP acceptance will stop. So billing fraud is not possible
on a continued basis. 

but I agree that the gains do not justify modifying RFC2960. 

Cheers,

Robert.

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 3:33 PM
> To: Fairlie-Cuninghame, Robert
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: Re: U-SCTP
> 
> 
> Robert:
> 
> Comments below...
> 
> > "Fairlie-Cuninghame, Robert" wrote:
> > 
> > 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.
> 
> 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).
> 
> > 
> > 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.
> > 
> 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).
> > 
> > I'll be interested to hear your comments.
> > 
> > Regards,
> > 
> > Robert.
> 
> -- 
> Randall R. Stewart
> Systems & Solutions Engineering
> Cisco Systems Inc.
> [email-masked] 815-342-5222 or 815-477-2127
>