Subject: RE: [Tsvwg] SCTP Message Fragmentation issue

From: [email-masked]
Date: Fri, 13 Dec 2002 13:41:37 +0200

Interesting... I didn't know about that kind of attack at the IP level...

	However, as SCTP packets doesn't have any offset, I fail to see how this can affect at the SCTP level... Do you mean illegal fragmented user messages that do not follow the "natural" order of flags in consecutive TSNs (flags BE = 10, 00, 01)?... Something like (flags BE = 10, 10, 01, 00...).

	I test that flag B can only (and must) be set if previous TSN had its E flag set or if it is the cumulative TSN ACK and we are not in the middle of a partial delivery... But I don't remember right now what I do afterwards if the peer makes these weird things... probably closing the association... :-/

	Thanks for the information about this attack!

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 12 December, 2002 22:34
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Tsvwg] SCTP Message Fragmentation issue
> 
> 
> Ivan.Arias-Rodriguez, Randall,
> 
> Ah, yes.  So do I.  Actually, I partial deliver all the timer for
> speed and to avoid the blocking problems associated with 
> large packets.
> 
> However, do you have graceful (renegging) protection against 
> tear-drop attack?
> 
> --brian
> 
> On Thu, 12 Dec 2002, [email-masked] wrote:
> 
> > 	Yes, my implementation is also able to make partial 
> deliveries...
> > 
> > 	And to answer Iain's second mail... In fact the implementation
> > 	shouldn't hang the association. There is a flag when receiving
> > 	messages using the socket interface, that tells you whether the
> > 	message gathered was complete or it is a part of a 
> larger message...
> > 	just to avoid this situation...
> > 
> > 	BR Iván Arias Rodríguez
> > 
> 
> -- 
> 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 ¦
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 13 Dec 2002 05:39:36 -0700

Ivan.Arias-Rodriguez,

What I meant was the SCTP equivalent of the neo-classical TCP teardrop
attack.  In this attack a malicious endpoint sends the first fragment
(e.g. TSN), skips one, and then sends the rest.  In a variation, it
sends the first fragment, skips a whole bunch and then sends the last
fragment.

Both variations attack the way the implementation reserves buffer space
for reassembly.

So, in the first variation of the attack in SCTP terms, the malicious
endpoint sends the first fragment (B not E) with TSN=100 and then sends
many (not B not E) fragments starting at TSN=102 and continuing.

The receiver is forced to buffer fragments until its buffer capacity is
full.  Then it could partial deliver TSN=100, but then it is stuck by
the hole at missing TSN=101.  How the receiver behaves now depends on
how susceptable it is to the attack.

Also consider that in variation, the hole can large or small.  The
malicious endpoint could, for example, send (B not E) on TSM=100 and
then start again with (not B not E) at TSN=100000.

One good way for the receiver to behave after a_rwnd drops below an MTU
is to either stop acking or start reneging TSNs but to never let the
memory allocated for reassembly exceed preset bounds.

There is a another tear-drop variation which could be used to attack
SCTP: that would be placing one or more holes in the SSN sequence for
one or more streams and witholding one or more TSNs.  This would be an
attack on resequencing just as the other is an attack on reassembly.

This one is a little more complicated and some implementations might be
more susceptable to this because, although they track the buffer space
used by the TSNs themselves, they might not set bounds on the system
space required to retain gap information for resequencing, and also
might not do bounds checks on things like SACK gap lists.  Also, they
might do non-optimal processing for gaps that would result in O2 or
greater rise in processor capacity consumption with the complexity of
the gaps.

Again, a good way for the receiver to protect against this is place
strict bounds on gap analysis resources and start discarding TSNs
between gaps and reneging on the gap acks.  (Here a_rwnd might not have
fallen to zero yet, so ACKs cannot be withheld without causing the
association to fail.)

Combination attacks are possible: middle fragments with missing SSNs on
multiple streams with missing TSNs.

TCP implementations that reserved reassembly space by using the segment
offset of the latest message were quite susceptable to this.  One could
set the offset arbitrarily high and the TCP receiver would reserve that
much memory even though the data actually received was small.

Not saying that such an SCTP implementation exists, but if an SCTP
implementation makes the mistake of allocating system resource without
bounds to the missing information (missing fragments, SSNs, TSNs) it
would also be susceptible to variations of this attack.

--brian

On Fri, 13 Dec 2002, [email-masked] wrote:

> 	However, as SCTP packets doesn't have any offset, I fail to see how
> 	this can affect at the SCTP level... Do you mean illegal fragmented
> 	user messages that do not follow the "natural" order of flags in
> 	consecutive TSNs (flags BE = 10, 00, 01)?... Something like (flags BE
> 	= 10, 10, 01, 00...).
> 
> 	I test that flag B can only (and must) be set if previous TSN had its
> 	E flag set or if it is the cumulative TSN ACK and we are not in the
> 	middle of a partial delivery... But I don't remember right now what I
> 	do afterwards if the peer makes these weird things... probably closing
> 	the association... :-/
>