Subject: Re: [rtcweb] SCTP user-land stack available

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Jan 2012 17:28:19 +0100

(after a long delay)
thank you very much for the input!

I've downloaded and compiled the code, but haven't yet found out how to 
do the typical "hello world" call with the binaries provided.

Could you give us a note saying "do this and see the packets flow"?

            Harald, experimenter

On 11/18/2011 02:17 PM, Michael Tüxen wrote:
> Dear all,
>
> I just wanted to let you know that the initial version of the
> SCTP user-land stack based on the FreeBSD kernel code for SCTP
> is available at
> http://sctp.fh-muenster.de/sctp-user-land-stack.html
>
> It currently support FreeBSD, Linux and Mac OS X. We are
> currently working on adding support for Windows, adding
> more examples and improving the API.
>
> Best regards
> Michael
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 17 Jan 2012 17:39:16 +0100

On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote:

> I've downloaded and compiled the code, but haven't yet found out how to do the typical "hello world" call with the binaries provided.
> 
Sure. Give me a day or two to put out a new release, which support Windows and IPv6
and some other options for the testprogram, which will allow a simple usage
for testing.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 20 Jan 2012 13:02:30 +0100

> Could you give us a note saying "do this and see the packets flow"?
Hi Harald,

an updated version of the user-land stack is available from
http://sctp.fh-muenster.de/sctp-user-land-stack.html

It now supports the platforms Windows in addition to FreeBSD, Linux and Mac OS X.
It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation variants
SCTP/UDP/IPv4 and SCTP/UDP/IPv6.

In libusrsctp-0.9.0/programs you find examples programs.

Please note that you need to run the programs with root privileges,
if you want to use native SCTP/IPv4 or SCTP/IPv6.

For example, you can run
sudo ./discard_server
in one shell and
sudo ./client 127.0.0.1 9
in another shell.
Whatever you type on the console will be sent to the discard server.
Wireshark will show the packets.

If you want to use UDP encapsulation, you can run
./discard_server 9899 9999
in one shell and
./client 127.0.0.1 9 9999 9899
in another shell.

Things are simpler, if you run the stack on two separate machines:
./discard_server
on one machine.
./client a.b.c.d 9 9899 9899
on the other.

Please note that the demo programs disable the sending of ABORTs
in response to out of the blue packets to allow running multiple
stacks on the same host. This is done by the line
	SCTP_BASE_SYSCTL(sctp_blackhole) = 2;
in the code. (On FreeBSD / Mac OS X kernel versions, you have such
a sysctl).

I hope this helps. If you have any further questions or issues,
please let me know.

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Jan 2012 13:32:52 +0100

Thank you - I now see the (UDP) packets flowing!

             Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 30 Jan 2012 19:58:19 +0100

Thanks again!

I've now spent a little time playing with it - it's been long since I've 
worked with C at this level!

One question I have is the handling of port numbers ... the way it 
currently seems to be structured, the SCTP layer is initialized with a 
listening UDP port number as a parameter to the sctp_init function, and 
the remote port is set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, 
on the listening socket (from discard_server.c) and the active socket 
(from client.c). So both when listening and when calling out, the remote 
UDP port is a necessary property of the socket.

This would mean that the mode of operation in an SCTP implementation 
embedded in a browser would be:

For each browser:
- Initialize SCTP to a single random local UDP port
For each PeerConnection desiring to use data:
- Perform ICE candidate finding to get candidates for this UDP port (or 
reuse)
- Perform ICE negotiation to associate the single UDP port to a remote 
UDP port
- Open an userspace SCTP socket and bind this to the remote UDP port 
(and address) of the best candidate
- (Use some DTLS mechanism to initialize DTLS as an encrypting sublayer 
for SCTP)
- One of the ends takes the initiative to set up the SCTP connection 
between the two
- Channels are then opened at will

Does that seem approximately right to you?

                            Harald

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 30 Jan 2012 22:05:56 -0800

On Mon, Jan 30, 2012 at 10:58 AM, Harald Alvestrand
<[email-masked]> wrote:
> One question I have is the handling of port numbers ... the way it currently
> seems to be structured, the SCTP layer is initialized with a listening UDP
> port number as a parameter to the sctp_init function, and the remote port is
> set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, on the listening socket
> (from discard_server.c) and the active socket (from client.c). So both when
> listening and when calling out, the remote UDP port is a necessary property
> of the socket.
>
> - Perform ICE negotiation to associate the single UDP port to a remote UDP
> port
> - Open an userspace SCTP socket and bind this to the remote UDP port (and
> address) of the best candidate

This seems problematic, since the ICE stack can change candidates
unbeknownst to the upper layers. IMO the SCTP stack needs to be
bound to an abstract datagram channel API, not to UDP transport.
This is certainly how I've anticipated DTLS would work in the absence
of SCTP.

> - (Use some DTLS mechanism to initialize DTLS as an encrypting sublayer for
> SCTP)

I'm not sure I understand this. If you're going to use SCTP over DTLS, then
you would put a DTLS shim under the SCTP layer (see above about the
abstract API). OTOH, if you're going to do DTLS over SCTP, then you
would probably just do SCTP negotiation and then stack DTLS over
top.

-Ekr

> - One of the ends takes the initiative to set up the SCTP connection between
> the two

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 31 Jan 2012 09:02:34 +0100

On Jan 30, 2012, at 7:58 PM, Harald Alvestrand wrote:

> Thanks again!
> 
> I've now spent a little time playing with it - it's been long since I've worked with C at this level!
> 
> One question I have is the handling of port numbers ... the way it currently seems to be structured, the SCTP layer is initialized with a listening UDP port number as a parameter to the sctp_init function, and the remote port is set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, on the listening socket (from discard_server.c) and the active socket (from client.c). So both when listening and when calling out, the remote UDP port is a necessary property of the socket.
Hi Harald,

this is correct.
> 
> This would mean that the mode of operation in an SCTP implementation embedded in a browser would be:
> 
> For each browser:
This depends on the stack you use:
(a) SCTP/DTLS/UDP
    Then you would the ICE stuff first, bound the UDP sockets, do the DTLS handlshake, and
    finally do the SCTP handshake. Please note that SCTP has to be changed to run on
    to of a connection oriented protocol. All stuff related to IP-addresses and UDP port
    numbers has to be taken out.
(b) DTLS/SCTP/UDP
    I would assume that you do the ICE stuff first, then configure the UDP port numbers to SCTP,
    then do the SCTP handshake, then the DTLS handshake. If ICE changes UDP port numbers,
    they can be changed in SCTP (maybe we need to tweak the current API). Or you use a lower
    layer which does the UDP encapsulation and run SCTP on top of that. This is more an
    implementation issue.

Best regards
Michael
> - Perform ICE candidate finding to get candidates for this UDP port (or reuse)
> - Perform ICE negotiation to associate the single UDP port to a remote UDP port
> - Open an userspace SCTP socket and bind this to the remote UDP port (and address) of the best candidate
> - (Use some DTLS mechanism to initialize DTLS as an encrypting sublayer for SCTP)
> - One of the ends takes the initiative to set up the SCTP connection between the two

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 31 Jan 2012 09:04:04 +0100

> bound to an abstract datagram channel API, not to UDP transport.
That is an implementation issue. Even with the current SCTP implementation
you can change the remote port on the fly.