netdev - RE: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B745D@saturn3.aculab.com>
Date:	Wed, 4 Dec 2013 14:50:46 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Vlad Yasevich" <vyasevich@...il.com>,
	"Sun Paul" <paulrbk@...il.com>
Cc:	<netdev@...r.kernel.org>, <linux-sctp@...r.kernel.org>,
	"Karl Heiss" <kheiss@...il.com>,
	"Neil Horman" <nhorman@...driver.com>,
	<linux-kernel@...r.kernel.org>
Subject: RE: Supporting 4 way connections in LKSCTP

> > In normal operation, IP-A sends INIT to IP-X, IP-X returns INIT_ACK to
> > IP-A. IP-A then sends HB to IP-X, IP-X then returns HB_ACK to IP-A. In
> > the meantime, IP-B sends HB to IP-Y and IPY returns HB_ACK.
> >
> > In case of the path between IP-A and IP-X is broken, IP-B sends INIT
> > to IP-X, NODE-B uses IP-Y to return INIT_ACK to IP-B. Then IP-B sends
> > HB to IP-X, and IP-Y returns HB_ACK to IP-B. In the meantime, the HB
> > communication between IP-B and IP-Y follows the normal flow.
> >
> > Can I confirm, is it really valid?
> 
> As long as NODE-B knows about both IP-A and IP-B, and NODE-A knows about
> both IP-X and IP-Y (meaning all the addresses were exchanged inside INIT
> and INIT-ACK), then this situation is perfectly valid.  In fact, this
> has been tested an multiple interops.

There are some network configurations that do cause problems.
Consider 4 systems with 3 LAN segments:
A) 10.10.10.1 on LAN X and 192.168.1.1 on LAN Y.
B) 10.10.10.2 on LAN X and 192.168.1.2 on LAN Y.
C) 10.10.10.3 on LAN X.
D) 10.10.10.4 on LAN X and 192.168.1.2 on LAN Z.
There are no routers between the networks (and none of the systems
are running IP forwarding).

If A connects to B everything is fine - traffic can use either LAN.

Connections from A to C are problematic if C tries to send anything
(except a HB) to 192.168.1.1 before receiving a HB response.
One of the SCTP stacks we've used did send messages to an
inappropriate address, but I've forgotten which one.

Connections between A and D fail unless the HB errors A receives
for 192.168.1.2 are ignored.

Of course the application could explicitly bind to only the 10.x address
but that requires the application know the exact network topology
and may be difficult for incoming calls.

	David