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 for Android: free password hash cracker in your pocket

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

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B745F@saturn3.aculab.com>
Date:	Wed, 4 Dec 2013 16:48:16 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Vlad Yasevich" <vyasevich@...il.com>,
	"Michael Tuexen" <Michael.Tuexen@...chi.franken.de>
Cc:	"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

> 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".

You might have two machines that are connected via the public
internet and also via a private network.
The two sets of cabling being completely separate giving you
resilience to network failure.
In which case you definitely don't want address scoping.

While you may not want the SCTP traffic on the public network
itself, it could easily be routed separately.

We have systems that 'sort of' designate one interface for SIP/RTP
and the other for 'management'. They might run M3UA/SCTP but no one
has really thought enough about which interface(s) the M3UA traffic
should use.
(Think of an ISUP/SIP gateway using M3UA for ISUP signalling.)

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html