Subject: [Tsvwg] SCTP NAT_attack

From: Florian Niederbacher <[email-masked]>
Date: Tue, 26 Aug 2008 12:39:30 +0200

Hi,
I have read the NAT-draft[draft-stewart-behave-sctpnat] 
<http://tools.ietf.org/id/draft-stewart-behave-sctpnat-04.txt> from 
behavewg. I made a lot of practical tests with the NAT considerations, 
so that SCTP works now fine with them. On the other side this draft 
explains also how easily a "SCTP- NAT attack" can be done. If an 
attacker is able to read the IP traffic it can modify the IP address 
(like NAT it does). The receiver sends to the wrong IP an ABORT back. If 
this packet is then redirected to the original IP, a connection loss is 
the result. In this case an attacker has a possibility to shutdown SCTP 
connections. In RFC4960 (SCTP) and RFC 5062 (Security attacks SCTP) I 
couldn't find any information which matches this case.
My proposal would be to insert this kind of attack in RFC 5062.
Maybe I am missing something, then correct me please. What's your 
opinion about this scenario?

Best regards
Florian Niederbacher

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 27 Aug 2008 08:30:43 +0200

Hi Florian,

SCTP (except for extensive use of SCTP-AUTH) does not protect against  
on-path
attackers. They know the verification tags and when they can forge  
source
addresses can send all SCTP packets on behalf of one end-points. They  
can
not only terminate the association (send an ABORT) but also insert user
data and so on.

That is known and pretty common to other transport protocols like TCP,  
UDP
or DCCP.

Protection against on-path attackers is much harder than protection  
against
off-path attackers. If you want to protect your traffic also against  
on-path
attackers you can use SCTP-AUTH to authenticate all allowed chunks and  
use
for example DTLS to establish a shared secret. Then an on-path  
attacker is
not able anymore to insert DATA or terminate the association. However,
he can still just dump all packets and perform a DOS attacker. You can
only use multihoming to protect against that attack as long as the
on-path attacker is not an on-path attacker on all paths...

An RFC can not be changed. One could write another ID to obsolete a  
given
one. But the problem you describe is known since the pre RFC 2960 time
and not SCTP specific, so I would not spent the effort to write up a
new ID.

The usage of SCTP-AUTH to protect against on-path attackers is covered
in RFC 4895.

Best regards
Michael

On Aug 26, 2008, at 12:39 PM, Florian Niederbacher wrote:

> Hi,
> I have read the NAT-draft[draft-stewart-behave-sctpnat] <http://tools.ietf.org/id/draft-stewart-behave-sctpnat-04.txt 
> > from behavewg. I made a lot of practical tests with the NAT  
> considerations, so that SCTP works now fine with them. On the other  
> side this draft explains also how easily a "SCTP- NAT attack" can be  
> done. If an attacker is able to read the IP traffic it can modify  
> the IP address (like NAT it does). The receiver sends to the wrong  
> IP an ABORT back. If this packet is then redirected to the original  
> IP, a connection loss is the result. In this case an attacker has a  
> possibility to shutdown SCTP connections. In RFC4960 (SCTP) and RFC  
> 5062 (Security attacks SCTP) I couldn't find any information which  
> matches this case.