[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.

[rjsw]

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

[remline]

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.