Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown

[Thomas Graf <tgraf@xxxxxxxxxxxxx>]

On Wed, Jul 06, 2011 at 10:31:56AM -0400, Vladislav Yasevich wrote:
> >>> +			 *
> >>> +			 * Allow the association to timeout if SHUTDOWN is
> >>> +			 * pending in case the receiver stays in zero window
> >>> +			 * mode forever.
> >>>  			 */
> >>>  			if (!q->asoc->peer.rwnd &&
> >>>  			    !list_empty(&tlist) &&
> >>> -			    (sack_ctsn+2 == q->asoc->next_tsn)) {
> >>> +			    (sack_ctsn+2 == q->asoc->next_tsn) &&
> >>> +			    !(q->asoc->state >= SCTP_STATE_SHUTDOWN_PENDING)) {
> >>
> >> Would a test for (q->asoc->state != SCTP_STATE_SHUTDOWN_PENDING) be clearer?  We only
> >> care about the PENDING state here.
> > 
> > I think SHUTDOWN_RECEIVED should also be included. We continue to transmit and
> > process SACKs after receiving a SHUTDOWN.
> 
> I am not sure about SHUTDOWN_RECEIVED.  If we received shutdown, then we are not in
> a 0 window situation.  Additionally, the sender of the SHUTDOWN started the GUARD timer
> and will abort after it expires.  So there is no special handling on our part.

Why can't we be in a 0 window situation? A well behaving sctp peer may not,
but we're on the Internet, everyone behaves at their worst :-)

Seriously, this would make for a simple dos. Establish a stream, don't ack any
data to make sure there is something on the retransmission queue of the peer.
Immediately shutdown the stream and ack any retransmission attempt with
a_rwnd=0 to keep the association around forever.

Starting the T5 SHUTDOWN GUARD timer is specified as MAY and not MUST so even in
a well behaving world we could not really rely on it.

Alternatively the peer could just be buggy as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html