making SCTP loadable and removing it from GENERIC

[Michael Tuexen]

> On 10. Jul 2020, at 12:29, Doug Hardie <bc979 at lafn.org> wrote:
> 
>> On 10 July 2020, at 02:39, Michael Tuexen <tuexen at freebsd.org> wrote:
>> 
>> Hi Eugene,
>> 
>> you are completely right. However, it requires that the program needs to run
>> with root privileges just to be able to communicate.
>> In the context of userland stack, this is one of the most important issues.
>> In case of SCTP, this is needed to open a raw socket to send/recv SCTP packets.
>> This is one of the reasons why you use UDP encapsulation...
> 
> I see RFC 6951 on UDP encapsulation and understand there are situations where that would be needed.  However, my replication processes do run as root.  Just for fun, I started them as non-root and SCTP worked just fine.  I didn't see any raw sockets in a ktrace of the processes.
> 
> 76330 replicate CALL  socket(PF_INET6,0x5<SOCK_SEQPACKET>,IPPROTO_SCTP)
> 76330 replicate RET   socket 5
Hi Doug,

sorry, I wasn't clear.

If you use an SCTP kernel stack, you don't need root privileges, except for binding to a
port smaller than 1024. This is the same for TCP and UDP.

If you want to use a userland SCTP stack, the program must be able to send and receive
SCTP packets. That is done via a raw socket, which need root privileges to be opened.

Since you are using a kernel stack, you don't see any raw socket interactions, but
the opening of an SCTP socket.

The FreeBSD SCTP sources are also the basis of the SCTP userland stack usrsctp. That
is why I have some experience with people running userland SCTP stacks. One of the
issues they report, is that they don't want to run an application with root privileges
just to do communication. I agree with that.
To avoid using root privileges just for network communication, the solution is to use
a kernel stack or a userland stack with raw sockets, which can be realised by using UDP
encapsulation.

If you run you application as root due to other constraints, there is no problem for
you to also load a kernel module. So you do not have the problem I was referring to.

Best regards
Michael
> 
> -- Doug
>