[remline]

SCTP would be the logical choice for supporting both streams and messages.

No one really wants to support a network with the evil of arbitrary UDP from the browser. In SCTP, the handshake combined with crypto tricks can allows a server to make sure the initiator stores a larger cookie than it needs to hold for verification, throttling the DDOS riffraff.

[mrmoka]

SCTP have been mentioned in the repo: https://github.com/Maksims/web-udp-public/issues/1#issuecomm...

[remline]

The reasoning there is kind of lame, every filter knows how to pass SCTP or UDP and doesn't pass SCTP since it is unpopular and UDP because stopping it is most of why you are filtering.

Making an SCTP web standard would improve endnode support (and actual app use) which is beginning to wane and are SCTPs adoption problems.

[rjsw]

There is already an extension to SCTP to encapsulate it in UDP, it isn't in Linux but is in the FreeBSD reference implementation.

The userspace SCTP stack that gets built into Firefox for use by WebRTC will do it too.

[remline]

The point of providing SCTP instead is not to open up UDP and all of the baggage of existing services that will answer expecting you to be you and not a relay for a malicious ad in your browser.

Similarly, once you have a userspace SCTP stack you have allowed the garbage to reach userspace resources.

Everyone knows how to not be a jerk while using UDP or SCTP, but people who have the goal of being a jerk are more manageable if you only give them remote SCTP access.

[rjsw]

Your security scenario only really works if you are happy with a symmetric firewall, that is one with the same filters in both directions.

My home firewall is set up to allow anything originating here to pass but block most things from outside. For this to work the firewall needs to be able to track the state of the protocol exchange which will be different for each protocol. Few firewalls can do this for SCTP or DCCP yet, I'm in the process of adding SCTP support to the one that I use.

[mrmoka]

In case of DCCP it can be implemented over UDP utilising existing firewall support for UDP traffic.

[mrmoka]

It is indeed a bit like chicken-and-egg situation here.

But SCTP implements reliability and ordered delivery making it more of an alternative to TCP, than a solution for low-latency communication with cases where reliability and/or ordered delivery is not required.

[rjsw]

There is also DCCP [1].

[1] https://en.wikipedia.org/wiki/Datagram_Congestion_Control_Pr...

[remline]

I'm not familiar with DCCP, but as long as browsers don't get access to DCCP-UDP encapsulation without some work by the user it seems like another alternative to use to use web security considerations as leverage to ween a critical mass off of UDP.

[remline]

rfc3257 page 3:

> SCTP supports the transportation of user messages that have no

> application-specified order, yet need guaranteed reliable delivery.

But most people don't really care (that insisting on re-delivering out of date packets will use some bandwidth,) they just have an existing UDP app they want to port to the web and converting it to SCTP is easy enough (I think I've even used an LD_PRELOAD to convert for that? But I may be confusing a different ULP substitution.)

Making them do that and set everything up is actually a good mechanism for protecting the rest of the internet and allowing a web SCTP that browsers could enable even by default, with less risk of in page ad hijackings, etc. Allowing UDP is something that I hope every browser leaves as impossible to allow without going into configuration or being in an entirely different use context of web APIs than a browser.

[fulafel]

WebRTC uses (UDP encapsulated) SCTP.