Chronological Thread 

< Chronological >      < Thread >

---

Andreas:

I don't think so.. first of all the idea is this (correct
me if I am wrong):

Endpoint-A <------------assoc----------> Endpoint-Z

Now someone else does this (with invalid mandatory parameters):

Evil-Endpoint :(from-E-A)INIT----------------> Endpoint-Z

Now Endpoint-Z SHOULD send back an ABORT to Evil-Endpoint but
it SHOULD NOT touch the association.. since this is an
overlapping case. As Michael said the only way that Endpoint-A
would tear down the association is if Evil-Endpoint guessed
or knew the V-Tag of the original association AND put that
in the I-Tag in the INIT. In that case (if Evil-Endpoint had
this information) it could just as easily:

a) Send a ABORT() directly to Endpoint-A
b) Send a Message in forged to Endpoint-A .. assuming if it
has the V-Tag it also has the sequence number of the next
TSN.

All of these presume more of a man-in-the middle type attack
where the Evil one can see what each side has...

I don't see this as a problem..

R


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.
>
> Regards,
> Andreas
>
> - --
> - ------------------------------------------------------------------------
> 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
>
> iD8DBQE8a60YXAsLBNOCSsARAox5AJsE6ZOjMxIdUyH/nsvpuokbGdjeMQCfaTU9
> 6vbLwcJXTjKeqSx/0zTrepA=
> =wK09
> -----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)

---

• [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+.