6 ms·

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 p

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 2y ago
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 2y ago
  It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/ https://www.cloudflare.com/learning/dns/dns-over-tls/
  - tsimionescu 2y ago
    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 2y ago
      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 2y ago
        > 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 2y ago
        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.
        tsimionescu 2y ago
        I guess we're generally in agreement on the facts, just looking at this from different sides. You're mostly commenting on the negative effect that DoH has over a private network administrator's legitimate need to control DNS resolution in their own private network. I was discussing how DoH has positive effects on a network user trying to evade illegitimate control over their DNS resolution on the Internet, such as legally enforced DNS-based censorship of certain sites. Several countries have legally mandated ISPs log and prevent resolution of, say, thepiratebay.com; and some include a requirement to prevent attempts at circumvention of these bans, such as DoT traffic (they might also ban DoH traffic to well known resolvers, which is where own proxies come in). Regardless, I think we can both agree that DoH was not created to work around ossification, the way QUIC was built on top of UDP instead of being a separate transport. > I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted. Also, this is another level of miscommunication. I agree you don't need DoH to protect from eavesdropping, DoT works just as well. DoH protects from ISPs dropping easily-identifiable DoT packets to force a downgrade to regular plaintext DNS.
nly 2y ago
It gets worse in practice. Congestional control algorithms on the internet need to play nice with TCP Cubic regardless of how good they are.
tepmoc 2y ago
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 2y ago
  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.
bewo001 2y ago
Actually, every browser supporting webrtc datachannel supports SCTP over UDP.
api 2y ago
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 2y ago
  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.
  - api 2y ago
    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 2y ago
      SLAAC’s awesome, though. It’s one of the good parts we definitely want to keep.
      - 2y ago
nesarkvechnep 2y ago
As with most of the network stack, *BSD implementation is the reference implementation.
immibis 2y ago
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.

tsimionescu 2y ago

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 2y ago
It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/ https://www.cloudflare.com/learning/dns/dns-over-tls/
- tsimionescu 2y ago
  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 2y ago
    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 2y ago
      > 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 2y ago
        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.
        tsimionescu 2y ago
        I guess we're generally in agreement on the facts, just looking at this from different sides. You're mostly commenting on the negative effect that DoH has over a private network administrator's legitimate need to control DNS resolution in their own private network. I was discussing how DoH has positive effects on a network user trying to evade illegitimate control over their DNS resolution on the Internet, such as legally enforced DNS-based censorship of certain sites. Several countries have legally mandated ISPs log and prevent resolution of, say, thepiratebay.com; and some include a requirement to prevent attempts at circumvention of these bans, such as DoT traffic (they might also ban DoH traffic to well known resolvers, which is where own proxies come in). Regardless, I think we can both agree that DoH was not created to work around ossification, the way QUIC was built on top of UDP instead of being a separate transport. > I don't care that an eavesdropper can observe discrete TCP/853 traffic because it's encrypted. Also, this is another level of miscommunication. I agree you don't need DoH to protect from eavesdropping, DoT works just as well. DoH protects from ISPs dropping easily-identifiable DoT packets to force a downgrade to regular plaintext DNS.

nly 2y ago

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

tepmoc 2y ago

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 2y ago
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.

bewo001 2y ago

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

api 2y ago

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 2y ago
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.
- api 2y ago
  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 2y ago
    SLAAC’s awesome, though. It’s one of the good parts we definitely want to keep.
    - 2y ago

nesarkvechnep 2y ago

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

immibis 2y ago

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.