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] [day] [month] [year] [list]

Message-Id: <E816D349-2DE7-4F28-9297-F212ED4C6935@lurchi.franken.de>
Date:	Thu, 5 Dec 2013 14:07:41 +0100
From:	Michael Tuexen <Michael.Tuexen@...chi.franken.de>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	"Vlad Yasevich" <vyasevich@...il.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 5, 2013, at 10:35 AM, David Laight <David.Laight@...LAB.COM> wrote:

>>>> the configured addresses could be:
>>>> System A) 10.0.0.1 on Lan X, 10.10.0.1 on Lan Y
>>>> System B) 10.0.0.2 on Lan X, 10.10.0.2 on Lan Y
>>>> System C) 10.0.0.3 on Lan X, 10.10.0.2 on Lan Z
>>>> 
>>>> Same problem will occur.
> ...
>> With that, Sys A talking to Sys C will get an abort
>> from Sys B when trying to talk to 10.10.0.2.  With /8, it'll be
>> even worse since SysB and SysC will have duplicate addresses
>> within the subnet. :)
>> 
>> The point is that you don't always know that the same private subnet
>> is in reality 2 different subnets with duplicate addresses.
>> 
>> I've had to debug an actual production issue similar to this where
>> customer had a very similar configuration to above, and their
>> associations kept getting aborted.  When I tried accessing the
>> system that kept sending aborts, I found it was some windows
>> server and not a Diameter station they were expecting.
> 
> Does seem that the addresses listed in INIT and INIT_ACK chunks
> should be ignored until a valid HB response has been received.
You are not allowed to send DATA to them until they are confirmed.
> If an abort is received before a valid HB response then the
> address should be ignored rather than the connection aborted.
No.
> Then it wouldn't matter anywhere near as much if addresses are
> advertised that are not reachable from the remote system.
> 
> All this should have been thought about when the original RFC
> was written.
Scoping wasn't considered that much, same as NAT traversal.
The assumption was that in SIGTRAN networks no NAT boxes are
deployed and you use appropriate addressing (for redundancy).

Best regards
Michael
> 
> 	David
> 
> 
> 
> 

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