- 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-----
>
- [SCTP-Discussion] AW: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid pa rameters), Hollaus Thomas, 02/14/2002
Archive powered by MHonArc 2.6.19+.