SCTP Discussions

Text archives Help


[SCTP-Discussion] AW: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid pa rameters)


Chronological Thread 
  • From: Hollaus Thomas <thomas.hollaus AT siemens.at>
  • To: "'Andreas Jungmaier'" <ajung AT exp-math.uni-essen.de>, discussion AT sctp.de
  • Subject: [SCTP-Discussion] AW: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid pa rameters)
  • Date: Thu Feb 14 15:07:00 2002
  • List-id: SCTP Discussions <discussion.sctp.de>

Dear all,

The established association with sctp.de implementation is not safe, because
it will be deleted on receive of e.g. INIT with MIS=0 or OS=0.


Mit freundlichen Gruessen / Best regards
Thomas Hollaus

SIEMENS AG Austria
Program and Systems Engineering
mailto:thomas.hollaus AT siemens.at
http://www.pse.siemens.at


> -----Ursprüngliche Nachricht-----
> Von: Andreas Jungmaier
> [mailto:ajung AT exp-math.uni-essen.de]
> Gesendet am: Donnerstag, 14. Februar 2002 15:51
> An: Randall Stewart
> Cc:
> discussion AT sctp.de;
> Hollaus Thomas;
> tsvwg AT ietf.org
> Betreff: Re: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid
> parameters)
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> > Andreas Jungmaier wrote:
> > > -----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.
> - --
> -
> --------------------------------------------------------------
> ----------
> 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
>
> iD8DBQE8a864XAsLBNOCSsARAlUzAKCYTPXsNH2p23b3DAKM0/Ye7m73XACfZ9I8
> a8KoEnC8KTIbBut4WLULsrI=
> =6OgC
> -----END PGP SIGNATURE-----
>




Archive powered by MHonArc 2.6.19+.

Top of page