linux-kernel - Supporting 4 way connections in LKSCTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFXGft+CXk3W8=3w=AuYzqYtYnR8nH4Of9=668tUeT+tugD9-A@mail.gmail.com>
Date:	Tue, 26 Nov 2013 09:03:31 +0800
From:	Sun Paul <paulrbk@...il.com>
To:	linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Supporting 4 way connections in LKSCTP

Hi

we have a problem on using LKSCTP to form a 4 ways multi-homing network.

Configuration
- Node-A has 2 IP addresses in different subnets, known as IP-A (eth1),
IP-B (eth2)
- Node-B has 2 IP addresses in different subnets, known as IP-X (eth1),
IP-Y (eth2)

the four way paths are shown below.
1. IP-A (11.1.1.1) to IP-X (11.1.1.11)
2. IP-B (12.1.1.1) to IP-Y (12.1.1.11)
3. IP-A (11.1.1.1) to IP-Y (12.1.1.11)
4. IP-B (12.1.1.1) to IP-X (11.1.1.11)

the HB/HB_ACK is normal for the paths " IP-A to IP-X" and "IP-B to
IP-Y", but it is not correct for the rest of two.

First of all, we are using iproute2 to form 2 table such that when
IP-B arrives on IP-X, it will know how to route back to IP-B on the
same interface, i.e (eth1). Same logic for the path "IP-A to IP-X".

What we observed here is that when 12.1.1.1 sends INIT to 11.1.1.11,
LKSCTP will send back the INIT_ACK to 12.1.1.1 using 12.1.1.11 but not
using the IP 11.1.1.11.

The above operation makes the subsequence HB/HB_ACK in using wrong IP address.

TCP trace on eth1
18:02:41.058640 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
[init tag: 19933036] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
18:02:41.061634 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
18:02:41.062642 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.062846 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.361811 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.661791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.961791 IP 11.1.1.11.2905 > 11.1.1.1.2905: sctp (1) [HB ACK]

TCP trace on eth2
18:02:41.058755 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
[init tag: 424726157] [rwnd: 131072] [OS: 5] [MIS: 5] [init TSN:
3340756356]
18:02:41.061696 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
18:02:41.062663 IP 12.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
18:02:41.062791 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.361777 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.661772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:41.961772 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:42.161771 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:42.461770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]
18:02:42.675770 IP 11.1.1.1.2905 > 12.1.1.11.2905: sctp (1) [HB REQ]


If we are using single homing, there is no problem on the SCTP
communication. Below is the TCP trace on eth1 using sctp_test

18:09:55.356727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [INIT]
[init tag: 32516609] [rwnd: 102400] [OS: 16] [MIS: 16] [init TSN: 0]
18:09:55.356811 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [INIT ACK]
[init tag: 3168861995] [rwnd: 131072] [OS: 10] [MIS: 16] [init TSN:
1877695021]
18:09:55.357727 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [COOKIE ECHO]
18:09:55.357788 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [COOKIE ACK]
18:09:55.358724 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
18:09:55.358740 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]
18:09:55.379715 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [DATA]
(B)(E) [TSN: 0] [SID: 0] [SSEQ 0] [PPID 0x3]
18:09:55.379735 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [SACK]
[cum ack 0] [a_rwnd 131064] [#gap acks 0] [#dup tsns 0]
18:09:55.657716 IP 12.1.1.1.2905 > 11.1.1.11.2905: sctp (1) [HB REQ]
18:09:55.657732 IP 11.1.1.11.2905 > 12.1.1.1.2905: sctp (1) [HB ACK]

>From the observations, it seems that the LKSCTP library is not able to
use the original local address when multi-homing is being used. Is
there anyway can be resolved it?

Thanks

PS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/