TLDR: I think it would be great if a list of ACTUAL programs/tools which do use SCTP could be listed. Google does not reveal many...
On 2016-09-14 20:26, Andreas Fink wrote: > >> Am 14.09.2016 um 18:33 schrieb Jeroen Massar <jer...@massar.ch >> <mailto:jer...@massar.ch>>: >> >> On 2016-09-14 18:13, Andreas Fink wrote: >>> I could do a presentation on the SCTP networking protocol which combines >>> some features of TCP and UDP and offers some unique features neither TCP >>> nor UDP have. >> >> Is there any tool that actually uses SCTP ? :) > > I'm using it day in day out since 15 years. And theres no alternative to > it for me. The Sigtran family (SS7 signalling over IP) requires it > mandatory. Theres no other option there. SCTP was mainly developed > because signalling over IP needed reliable multipath support. So > protocols which 100% depend on SCTP are at least M2UA, M2PA, M3UA, SUA, IUA. I rarely see any of that kind of traffic (looking at Netflow/IPFIX of rather large networks...). End-users definitely will not see it. Few developers bother with that stuff either. Thus outside of SIGTRAN, any other actual things that use it? >> IPFIX is supposed to use it, but everybody still sends over UDP, rare >> support for SCTP (except for purists like me who did implement it and >> then also never really used it). > > Great. why did you not use it? UDP is not a reliable datagram service. > SCTP is. UDP is reliable enough over short distance. No need to bother with the complexity of SCTP. If the management or monitoring network of a network is unreliable you got bigger problems. Indeed, NetFlow/IPFIX are not sent over this magic Internet thing that drops packets like crazy. Oversubscriptions are also rare on those kind of links. And in many cases the collector is next to the thing that generates it, thus the real question is: why bother with the complexity of SCTP? Also, for reliability one can also just send Netflow or IPFIX over TCP: no magic needed there. Yes, I am fully aware of the 'advantages' of SCTP. But in many cases there is no need for them. Wiresharking a UDP or TCP stream is also so much easier than peeking through an SCTP stream that might go haywire with features nobody really needs. >> WebRTC is supposed to go partially over SCTP, never seen it actually used. > > WebRTC requires it (but can work around by encapsulating it into UDP > which just means more useless overhead). While it requires it. Does any implementation actually do anything with it? :) Because THAT is the point. IPFIX also "requires" SCTP. Does not mean that any implementation actually uses it (even when they might support it to be 'compliant'). As you note, without Windows + OSX having SCTP in the default install, how can you even remotely claim that WebRTC does any kind of SCTP when there are no users who could use it? As long as the Googles/Facebooks of the world do not care, endusers will never get to use it transparently. >> Apple chose to use Multipath TCP instead... [..] > Linux has SCTP built in since a long time. Solaris, has it. HP/UX has > it. Windows I actually don't know. Windows has the magic: http://www.bluestop.org/SctpDrv/ Or actually, see what I referenced the list on Wikipedia: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol#Implementations Hence why I state: what does actually use it? In Linux btw it is recommended by many to disable it, so in firewalls, as it is a not-very-well-checked codebase: read likely many vulns: http://www.cvedetails.com/cve/CVE-2016-1879/ http://www.cvedetails.com/cve/CVE-2015-8767/ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8160 and many many more. Though indeed you'll find CVEs anywhere. But you'll find more 0-day ones in code that does not really get tested/used... > Part of the problem is: If desktops don't have it, then developers > don't tend to use it. If developers don't want to use it, then the OS > vendors dont tend to implement it. This however also applies to other > layer 4 transport protocol. Thats why everyone uses plain old TCP and UDP. As a Developer, I actually do implement it. But that does not mean that even though I know the protocol and how to support it that I am going to use it, as well, there is no actual real benefit over plain TCP for reliable or UDP if some packets maybe may get lost. Yep, changing endpoints etc is fun, but how well does that scale when the endpoint is not truly in IP style and actually is anycasted/loadbalanced. SCTP is indeed a second class citizen: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306428 > Also 10$ crap ADSL routers who don't understand how to properly > implement NAT don't help either. Hopefully NAT will be a relict of the > past soon due to IPv6 (*cough cough*). Nah, lots of ISPs are implementing IPv6 wrongly, hence you will have lots of IPv6 NAT. That is a lost race since the beginning as ISPs go for money, not actual service. >> The article on Wikipedia does not list much more: >> https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol >> >> Apparently some variant of SSH should support it, but no actual >> implementations mentioned there either. > > Any application which uses TCP or UDP could be changed into using SCTP > by a single line of code. (hint: IPPROTO_SCTP on socket()) That just makes SCTP behave like TCP. Really really bad idea. You actually need other calls to make it behave better. And you would be missing out of the multiple streams too. REAL SCTP support takes quite a bit more. I suggest you read through RFC6458. The appendixes are a lot of fun... > [..] SCTP is proven [..] While it might be used for some niche things. The Internet at large unfortunately does not want to evolve and will stick everything inside HTTP(S). One major reason: it load balances really really well. The overhead of SCTP over TCP is also much much more compared to even the amount of packets that TCP needs for establishing a session. Check out protocols like QUIC and the reasoning behind those and you'll notice that they really want to minimize handshakes, not explode them. > reliable, established and well supported in the Unix arena. Does not matter unless one is doing server-server. No end-users there. > Developers just have to know about that its there and it is useful for > many things. There are soooo many things "developers" still have to learn. Many of them are still not aware of this much more important thing called IPv6 even though many folks have been telling them for years already. Note that there are "developers" and "coders", the latter typically get things right though ;) But as you love to complain about developers: what tools did you make? > That's why I think the key is to let developers know that there's a > cherry to be picked up. Now if only SwiNOG was SwiDEV... ohno 2016, thus SwiDevOps! Mostly network folks here... some of them though might program network tools though ;) Yeah, SCTP might be interesting, but more from a "should I ban this from my network" perspective. See CVEs above... > And I would be happy to present its benefits and features. I am pretty sure I know all the "benefits" and features of SCTP. Still: KISS is a good principle and SCTP does not come close to that. (not that TCP is overly complex... ;) ) > But if we only have java developers here who usually encode a boolean > into a UTF16 string into XML over SOAP over HTTP over a 10G fiber link, > then it would be a waste of time of course. JDK7 apparently has support for SCTP since 2009. http://www.oracle.com/technetwork/articles/javase/index-139946.html Not that I do Java, but just point out to you that those folks might do something with it; if they would bother too. Many of your SIGTRAN things btw are Java based... Also checking this little IANA list of ports: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt where is your protocol that uses SCTP? :) A full total of 75 ports with SCTP, which includes combos like ipfix+ipfixs (guess who's name is in those drafts) and sip+sips. Noting that many protocols could have 'sctp' added to it, eg AYIYA which happily tunnels over anything... And yes, IPv6 faces those same problems already for a much longer time. Without a clear *business* benefit though many things won't come to fruition. And with IPv6 their is now a business 'benefit': CGN/DS-Lite returns 'rare' IPv4 addresses to the pool to be sent at a much higher price to business users... Greets, Jeroen _______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
