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

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.

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.

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.

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.

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

The grandparent poster stated that they don't want to encapsulate stuff in UDP.

Generally, yes. I suppose if the client were unable to override the default recipient port for DCCP-UDP Encapsulation (6511) and the DCCP implementation were enforcing rules such as back off on the client then it is still a better option to give a client a DCCP socket that can enable UDP encapsulation rather than giving inspecific access to UDP.

The point that seems to be getting lost is not that I want SCTP or DCCP support. Its that I don't think anyone should accept anything that could become a UDP arbitrary access loophole. The point of the current path is to replace the problem techs and add use cases safely as we go to gradually pay for a better network by making standards that aren't just the easiest thing for web-devs.

Every time someone tries to walk too close to the edge in a way that can open security problems for people who aren't running a server fully opted-in to web 2.0/etc, they risk a security backlash that could ban browser updates and effectively delay/kill unrelated innocent features and fixes with ripples for ~5-10 years.

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.

There is also DCCP [1].

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

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.

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.

WebRTC uses (UDP encapsulated) SCTP.