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

From: Tuexen Michael <[email-masked]>
Date: Thu, 14 Feb 2002 12:45:04 +0100

Dear all,

if a attacker wants to bring down an association by sending
this kind of INITs he has to guess the verification tag. This
is difficult. And if he knows the verification tag he can do anything.

So I do not see the possibility of a DOS here.

Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	Andreas Jungmaier [SMTP:[email-masked]]
> Sent:	Thursday, February 14, 2002 1:27 PM
> To:	[email-masked]; Hollaus Thomas; [email-masked]'
> Cc:	[email-masked]
> Subject:	[Tsvwg] Possible DoS in SCTP ?  (was: [SCTP-Discussion] receive of unexpected chunks with invalid parameters)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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  / \
> -----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-----
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg

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