Re: Linux SCTP multihoming question

[Philipp Stanner <stanner@posteo.de>]

Am Samstag, dem 10.02.2024 um 18:02 +0000 schrieb David Laight:
> From: Philipp Stanner
> > Sent: 10 February 2024 17:49
> ...
> > > But won't that defeat the entire point of SCTP multihoming?
> > 
> > I guess it defeats the philosophy of the OS with its routing table
> > being solely responsible for choosing a source address.
> > I don't see how SCTP would be affected by that, though. SCTP
> > doesn't
> > demand a certain number of interfaces being available, nor does it
> > make
> > statements about how the networks behind the interfaces might or
> > might
> > not be interconnected.
> 
> You need to look at why it exists, and what it was trying to
> replicate.
> SCTP is all about carrying telephony signalling over the IP network.
> So it is trying (and failing for all sorts of reasons) to give
> the same sort of error detection and redundancy as SS7 MTP2 and MTP3.
> 
> The normal level of redundancy is to have two separate MTP2 links
> (a linkset) to each of two different remote MTP3 systems.
> If you are doing it right each MTP2 link is on a separate physical
> cable.
> The SCTP connection is trying to replicate the linkset to a remote
> system - so you need two local interfaces connected to two remote
> ones.
> You can have more, but it is basically pointless.
> 
> > > You need two interfaces in different subnets that use entirely
> > > separate IP networks to connect to the two addresses the remote
> > > system gives you.
> > > (There are really only ever two addresses for each system.)
> > 
> > I assume you're coming from the perspective of a user where SCTP is
> > utilized with completely redundant and separated networks for
> > redundancy.
> 
> That is what it is designed for.

All that may be true regarding the original _motivation_ behind the
protocol, but the relevant documents, the RFCs, make no such
statements.
And rightfully so, because a transport protocol should never be tied to
a specific narrow usecase, although people seem to have a hard time
learning that lesson (looking at you, QUIC).
You can even use SCTP as a mere TCP replacement, plainly writing to it
with write(). It's completely up to you. Just as the number of
interfaces you use is.

The protocol even specifies the upper layer protocol number field,
specifically designed to multiplex all sorts of payload protocols (SSH,
HTTP...) over it.


P.

> 
> > I, however, have only used the protocol in the normal boring
> > Internet –
> > and there it's definitely possible to reach N endpoints from just 1
> > outgoing interface. All the endpoints are connected to the
> > Internet,
> > after all, so the routers will ultimately direct your packages to
> > the
> > target addr.
> 
> I hope you aren't running any of the SIGTRAM protocols...
> 
> > > I don't know what the standards people were smoking, but the
> > > default 'send all my IP addresses to the far end' is so broken.
> > 
> > How else could you implement it?
> > Only alternative I can think of would be to have some sort of
> > multi-
> > homing DNS that provides you with several addresses.
> 
> Given the security in all the SIGTRAN protocols you always used
> fixed IP addresses and (in reality) better be using VPN tunnels
> if you go anywhere near the public IP network.
> 
> You need some property that can be assigned to the local IP /
> interface
> to indicate which ones can be grouped together.
> This is already done to exclude localhost.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes,
> MK1 1PT, UK
> Registration No: 1397386 (Wales)