Subject: RE: [Tsvwg] question about security of multi-homing

From: [email-masked]
Date: Wed, 1 Aug 2001 11:35:51 +0300

Thank you for your comment!

However, if attackers want to send arbitrary packets to B directly to cause
DDOS, they should coordinate their action to launch the attack at the same
time.
With SCTP's multi-homing, they can only break several big webservers and
redirect the users packets to the victim B.

-----Original Message-----
From: ext Tuexen Michael [mailto:[email-masked]]
Sent: 2001?8?1? 15:09
To: [email-masked]'
Subject: RE: [Tsvwg] question about security of multi-homing

Dear all,
see my comments below.
Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, August 01, 2001 8:52 AM
> To:	[email-masked]
> Subject:	[Tsvwg] question about security of multi-homing
> 
> Hi,
> 
> It seems  there isn't authentication of the address list of an endpoint in
> SCTP.  If someone break into  A, add B's address to the address list of A,
> then shutdown A, will it cause a distributed deny of service to B ( if A
is
> a big ISP)?
	[Tuexen Michael]  Well, B will receive SCTP packets which are
	out of the blue. The handling of these packets is described in 
	RFC 2960 and may result in sending ABORTS.
	But an attacker could send arbitrary packets directly B. So I do
	not see a way SCTP helps the attacker...

> Thanks in advance!
> 
> > Zhang Dajiang
> > 
> > 
> > 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 01 Aug 2001 07:26:12 -0500

Zhang:

Let me see if I have this straight...  and I so
love to draw text diagrams in netscape :-)

+----------+            -----------
| attacker |-IP-A------/           \
+----------+           |            |     +----------------+
                       |  IP Net    |IP-Z-| Large Web Site |
+----------+           |            |     | or other server|
| Victim   |-IP-B------\            /     +----------------+
+----------+            -----------

Now Attacker sends

From:IP-A(INIT(IP-A,IP-B)--->To IP-Z

And of course IP-Z responds to IP-A setting up the association.

Now I did not understand your comment about "shutdown of A"
First let me examine the threat here..

An association  now exits between IP-A|IP-Z
                                  IP-B|

But of course IP-B is unaware..

Now IP-Z will send a heartbeat in about 30-32 seconds to IP-B 
since it is idle and receive an ABORT back from IP-B since
it does NOT have an assocation.

So the attacker would get a pair of packets every 30-32 seconds
for every assocation setup this way.

Now your comments on shutdown seem out of place... if IP-A does
a "shutdown" procedure the association is torn down with no
packets going to IP-B. If you mean IP-A goes away... well
that is possible... aka IP-A's host is shutdown and halted...

But some important points:

A) It HAD to be present in order to do the
INIT/INIT-ACK/COOKIE/COOKIE-ACK
B) Since it halted the processor (somehow) it has only queued a
   delayed number of packets 30-32 seconds later based on the
   number of associations it setup.
C) When a stack halts like this.. if it has a chance the kernel would
   hopefully kill a number of these off by sending out ABORT's during
   the shutdown procedure. I would think the attacker would need to
   have some way to halt the processor without the normal shutdown
   process... which may be possible but still more difficult..

Considering how few of packets the attacker can generate it seems
to me that he would be better off to use some other mechanism...
You sure don't get much bang for the buck... 

In fact if this happened to often I bet you would see web-servers
(if they used SCTP) disabling heartbeats....

R

[email-masked] wrote:
>         [Tuexen Michael]  Well, B will receive SCTP packets which ar

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 01 Aug 2001 11:33:18 -0500

Randy,

Not exactly. I think what Dajiang says is that (using your diagram
below), what if someone hacks into the kernel of the big Web site (say,
Yahoo!) and adds the victim's IP address (say, your home site address
IP-B) along side the real Yahoo address IP-Z. From that point on, when
people access Yahoo they will see Yahoo as multi-homed with IP-Z and
IP-B and your home site will get maybe half of the normal traffic of
Yahoo and hence be attacked.

First, I don't know how realistic it is to hack into the kernel of a big
site and insert a fake IP address into the stack. Secondly, if the guy
is already in the kernel of the machine, then he/she can simply insert a
small code to amplify all the incoming traffic and re-direct it to the
victim IP-B without going through the trouble of inserting the IP
address into the stack.

I don't see SCTP's multi-homing adding any DOS vulnerability here.

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Wed, 01 Aug 2001 13:56:17 -0500

Qiaobing...

some comments..

> Yahoo and hence be attacked.

Boy.. this would be a REAL cracker then :-0  But I don't see that
this is as big of an issue.. of course depending on HOW SCTP
implementations
pick the primary address you may or may not get 1/2 of the traffic..

> victim IP-B without going through the trouble of inserting the IP

I think I agree with you 100%. If the cracker has reached the level
where he can penetrate your kernel playing this small game with 
SCTP is the least of your worries... I think it is un-realistic 
to think you could replace the running kernel with your image
and get away with it.. If you did I think there are a LOT of
other harms the cracker could do besides mes with SCTP ...

> I don't see SCTP's multi-homing adding any DOS vulnerability here.

I agree... 

R