Subject: [Tsvwg] Possible DoS in SCTP ? (was: [SCTP-Discussion] receive of unexpected chunks with invalid parameters)

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 14 Feb 2002 13:26:56 +0100

Hello Thomas, dear all,

please see my comments below.
I am CC'ing TSVWG to discuss this: does this open up a possibility
for DoS attacks ?

On Thursday, 14. February 2002 08:56, Hollaus Thomas wrote:
> Dear all,
>
> Question to unexpected chunks with invalid mandatory parameters (e.g.
> MIS=0, OS=0, Init-Tag=0):
> As far as I understand the sctp.de implementation, it is possible to attack
> a running association with e.g. an INIT and invalid mandatory parameters.
> After receive of that unexpected chunks the prototype does delete the
> running association (pre 16: sctp-control.c, func scr_init, line 677). Is
> that a correct behaviour according to RFC?

The implementation probably should return an ABORT with an Error Chunk
that specifies the appropriate error code, as per RFC 2960:
      Cause Code
      Value           Cause Code
      ---------      ----------------
       1              Invalid Stream Identifier
       2              Missing Mandatory Parameter
       3              Stale Cookie Error
       4              Out of Resource
       5              Unresolvable Address
       6              Unrecognized Chunk Type
   --> 7              Invalid Mandatory Parameter
       8              Unrecognized Parameters
       9              No User Data
      10              Cookie Received While Shutting Down

However, I am not actually sure that this is a good idea, since that
would make it easily possible (with IP spoofing) to start 
denial-of-service attacks. 
I think the rationale behind this in the RFC was to stop a broken 
client from keeping retransmitting wrong INITs and tell it directly 
WHAT is wrong, and that something is wrong.

Regards,
Andreas

- -- 
- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier              |                         _
Computer Networking Technology Group      | ASCII ribbon campaign  ( )
University of Essen                       |  - against HTML email   X
http://www.exp-math.uni-essen.de/~ajung   |              & vcards  / \

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 14 Feb 2002 07:16:10 -0600

Andreas:

I don't think so.. first of all the idea is this (correct
me if I am wrong):

Endpoint-A  <------------assoc----------> Endpoint-Z

Now someone else does this (with invalid mandatory parameters):

Evil-Endpoint :(from-E-A)INIT----------------> Endpoint-Z

Now Endpoint-Z SHOULD send back an ABORT to Evil-Endpoint but
it SHOULD NOT touch the association.. since this is an
overlapping case. As Michael said the only way that Endpoint-A
would tear down the association is if Evil-Endpoint guessed
or knew the V-Tag of the original association AND put that
in the I-Tag in the INIT. In that case (if Evil-Endpoint had
this information) it could just as easily:

a) Send a ABORT() directly to Endpoint-A
b) Send a Message in forged to Endpoint-A .. assuming if it
   has the V-Tag it also has the sequence number of the next
   TSN.

All of these presume more of a man-in-the middle type attack
where the Evil one can see what each side has...

I don't see this as a problem..

R

Andreas Jungmaier wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Thomas, dear all,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE8a60YXAsLBNOCSsARAox5AJsE6ZOjMxIdUyH/nsvpuokbGdjeMQCfaTU9
> 6vbLwcJXTjKeqSx/0zTrepA=
> =wK09
> -----END PGP SIGNATURE-----
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 14 Feb 2002 15:50:32 +0100

Dear all,

I am sorry for not explaining more exactly what I meant.
I am assuming an attack with IP-Spoofing. The evil attacker 
(say E) is spoofing poor victim (say V), using oblivious 
server (say) O. 

Now, 

 Evil-Endpoint E: 
  Source IP V(spoofed)
  Dest IP O
  SCTP-INIT (invalid params) ----------------> Server O
                                   /-------------/  
               SCTP-Abort,Error   /
  Poor Victim V   <--------------/                                 

Now, if E can use V, it could send such packets to a large number
of servers. And then V gets bombed with Aborts.

I agree fully, that an established association is safe, but that
was not the issue I was thinking about. Comments ?

Andreas

> > > As far as I understand the sctp.de implementation, it is possible to
> > > attack a running association with e.g. an INIT and invalid mandatory
> > > parameters. After receive of that unexpected chunks the prototype does
> > > delete the running association (pre 16: sctp-control.c, func scr_init,
> > > line 677). Is that a correct behaviour according to RFC?
> >
- --

---

From: Randall Stewart <[email-masked]>
Date: Thu, 14 Feb 2002 08:40:34 -0600

Andreas:

There is no amplification here though... so it is no
different than if Evil-E sent the aborts itself
to all the "victims" V... it must send N packets
to get N packets to victims... this is no
different than a UDP attack.. in fact a UDP attack
is easier...

R

Andreas Jungmaier wrote:
> iD8DBQE8a864XAsLBNOCSsARAlUzAKCYTPXsNH2p23b3DAKM0/Ye7m73XACfZ9I8
> a8KoEnC8KTIbBut4WLULsrI=
> =6OgC

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 14 Feb 2002 17:36:28 +0100

Randy, 

please see my comments inline.

> different than a UDP attack.. in fact a UDP attack

Well, *almost*. The only problem I see here is that many
network installations by now have already adapted to UDP
attacks, e.g. by filtering excessive amounts (or simply all)
ICMP dest. unreachble packets (which are subsequently 
jamming the targets/victims network).

With SCTP, however, it is not that simple: you get back
a transport layer packet that is much harder to filter. 
Think about it: there have been MANY distributed DoS attacks
based on UDP, why shouldn't there be some based on SCTP some
day ?

BTW, John: I am not concerned about cycles for processing
ABORTs. The problem really arises when an attacker starts a lot
of "Evil Endpoints E", that all have one target: Victim V.
The scarce resource is bandwidth.

- --

---

From: Randall Stewart <[email-masked]>
Date: Thu, 14 Feb 2002 09:43:25 -0600

> a transport layer packet that is much harder to filter.

How is SCTP harder to filter than UDP.. UDP IS a transport
protocol and the ports in the UDP/TCP header are in the
same place as the SCTP header...

> based on UDP, why shouldn't there be some based on SCTP some

Or TCP.. at this level though your attacker is limited
to the bandwidth/cpu of the Evil-E machine. This is NO
different than TCP or UDP or anything else out there
now...

I fail to see how it is an issue..

R

> iD8DBQE8a+eMXAsLBNOCSsARAmPfAJ47qG/Zy9+7omHnCOkbhsNR1b73QwCfZSQz
> vIKQ3YdsJjzX46WI8XX/Qbk=
> =g5mQ

---

From: Randall Stewart <[email-masked]>
Date: Thu, 14 Feb 2002 10:07:56 -0600

Andreas Jungmaier wrote:
> Hi all,
> Yes, but the UDP does not cause the DoS -- it is the ICMP
> destination unreachable packets sent in reply to a UDP packet, that
> cause the problems.
> 

Ok.. ICMP may be used so it does NOT get filtered.. but
in SCTP's case if you do the bounce.. you respond with an
ABORT.. which CAN be filtered.. of course it kills the
association in the end .. but that is what filtering would do..

> No, that was my point. In typical DDoS scenarios, there is
> thousands of Evil-E's, directed by one central process. This has
> been done by e.g. the Stacheldraht based DDoS attacks.
> I am not saying this is much of an issue, I am saying that
> SCTP can be used, as other protocols, for (D)DoS attacks.

So what is the issue.. none I think... TCP and UDP have these
same problems... 

SCTP IS a transport protocol and thus it to gets the same
issues as UDP and TCP..

R

> Best regards,
> > > -
> > > ------------------------------------------------------------------------
> iD8DBQE8a+3fXAsLBNOCSsARAm4GAJ9P8xD5loz/k4p2eSHeYefJj/3uEgCfbM15
> WsAQnnBB9g6F3Vsmyqqj0xI=
> =TK7O

---

From: Andreas Jungmaier <[email-masked]>
Date: Thu, 14 Feb 2002 18:03:27 +0100

Hi all,

Best regards,
Andreas

- --