Subject: [Tsvwg] SCTP IG: Reception of bundled chunks

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 00:17:29 +0200

Dear all,

I have been thinking about the packet amplification attacks in the
SCTP threat document, which are based on sending packets containing
DATA chunks or HB. We have seen some discussion under the (misleading)
subject ICMP issue with SCTP IG.

There is another class of amplification attacks possible (text
will be added to the SCTP threat ID).

The attacker establishes an association with a host and lists the
address of the victim.

Then it sends with the source address of the victim a packet containing
- lots of bundled HEARTBEAT chunks (for example up to 183 chunks on an
   ethernet link)
- lots of bundled chunks with unknown type requesting a report and 
continue
   to process (for example up to 367 on an ethernet link)
- lots of bundled DATA chunks with an illegal SID.

There is an implementation which just returns one packet which has
- all HB-ACKs in it
- as much ERROR chunks as fit in a packet.
- all ERROR chunks in it

But there are also implementations which send each 'reply', which means
HB-ACK or ERROR chunk, in its own packet. This gives an amplification
of more than 350 on a normal 1500 MTU link!

So I would suggest that we should add a statement, that an SCTP 
implementation
MUST send at most one 'reply' packet on reception of a packet. This 
does not
affect DATA and SACK, but the others.

So an implementation can send a packet having lots of HB-ACK on 
reception of
a packet containing lots of HB. But only as much as fit in one packet 
(Path MTU
could be asymmetric). The same applies to other 'reply' packets. This 
would
be an incarnation of the principle 'send at most one packet on 
reception of
a packet' which normally should be applied to non DATA chunks.

Comments?

Best regards
Michael

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 16:49:10 -0600

Michael,

Illegal stream DATA chunks are neither here nor there.  It is
also possible to ABORT the association upon receipt of an
illegal SID, or it is also possible to simply process them.

Unknown report chunks and HB/HB-ACKs on the other hand are a
problem.  Report chunks are probably the worst. (Many very
short unknown chunks can be bundled in a single packet.)

Although I agree with your solution, as Randall pointed out to
me, currently, bundling of chunks is OPTIONAL.

This sounds like a good reason to make bundling mandatory.

--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: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 07:26:49 +0200

Hi Brian,

see my comments in-line.

Best regards
Michael

> illegal SID, or it is also possible to simply process them.
My statement is that it is pretty bad to see one ERROR chunk
each in one packet for one packet with lots of these DATA chunks.
> short unknown chunks can be bundled in a single packet.)
Yes, these are the ones I tested some implementations with. You
can get over 350 in a 1500 byte packet. If the MTU is larger,
it is even worse.
> me, currently, bundling of chunks is OPTIONAL.
That is correct.
The solution does not require bundling but introduces the drop
of unsupported chunk which should be reported.
But note, even if you bundle (the preferred solution, but not
required) you have to drop stuff (if the 'response does not
fit in a packet).

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 27 Sep 2005 23:54:49 -0600

Michael,

> required) you have to drop stuff (if the 'response does not

So how would you handle just 300 odd bundled HB's if you do not
support bundling?  Just send one HB-ACK and ignore others?  I suppose
that's reasonable.  There should not be two HB's in a packet anyway.
Any the HB-ACK is the same size as a HB.

Also drop ERROR chunks.  That's ok too. ERROR chunks are not sent
reliably anyway and could be dropped by the network.  The peer must
be ready for them to vaporize at some point anyway.

Ok, sounds good.  Now some text?

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 28 Sep 2005 08:40:18 +0200

Brian,

see my comments in-line.

Best regards
Michael

> that's reasonable.  There should not be two HB's in a packet anyway.
Two HB in a packets are very usefull for testing the correct handling
of unrecognized chunks. However, I have not seen bundled HB from 
implementations.
> Any the HB-ACK is the same size as a HB.
That is why bundling works on symmetric paths.
> be ready for them to vaporize at some point anyway.
Yes.
> Ok, sounds good.  Now some text?
I can post some text later (I'm currently waiting for a flight...)

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 30 Sep 2005 14:12:19 +0200

Hi Brian,

here is a text suggestion.

The following could be added to section 6.10.

When a packet containing multiple control chunks or DATA
chunks which results in sending of an ERROR chunk is received
and the processing of the packet requires the sending of multiple
chunks no more than one packet MUST be sent. If bundling is
supported multiple chunks that fit into one packet can be put
into the packet. All other chunks MUST be discarded. If bundling
is not supported, only the first chunk can be sent back.

Should we also have some examples: Reception of
- multiple HB
- multiple unknown chunks
- multiple SHUTDOWN-ACKs
- DATA with errors in fields
- multiple COOKIE-ECHOs

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 30 Sep 2005 11:57:25 -0600

Michael,

Sounds good.  I agree with the MUST language.

--brian