- From: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
- To: discussion AT sctp.de, Hollaus Thomas <thomas.hollaus AT siemens.at>
- Subject: Re: [SCTP-Discussion] AW: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid pa rameters)
- Date: Thu Feb 14 16:22:01 2002
- List-id: SCTP Discussions <discussion.sctp.de>
- Organization: University Essen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas,
if you assume an *already established* association between two
endpoints A and B, and one of these sends a _new_ INIT with
invalid parameters, then indeed the assoc will be deleted.
Acc. to RFC2960, the peer should, however, send an ABORT with
an Error Chunk, and THEN remove itself. The sctplib-implementation
from www.sctp.de currently does not send an ABORT with Error Chunk.
It is not unsafe for that reason.
After an INIT with invalid parameters the association
will be gone (for the server, if the INIT chunk contains the
invalid parameters) anyway !
Regards,
Andreas
On Thursday, 14. February 2002 15:02, Hollaus Thomas wrote:
>
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-----
>
>
_______________________________________________
>
discussion mailing list
>
discussion AT sctp.de
>
http://www.sctp.de/mailman/listinfo/discussion
- --
- ------------------------------------------------------------------------
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
iD8DBQE8a+N1XAsLBNOCSsARAqWiAKCH4vuxsaO8rKMEj9Y4crBTZpYuXQCgydoz
xF49fKkxapqnfTpNsCGKyhQ=
=vxEl
-----END PGP SIGNATURE-----
Archive powered by MHonArc 2.6.19+.