Chronological Thread 

< Chronological >      < Thread >

---

-----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] receive of unexpected chunks with invalid parameters, Hollaus Thomas, 02/14/2002
  • Possible DoS in SCTP ? (was: [SCTP-Discussion] receive of unexpected chunks with invalid parameters), Andreas Jungmaier, 02/14/2002
    • Re: [Tsvwg] Possible DoS in SCTP ? (was: [SCTP-Discussion] receive of unexpected chunks with invalid parameters), Randall Stewart, 02/14/2002
      • [SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid parameters), Andreas Jungmaier, 02/14/2002
        • [SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ? (was: reception of invalid parameters), Randall Stewart, 02/14/2002
          • [SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ?, Andreas Jungmaier, 02/14/2002
            • [SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ?, Randall Stewart, 02/14/2002
              • [SCTP-Discussion] Re: [Tsvwg] Possible DoS in SCTP ?, Andreas Jungmaier, 02/14/2002

---

Archive powered by MHonArc 2.6.19+.