Subject: Why not discard OOTB SHUTDOWN-ACK?

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Sep 2007 11:49:59 -0400

Hi All

The current text is Section 8.4, OOTB handling has this for
treatment of OOTB packets with SHUTDOWN-ACK:

   5)  If the packet contains a SHUTDOWN ACK chunk, the receiver should
       respond to the sender of the OOTB packet with a SHUTDOWN
       COMPLETE.  When sending the SHUTDOWN COMPLETE, the receiver of
       the OOTB packet must fill in the Verification Tag field of the
       outbound packet with the Verification Tag received in the
       SHUTDOWN ACK and set the T-bit in the Chunk Flags to indicate
       that the Verification Tag is reflected.  Otherwise,

My question is, why not discard this packet?  It's OOTB, so if there
is anything bundled along with SHUTDOWN-ACK it would elicit another
response (ABORT or SHUTDOWN-COMPLETE).  Seems a bit pointless, but
I may be missing something.

I used to have code that discarded the packet, but while doing some update
and re-reading the spec, I noticed that it didn't match the text.

Thanks
-vlad

---

From: "Peter Lei (peterlei)" <[email-masked]>
Date: Mon, 17 Sep 2007 11:03:25 -0500

What if the peer lost your "real" SHUTDOWN-COMPLETE?... It
will then continue to send you SHUTDOWN-ACK until it gets a
SHUTDOWN-COMPLETE, or overall shutdown guard timer expires.

Hence, the below text allows this condition to be be more
quickly handled as a normal shutdown (e.g. the peer would
get a SHUTDOWN-COMPLETE vs. abort or timeout).

--peter

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Sep 2007 13:23:58 -0400

Peter

> get a SHUTDOWN-COMPLETE vs. abort or timeout).

But it would still get my SHUTDOWN-COMPLETE that was a response
to the SHUTDOWN-ACK.

The question is the bundled chunks that came might have come with
this OOTB SHUTDOWN-COMPLETE.  The way text is now, we still
have to process those other chunks, but the only other possible
response is an ABORT.

For example, SHUTDOWN ACK + HEARTBEAT would result in 2
packets if implementation conforms strictly to the text:

  1. SHUTDOWN COMPLETE in response to SHUTDOWN ACK has to be
     separte, because you MUST NOT bundle anything with it.

  2. ABORT in response to HB.

What I am talking about is to add text like

"After sending this SHUTDOWN COMPLETE, the
 receiver of the OOTB packet shall discard the OOTB packet and
 take no further action."

to the paragraph in item 5.

This, in essence, disregards any bundled chunks that were sent with
OOTB SHUTDOWN ACK.

-vlad

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 17 Sep 2007 11:37:18 -0600

Vlad,

It doesn't make much sense to bundle a HEARBEAT with a SHUTDOWN-ACK.
The only chunk that I know of that can be bundled with SHUTDOWN-ACK
is an ERROR chunk (cookie received while shutting down) which would
not illicit an ABORT.  Can you think of another bundled chunk that
makes sense?

--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: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Sep 2007 14:04:10 -0400

Brian

> not illicit an ABORT.  Can you think of another bundled chunk that

I am not talking about things that make sense.  These are OOTB packet
and an implementation should be prepared to deal with anything that
comes along.

The case of 300 bundled SHUTDOWN-ACKs comes to mind.  The way the
OOTB handling is specified, an implementation would send 300 SHUTDOWN
COMPLETES, which could be considered an attack.

-vlad

---

From: "Peter Lei (peterlei)" <[email-masked]>
Date: Mon, 17 Sep 2007 13:43:54 -0500

Vlad,

Sorry, I did not read enough into your original email...

I think this case is addressed in the sctp-threats I-D.. that is,
an endpoint should not send back multiple packets in response to
a single received packet.

Thus, the case of N bundled SHUTDOWN-ACKs should elicit a single
packet with one SHUTDOWN-COMPLETE chunk, as it can't be bundled
with any other chunks.

As Brian points out, there are no chunks that I know of that one
would send after a SHUTDOWN-ACK that would require any real
response... so no other outgoing packet should happen.  In other
words, since only one packet should go out, it would be the
SHUTDOWN-COMPLETE.

The BSD implementation does exactly what you say... it disregards
any bundled chunks after a SHUTDOWN-ACK in a packet.

If this isn't clear from the threats I-D, perhaps the text there
can be clarified.

--peter

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 17 Sep 2007 20:42:40 +0200

Hi Vlad,

RFC 5062 (Security Attacks Found Against Stream Control Transmission
Protocol (SCTP) and Current Countermeasures) will contain:

9.  Bombing Attack (Amplification) 3

    This attack allows an attacker to use an SCTP endpoint to send a
    large number of packets in response to one packet.

9.1.  Attack Details

    The attacker sends a packet to an SCTP endpoint, which requires the
    sending of multiple chunks.  If the SCTP endpoint does not support
    bundling on the sending side, it might send each chunk per packet.
    These packets can either be sent to a victim by using the victim's
    address as the sources address, or it can be considered an attack
    against the network.  Since the chunks, which need to be sent in
    response to the received packet, may not fit into one packet, an
    endpoint supporting bundling on the sending side might send multiple
    packets.

    Examples of these packets are packets containing a lot of unknown
    chunks that require an ERROR chunk to be sent, known chunks that
    initiate the sending of ERROR chunks, packets containing a lot of
    HEARTBEAT chunks, and so on.

9.2.  Analysis

    This attack depends on the fact that the SCTP endpoint does not
    support bundling on the sending side or provides a bad  
implementation
    of bundling on the sending side.

9.3.  Mitigation Option

    First of all, path verification must happen before sending chunks
    other than HEARTBEATs for path verification.  This ensures that the
    above attack cannot be used against other hosts.  To avoid the
    attack, an SCTP endpoint should implement bundling on the sending
    side and should not send multiple packets in response.  If the SCTP
    endpoint does not support bundling on the sending side, it should  
not
    send in general more than one packet in response to a received one.
    The details of the required handling are described in [RFC4960].

and

11.  Bombing Attack (amplification) 5

    This attack allows an attacker to use an SCTP endpoint to send a
    large number of packets in response to one packet.

11.1.  Attack Details

    The attacker sends a packet to an SCTP endpoint, which requires the
    sending of multiple chunks.  If the MTU towards the attacker is
    smaller than the MTU towards the victim, the victim might need to
    send more than one packet to send all the chunks.  The difference
    between the MTUs might be extremely large if the attacker sends
    malicious ICMP packets to make use of the path MTU discovery.

11.2.  Analysis

    This attack depends on the fact that an SCTP implementation might  
not
    limit the number of response packets correctly.

11.3.  Mitigation Option

    First of all, path verification must happen before sending chunks
    other than HEARTBEATs for path verification.  This makes sure that
    the above attack cannot be used against other hosts.  To avoid the
    attack, an SCTP endpoint should not send multiple packets in  
response
    to a single packet.  The chunks not fitting in this packet should be
    dropped.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 17 Sep 2007 12:39:10 -0600

Vlad,

Well, you are allowed to discard or abort any packet that
doesn't make sense or is a protocol violation, such as your
examples.  It does not require text in the SHUTDOWN-ACK
description.

Because only a SHUTDOWN-ACK (and maybe the ERROR chunk for
cookie received while shutting down) makes sense, I send
SHUTDOWN-COMPLETE based on the SHUTDOWN-ACK in the first
chunk and ignore the rest of the message.  If the packet makes
sense, it is valid reply.  If the packet does not make sense,
it is still a valid reply.

--brian

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Sep 2007 14:57:33 -0400

> If this isn't clear from the threats I-D, perhaps the text there

I thought that the goal was to put resolutions from the threats ID into
2960bis?  Adding the sentence that I provided below would essentially
document the current behavior of multiple (if not all implementations)
and preclude new implementors from going through this again.

Thanks
-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 17 Sep 2007 21:22:08 +0200

Hi Vlad,

I'm adding Randy here... As far as I know, 2960bis is in
AUTH48 state, so there can only be editorial comments anymore.
If it has not already passed it...

Best regards
Michael

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 17 Sep 2007 15:28:21 -0400

> If it has not already passed it...

Crud...  I guess adding:

To section 8.4, item 5 could be considered editorial, but that's
a hard sell.

I does document state of the art though...

I'll live with whatever outcome.

Thanks
-vlad

---

From: Randall Stewart <[email-masked]>
Date: Mon, 17 Sep 2007 16:49:08 -0400

There are no changes now..

But let me review this thread and reply..

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Randall Stewart <[email-masked]>
Date: Mon, 17 Sep 2007 16:48:32 -0400

Its gone past 48.. let me get settled (just got to the mother
ship).. and then I will spend some time thinking about
if we did not take care of this already..

R

Michael Tuexen wrote:
>>>>> It doesn't make much sense to bundle a HEARBEAT with a SHUTDOWN- ACK.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 18 Sep 2007 07:58:34 -0400

> But it would still get my SHUTDOWN-COMPLETE that was a response

Vlad:

I want to stay focused on the "valid case" first... before I look
at the malicious case.

I don't grok your statement:
"
  But it would still get my SHUTDOWN-COMPLETE that was a response
  to the SHUTDOWN-ACK.
"

Your original question was,

If I have no TCB (after I have shutdown) and I get a SHUTDOWN-ACK
why would I not just drop it silently.

The answer Peter gave was...

Well the SHUTDOWN-COMPLETE could have been lost.

Thinking of the normal case, not the attack case does this make
sense to you now? If so what was the meaning of the sentence
above..

Thanks

R

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 18 Sep 2007 09:06:25 -0400

Hi Randy

> why would I not just drop it silently.

The subject is misleading (I forgot to add "bundled" to the line).
The, the question I was _really_ asking is:

If I get an OOTB packet with SHUTDOWN-ACK bundled with other chunks,
why not simply drop the packet after processing SHUTDOWN-ACK.

I am looking specifically at the OOTB case where SHUTDOWN-ACK is not
the only chunk in the packet.

Thanks
-vlad

---

From: Randall Stewart <[email-masked]>
Date: Tue, 18 Sep 2007 08:10:51 -0400

Vlad:

Ok let me direct you to a section of the text I bet you
have not concentrated upon ... security :-D .. This section
was added due to this issue:

In section 11.4
"
    When an SCTP stack receives a packet containing multiple control or
    DATA chunks and the processing of the packet requires the sending of
    multiple chunks in response, the sender of the response chunk(s) MUST
    NOT send more than one packet.  If bundling is supported, multiple
    response chunks that fit into a single packet MAY be bundled together
    into one single response packet.  If bundling is not supported, then
    the sender MUST NOT send more than one response chunk and MUST
    discard all other responses.  Note that this rule does NOT apply to a
    SACK chunk, since a SACK chunk is, in itself, a response to DATA and
    a SACK does not require a response of more DATA.
"

So its there.. you just have to make sure and do it..

And note, from day 1 both the BSD implementation and the previous
reference implementation (the original user space verision that
Qiaobing and I kept up to date has we worked on the original
SCTP implementation) always did as described above. So if you
sent 100 HB's bundled, you get 100 HB-ack's bundled in one packet
back. Shutdowns are as Peter described.. and have always been (at
least as far back as I can remember :-D)

R

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 18 Sep 2007 11:42:06 -0400

> So its there.. you just have to make sure and do it..

Aha... that's were it is!

Now to audit all that code...

Thanks
-vlad

---

From: Randall Stewart <[email-masked]>
Date: Tue, 18 Sep 2007 14:13:44 -0400

> Now to audit all that code...
Yes security sections often times are seen as "blah blah blah ...",
sort of like the Adult conversations on a Charlie Brown
cartoon :-D... but they do tend to have good information in
them. We put it there so we did not have to rip up large
amounts of the document.. it made sense and is a clean place
for it.. and I think a correct one too...

However the risk is always that folks tend to not hear it :-(

R