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
