Subject: [Tsvwg] Establishment of SCTP association

From: [email-masked]
Date: Wed, 17 Dec 2003 17:33:19 +0200

Hello,

We noticed an interesting behaviour in Linux SCTP implementation. 

1. Endpoint A sends an INIT chunk to endpoint B using IPa as a source IP address and IPb as a destination IP address

2. Endpoint B returns INIT ACK to endpoint A using IPc as a source IP address and IPa as a destination IP address. IPb is included in INIT ACK as an address parameter.

3. A and B finish the association negotiation, endpoint A using IPb as its primary IP address and endpoint B using IPc as a source address when it sends data chunks to endpoint A. 

My question is: although RFRC2960 does not explicitly deny the use of IPc as a source IP address in INIT ACK, when implementation does so, doesn't this present a security hole in the association setup procedure? Therefore such behaviour should not be allowed.

For example, in a man-in-the-middle attack hostile node could highjack the association by responding to INIT, which endpoint A sent, faster than endpoint B, using hostile node's own IP address IPz as a source IP address. Obviously this attack assumes that the endpoint A selects the source IP address IPz as its primary IP address.

/Mikael

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 19 Dec 2003 17:23:13 -0700

Mikael.Latvala,

I don't know about lksctp implementation, but we pretty much hashed out
and plugged all those security holes in the Implementor's Guide.  This
behaviour is safe as long as the correct rules are followed with regard
to handling of initialization procedures, cookies and tie tags.

--brian

On Wed, 17 Dec 2003, [email-masked] wrote:

> 1. Endpoint A sends an INIT chunk to endpoint B using IPa as a source IP
> address and IPb as a destination IP address
> 
> 2. Endpoint B returns INIT ACK to endpoint A using IPc as a source IP
> address and IPa as a destination IP address. IPb is included in INIT ACK as
> an address parameter.
> 
> 3. A and B finish the association negotiation, endpoint A using IPb as its
> primary IP address and endpoint B using IPc as a source address when it
> sends data chunks to endpoint A. 
> 
> My question is: although RFRC2960 does not explicitly deny the use of IPc as
> a source IP address in INIT ACK, when implementation does so, doesn't this
> present a security hole in the association setup procedure? Therefore such
> behaviour should not be allowed.
> 
> For example, in a man-in-the-middle attack hostile node could highjack the
> association by responding to INIT, which endpoint A sent, faster than
> endpoint B, using hostile node's own IP address IPz as a source IP address.
> Obviously this attack assumes that the endpoint A selects the source IP
> address IPz as its primary IP address.
> 
> /Mikael
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 20 Dec 2003 13:03:10 +0100

Mikael,

a true man-in-middle can do everything: insert ABORTs when he wants and 
so on.
And not allowing that the other IP address is used as a source address 
does not
hel you. The true man in the middle can intercept the packet and return 
the
INIT-ACK with B's address as a source address. In general: a true 
man-in-the-middle
can do everything and there is not much a transport layer can do. You 
must
have some mechanism to identify your peer not based on the IP address. 
Possibilities
include IPSec or TLS.

Best regards
Michael

On 17. Dec 2003, at 16:33 Uhr, [email-masked] wrote:

> 1. Endpoint A sends an INIT chunk to endpoint B using IPa as a source 
> IP address and IPb as a destination IP address
>
> address and IPa as a destination IP address. IPb is included in INIT 
> ACK as an address parameter.
>
> 3. A and B finish the association negotiation, endpoint A using IPb as 
> its primary IP address and endpoint B using IPc as a source address 
> when it sends data chunks to endpoint A.
>
> My question is: although RFRC2960 does not explicitly deny the use of 
> IPc as a source IP address in INIT ACK, when implementation does so, 
> doesn't this present a security hole in the association setup 
> procedure? Therefore such behaviour should not be allowed.
>
> For example, in a man-in-the-middle attack hostile node could highjack 
> the association by responding to INIT, which endpoint A sent, faster 
> than endpoint B, using hostile node's own IP address IPz as a source 
> IP address. Obviously this attack assumes that the endpoint A selects 
> the source IP address IPz as its primary IP address.
>
> /Mikael
>