5 ms·

Thanks for this answer but I still don't understand, sorry. What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent anothe

Thanks for this answer but I still don't understand, sorry. What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? It's already in the kernel, seems to have had its own share of CVEs that it should now be relatively trustable? But it's also available in userland, especially over UDP. Performance is fine, from my benchmarks. Ease of use is (to me) far better than TCP and all the socket-hand-holding you need to do (if you don't use zmq because tired of writing the same all the time). Flexibility of substreams is amazing. Multi-homing is great so you can bond links at the applicative level (so, higher decoupling instead of ip-bonding). I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need.

tialaramex 7y ago
> What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements that). > I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need. If you "just" drop the encrypted transport on top you either have to do all the work to deliver features like substreams yet again, or else all the metadata in the layer that's not encrypted is left unprotected and you'll regret that.
- nitrogen 7y ago
  In addition to that I believe I've read that SCTP can't traverse all of the networks that TCP and UDP can, so any universal datagram protocol will have to build on UDP.
- touisteur 7y ago
  Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 https://tools.ietf.org/html/rfc3436 don't know whether any userland lib supports this with sctp-over-UDP.
  - tialaramex 7y ago
    I explained the negative consequences of just layering TLS on top in my comment already. RFC3436 just makes pairs of SCTP streams (one in each direction) into a transport like TCP that TLS will run on top of. Each such stream-pair then does a TLS handshake. That's not what QUIC does. The entire QUIC connection, however many streams and in whichever direction, is encrypted. As a very simple example - suppose you spin up three parallel stream pairs to fetch three separate documents over a hypothetical HTTP-over-TLS-over-SCTP. With RFC 3436 you reveal to an on-path adversary that there are three streams, and they get to see how much data travelled over each stream. But with QUIC it's just an opaque pipe, the on-path adversary can see how much data was transmitted each way but can't determine whether that's one document in one stream, or ten documents in two streams or anything else.
    - touisteur 7y ago
      Sorry I did not mean to say you were wrong, I just meant to say 'it exists', for reference. I understood your first explanation, didn't know whether this RFC encrypted substream by substream or the whole session (I should have read more before posting). Thanks for the clarification. And your patience.

tialaramex 7y ago

> What's missing in SCTP (used everywhere in telephony/3-4-5g, right?) that we had to reinvent another complete transport+session layer ? SCTP isn't encrypted. Because "Pervasive Monitoring is an Attack" new IETF protocols should be encrypted or explain why they can't be. HTTP/2 for example is in effect always encrypted (the document explains how one could in theory build an unencrypted variant but nobody implements that). > I'm genuinely curious as to why they haven't just taken SCTP as is, and added the extensions (?) they need. If you "just" drop the encrypted transport on top you either have to do all the work to deliver features like substreams yet again, or else all the metadata in the layer that's not encrypted is left unprotected and you'll regret that.

nitrogen 7y ago
In addition to that I believe I've read that SCTP can't traverse all of the networks that TCP and UDP can, so any universal datagram protocol will have to build on UDP.
touisteur 7y ago
Ah, encryption, thanks. Thought there was a sctp+tls RFC https://tools.ietf.org/html/rfc3436 https://tools.ietf.org/html/rfc3436 don't know whether any userland lib supports this with sctp-over-UDP.
- tialaramex 7y ago
  I explained the negative consequences of just layering TLS on top in my comment already. RFC3436 just makes pairs of SCTP streams (one in each direction) into a transport like TCP that TLS will run on top of. Each such stream-pair then does a TLS handshake. That's not what QUIC does. The entire QUIC connection, however many streams and in whichever direction, is encrypted. As a very simple example - suppose you spin up three parallel stream pairs to fetch three separate documents over a hypothetical HTTP-over-TLS-over-SCTP. With RFC 3436 you reveal to an on-path adversary that there are three streams, and they get to see how much data travelled over each stream. But with QUIC it's just an opaque pipe, the on-path adversary can see how much data was transmitted each way but can't determine whether that's one document in one stream, or ten documents in two streams or anything else.
  - touisteur 7y ago
    Sorry I did not mean to say you were wrong, I just meant to say 'it exists', for reference. I understood your first explanation, didn't know whether this RFC encrypted substream by substream or the whole session (I should have read more before posting). Thanks for the clarification. And your patience.