Subject: RE: [Tsvwg] SCTP Vulnerability

From: [email-masked]
Date: Tue, 20 Mar 2001 14:33:30 +0200

> Have you seen this one yet?
> 
> 
> Problem:
> 
>     An SCTP endpoint which implements the "SHOULD" parts of RFC 2960
>     Section 8.4 or the MUST parts of Section 5.1 can be made to send
>     ABORT chunks to an arbitrary address with arbitrary verification
>     tags.
> 
> Description:
> 
>     Section 8.4:
> 
>     Evil endpoint 'E' sends an OOTB packet to 'A' spoofing source
>     address of the Target 'T'.  If endpoint 'A' sends ABORT to
>     OOTB as it SHOULD from Section 8.4, it will send ABORT to
>     'T' with T-bit set and VTAG from attacker's message.
> 
>     +------+     SRC:T      +------+     DST:T      +------+
>     |      |     DST:A      |      |     SRC:A      |      |
>     |  E   |--------------->|  A   |--------------->|  T   |
>     |      |     VTAG:Z     |      |     VTAG:Z     |      |
>     +------+                +------+     T-Bit      +------+
> 
>                 HEARTBEAT                ABORT
> 
>     The target 'T' is vulnerable (and 'A' gullable) in the COOKIE-WAIT
>     and COOKIE-ECHOED states on the selected port.  By flooding, 'E'
>     could possibly deny initialization of associations from 
> 'T' to 'A's
>     well-known port numbers.
> 
>     Solution: Don't send ABORT in response to OOTB as indicated
>     in RFC 2960 Section 8.4.

	I'm not so sure I'm missing something, but, wouldn't it be that the
ABORT would be rejected if it doesn't have the right verification tag
(peer's one, or ours if the T bit is set)?. During COOKIE-WAIT and
COOKIE-ECHOED states for T, A doesn't have any boundaries at all yet with T,
so, you are right when saying that A would send that ABORT chunk to T, but
it would have the T bit set, and the verification tag set to one random
value chosen by E that doesn't match A's or T's tag, so T would discard
it... wouldn't it?

	T could receive lots of ABORTs, ok, but it will discard them all,
and proceed with the initialization process. As soon as A receives the
COOKIE ECHO chunk, A would start discarding the chunks sent by E, since it
would find an association but the Verification Tag wouldn't match...

	Maybe I'm wrong, but I would say that this wouldn't cause any
trouble...

>     Section 5.1:
> 
>     Evil endpoint 'E' sends an OOTB INIT to 'A' with missing or
>     invalid mandatory parameters spoofing source address of the
>     Target 'T'.  If endpoint 'A' sends ABORT to OOTB INIT as
>     it MUST in Section 5.1, it will send ABORT to 'T', without
>     T-bit set and with the VTAG from the attacker's INIT ITAG.
> 
>     +------+     SRC:T      +------+     DST:T      +------+
>     |      |     DST:A      |      |     SRC:A      |      |
>     |  E   |--------------->|  A   |--------------->|  T   |
>     |      |     VTAG:0     |      |     VTAG:Z     |      |
>     +------+     ITAG:Z     +------+                +------+
> 
>              Bad INIT                    ABORT
> 
>     The target 'T' is vulnerable (and 'A' gullable) in the COOKIE-WAIT
>     and COOKIE-ECHOED states on the selected port.  By flooding, 'E'
>     could possibly deny initialization of associations from 
> 'T' to 'A's
>     well-known port numbers.
> 
>     Solution: Don't send ABORT in response to refused INIT in
>     violation of RFC 2960 Section 5.1.

	I think that there is exactly the same problem here with the tags...
In my opinion this attack wouldn't work either...

> 
> Solution:
> 
>     Do not, or throttle, sending ABORT to OOTB packets.

	Thanks!

	BR Iván Arias Rodríguez

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 20 Mar 2001 14:21:14 -0500 (EST)

After the tsvwg session monday, I discussed with Randy and La Monte the
issue I pointed out about unreliable, ordered data suffering
unnecessary delays due to SOME head-of-line blocking. They temporarily
convinced me that it was a non-issue. After further thinking and a
re-read of the draft, I realized that there is some ambiguity in the draft
and depending on the interpretation, it could still be an issue.

The draft is not clear on how the receiver should handle reordering. There
are two possible definitions of partial reliability and each implies a
different way of handling reordering. Let me explain the two possible
definitions.

Definition 1: A lost partially reliable chunk is retransmitted at most 'k'
times.  Hence, the receiver MUST wait for a FORWARD TSN from the sender
before determing that the a given lost chunk should be given up on. If the
recever needs to deliver data to the application and the lost chunk has
still not arrived, the receiver cannot give up on the lost chunk until all
'k' restransmits have been used.

Definition 2: A lost partially reliable chunk continues to be
retransmitted until either the receiving end needs to deliver
new data to the application OR the 'k' retransmit value is reached.
In other words, if the receiver needs to deliver data to the application
and the lost chunk still hasn't arrived, the receiver gives up on it and
moves on.

To me, the draft implies Definition 1. That is the reason I originally had
an issue with zero-retransmit, ordered delivery. In this case, even if the
packet should never be retransmitted, there is unnecessary delay.

After my discussion with Randy and La Monte, I realized that the intended
definition in the draft was in fact Definition 2. My feeling is that
Definition 2 is the better way to go, but this may need more research.
If Definition 2 is used, an infinite 'k' value does not mean full
reliability. Instead, it simply means continue retransmitting until the
receiver determines it needs to move forward and give up on the lost
chunk.

Additionally... From what I understood (and I may be wrong), the IP
Storage people prefer Definition 1 for their needs.

Comments?

-----------------------------------------------------------------------
Armando L. Caro Jr.                                  [email-masked]
University of Delaware                   http://www.cis.udel.edu/~acaro
-----------------------------------------------------------------------

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 21 Mar 2001 00:40:53 -0600

Armando,

This's really an implementation choice on the receiver side. Either
definition will work just fine, with slightly different performance
characteristics - Definition 1 trades delay for reduced message loss,
while Definition 2 trades loss for reduced delay. 

-Qiaobing

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 21 Mar 2001 11:00:51 -0500 (EST)

This is NOT an implementation issue. These definitions are 2 big
differences in how the protocol works. Each provides a totally different
service to the ULP. One could imagine an application that NEED and depend
on one service, but if it uses the other service, it will break down.

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Mar 2001 08:40:13 -0600

> receiver determines it needs to move forward and give up on the lost

I am not sure how you could ever get from our converstation definition
2... if it is not clear it will be made clear in the next U-SCTP
specification. A receiver SHOULD wait for the F-TSN before releasing
any out-of-order U-SCTP data. If this wording is not in the
draft it will break the contract that exists between the sender
and the receiver.

I understand your thoughts for multi-media... but this is not
the primary intent of the draft. If someone wanted to use it
for multi-media then send UN-Ordered data and let the upper
layer put RTP or some such inside the SCTP data packet. Then it
can do what EVER it likes for jitter buffer etc...

Of course this is a receiver side behavior anyway not something
that effects the bits on the wire but the actual internal API
of the reciever... maybe this is why we did not get it into
the document yet :0

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)