linux-kernel - 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: <7A4B9BD9-B2BF-4625-A2E5-500CD4A6D399@lurchi.franken.de>
Date:	Wed, 4 Dec 2013 17:01:24 +0100
From:	Michael Tuexen <Michael.Tuexen@...chi.franken.de>
To:	Vlad Yasevich <vyasevich@...il.com>
Cc:	David Laight <David.Laight@...LAB.COM>,
	Sun Paul <paulrbk@...il.com>, 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

On Dec 4, 2013, at 4:41 PM, Vlad Yasevich <vyasevich@...il.com> wrote:

> On 12/04/2013 09:50 AM, David Laight wrote:
>>>> 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.
> 
> I guess that would be problematic if A can not receive traffic for
> 192.168.1.1 on the interface connected to LAN X.  I shouldn't
> technically be a problem for C as it should mark the path to 192.168.1.1
> as down.  For A, as long as it doesn't decide to ABORT the association,
> it shouldn't be a problem either.  It would be interesting to know more
> about what problems you've observed.
> 
>> 
>> Connections between A and D fail unless the HB errors A receives
>> for 192.168.1.2 are ignored.
> 
> Yes, this configuration is very error prone, especially if system B and
> system D are up at the same time.  Any attempts by system A to use
> LAN Y will result in an ABORT generated by system B.  I have seen
> this issue well in production and we had to renumber system D to solve
> it.
The point is that address scoping should be used. When sending an
INIT from 10.10.10.1 to 10.10.10.4 you should not list 192.168.1.1,
since you are transmitting an address to a node which might or might
not "be in the same scope". We had IDs for that in the past, but
they never made it to RFC state, because they were not progressed enough
by the authors. Maybe we should push them again...

Best regards
Michael
> 
> -vlad
>> 
>> 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
>> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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/