SCTP Discussions

Text archives Help


[SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid parameters)


Chronological Thread 
  • From: Randall Stewart <randall AT stewart.chicago.il.us>
  • To: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
  • Cc: discussion AT sctp.de, Hollaus Thomas <thomas.hollaus AT siemens.at>, tsvwg AT ietf.org
  • Subject: [SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid parameters)
  • Date: Thu Feb 14 18:32:51 2002
  • List-id: SCTP Discussions <discussion.sctp.de>

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:
>
> -----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-----
>
> _______________________________________________
> tsvwg mailing list
> tsvwg AT ietf.org
> https://www1.ietf.org/mailman/listinfo/tsvwg

--
Randall R. Stewart
randall AT stewart.chicago.il.us
815-342-5222 (cell phone)




Archive powered by MHonArc 2.6.19+.

Top of page