[jeroenhd]

SCTP is fascinating because it's one of the backbone technologies that makes communication possible for most people on the planet (as the mobile network stack pretty much relies on it), yet it's effectively unsupported on almost every consumer device. If you want to use it, you're probably going to have to ship a userland implementation that needs privileges to open a raw network socket, because kernel implementations are rare (and often slow).

We could've had it as a QUIC replacement if it weren't for terrible middleboxes and IPv4 NAT screwing everyone over once again. Hell, NAT wouldn't even have been an issue had SCTP support been widespread before consumer NAT devices started being implemented.

It's a prime example of how new network protocols now have to lie and deceive to work over the internet. TLS needs to pretend to be TLS 1.2, QUIC needs to pretend to be an application on top of UDP while reimplementing SCTP and TCP, and even things like secure DNS are now piped over HTTPS just in case a shitty middlebox can't deal with raw TLS.

[tsimionescu]

While the gist of your post is spot on, I do feel it should be noted that DoH is preferred over DoT not to protect from middleboxes that don't work properly, but from middleboxes that are actively trying to outright censor encrypted DNS, but can't afford to snoop on/prevent all HTTPS traffic. It's an anti-censorship measure, not a compatibility measure.

[capitainenemo]

It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/

[tsimionescu]

DoT (DNS over TLS) would have been enough for privacy from your ISP, using a dedicated port. It's only when you want to protect from censorship that you need to hide the (encrypted) DNS traffic among other traffic that can't be easily blocked.

[nickburns]

Security through obscurity is not the same as actual concealment. That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted.

Many LAN operators conclude that the pragmatic impossiblility of blocking DoH is a net-negative for both network security and censorship avoidance.

[tsimionescu]

> That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted.

Of course there is. Blocking all traffic with destination port 443 is virtually impossible. Conversely, blocking port 853 is trivial, and it forces all clients to either not resolve DNS, or downgrade to un-encrypted DNS.

Of course, if DoH had not been encrypted, it wouldn't have mattered that it uses port 443. But being encrypted yet easily identifiable would have also defeated half the point.

[nickburns]

You've sidestepped my point and merely reiterated yours.

Both DoH and DoT achieve actual concealment (and therefore privacy and censorship avoidance) through encryption. That one is more obscure than the other doesn't change the fact that the whole point of both protocols is encrypted DNS queries, not obscured DNS queries.

And again, if I'm the network operator and a host can obscure/obfuscate its DNS queries, then I've lost some measure of control over my network and the hosts that connect to it. I can trivially redirect all TCP/853 traffic to my DoT-capable resolver of choice. I can't do the same for all TCP/443 traffic (i.e. redirect it to my DoH-capable resolver of choice).

I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted. The whole point is maintained, and I've maintained control over my private network.

[bewo001]

Actually, every browser supporting webrtc datachannel supports SCTP over UDP.

[tepmoc]

Diameter in mobile network is heavy user of SCTP, but from what I've read they moving away from diameter into HTTP calls for 6G.

[bennettnate5]

For communication between carriers and some communications within a given carrier's network components, yes. Base stations all still communicate with the core network over SCTP, though.

[api]

It’s too bad the original IP could not have included some kind of stronger header integrity lock to block middle boxes.

It would have forced us to adopt V6 and… my god… the network would be so much cleaner and superior in every way. Things would just have addresses, and protocol innovation at L3 would be possible.

[hylaride]

I'd like to agree with you, but IPv6 had such a classic case of suffocation by committee during its birth that I doubt it would have been pushed by such a situation. IPSec was mandated in the original IPv6 RFC, for god's sake. That alone delayed a lot of work in implementing it as crypto code needed to be integrated into kernels, which was not common in those days. That's to say nothing about the fact that IPSec is loosely defined enough that setting it up between different vendors is always an adventure - adding support to an IP stack was a big headache (I followed OpenBSD at the time they were integrating IPv6 in the early 2000s and there was a lot of hard problems around compatibility).

Header integrity was so far off of consideration during IPv4's implementation because the internet was a dozen universities and DoD sites that it was overkill (and possibly a waste of limited CPU cycles at the time).

What's far more likely to have happened is that we'd see more proxies instead of NATs (SOCKS, etc). I don't think that'd be better than NAT.

[graealex]

It's funny that you mention IPSec, since that would have made most of the application-level encryption we see today obsolete. They did have good intentions, and if it was widely accepted, it would have meant that barely any applications would have had to deal with the details of encryption, including the ever-looming possibility of doing it wrong (doing encryption right is hard!).

Now we have a slew of protocols that either implement TLS, or roll their own custom thing, or have X-over-HTTPS protocols, including SSTP and DoH.

[hylaride]

IPSec was far too complicated, loosely defined, and over-engineered to have ever been widely accepted. Any host verification would need to involve application level verification anyways to make sure the other end is who you expect. So your browser would need to verify the encrypted tunnel is in face connected to google, or whoever. There’s a reason SSL/TLS is done at the application level.

[api]

There's some history I'm not aware of here. I didn't know just how bad the V6 second system committee shitshow was.

Today V6 has been stripped down almost to what it should have been: bigger addresses, then stop. All that's left to get there is to deprecate SLAAC or make it optional.

[kstrauser]

SLAAC’s awesome, though. It’s one of the good parts we definitely want to keep.

[hylaride]

SLAAC is awesome, but DNS support in it didn't show up until much later. The result is a mish-mash of DHCPv6/SLAAC support (and android famously doesn't support DHCPv6 at all and windows only supported DHCPv6 until windows 10).

[api]

Let's say your ISP gives you a /64. Now you have to use V6 NAT... or assign a /96 internally. SLAAC won't let you do that.

That, among other things, is a problem. SLAAC is too limited.

You can use DHCPv6 but then you can't use Android because Android, and I think they're alone here, stubbornly and dogmatically refuses to implement it. I guess you could go around and statically assign V6 IPs to Android devices, or run NATv6 with SLAAC for those and DHCPv6 for everything else, but that's annoying as hell.

[labcomputer]

Then your ISP isn’t following the RFCs. You might as well ask what you would do if you ISP gives your router a 17.0.0.0/8 address via DHCP.

These are completely invented problems in your head. SLAAC can absolutely advertise a single /64 internally. It can advertise any /64 you tell it to.

DHCPv6 can absolutely respond with DNS servers (and nothing else) in parallel. Configuring your SLAAC daemon to tell clients to get DNS servers via DHCPv6 is a 15 minute exercise with google.

[kstrauser]

Android's right on this one (and I don't own an Android device that I know of, so this isn't me fanboying them). TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup.

[nly]

It gets worse in practice. Congestional control algorithms on the internet need to play nice with TCP Cubic regardless of how good they are.

[nesarkvechnep]

As with most of the network stack, *BSD implementation is the reference implementation.

[immibis]

What we can learn from this is that there are networks other than The Internet, and even The Internet can be subdivided into parts that don't really work together.