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.

Am 14.09.2016 um 18:02 schrieb Simon Ryf simon@swinog.org:

Dear SwiNOG supporter,

this is the official Call for Paper email. Please send your proposal to swinog-core (at) swinog.ch or directly to me. The 30th meeting of the Swiss Network Operators Group (SwiNOG) will be held in Berne on top of the Gurten on November 4th 2016.

Important Dates for SwiNOG#30

17.08.2016 Announcement of Meeting 05.09.2016 Registration opens 14.09.2016 Call for Papers 16.10.2016 Call for Papers closing 23.10.2016 Final publication of agenda 27.10.2016 Registration closes 01.11.2016 Deadline for all slides 04.11.2016 Meeting day

Topics for Presentations/Talks

The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 5 to 45 minutes. Here is a non-exhaustive list of typical SwiNOG meeting topics:

• Security - DDOS Mitigation - AntiSpam
• IPv6
• Open Source tools
• International view of the internet (incidents, outages, measurements)
• Routing
• Server applications (DNS, Web, etc.)
• Legal issues (BÜPF, etc.)
• Telecommunication politics (Net Neutrality, Incumbent monopoly, etc.)

-> PLEASE feel free to talk to us about any kind of topic and collaboration!!! You can always start a discussion on the list - I'm sure people join in.

Language of Slides and Talks

The whole day will be held in English, therefore we kindly ask you to produce your presentation in English.

Submission Guidelines

All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information to <swinog-core at swinog.ch>:

• the name of the presenter (and if applicable your affiliation)
• a working email address
• the name and number of the topic which will contain the presentation
• the title of the presentation
• its expected length (in minutes)
• a short abstract of the presentation (so we know what it is about)

We also welcome suggestions for specific presentations which you feel would be valuable to the SwiNOG community. Please be aware that your presentation will be published on the SwiNOG website after the event. We can publish modified slides if requested - it might be that some confidential data will be presented by you which are not intended for publication on the internet.

Greetings, Simon Ryf SwiNOG Core Team

General Information (SwiNOG Community)

The Swiss Network Operators Group (SwiNOG) is an informal group of people who are concerned with engineering and operation of the Swiss Internet. SwiNOG exists to enhance the quality of Internet services available in Switzerland. It does this by fostering the free exchange of technical ideas and information between different companies and organisations. SwiNOG is a community for professionals who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community.

More information about SwiNOG can be found at http://www.swinog.ch/, Facebook, Xing, Information about the meeting will be published at http://www.swinog.ch/meetings/swinog30/

General Information (SwiNOG Organisation)

The SwiNOG Organisation Association is a non-profit association under article 60 and further of the swiss civil law. It manages the SwiNOG community ressources (domain, web, mailing-lists, etc..) and organises SwiNOG meetings.

Contact: SwiNOG Organisation 8000 Zurich Switzerland

---

swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Andreas Fink DataCell ehf, Backbone ehf, Cajutel Inc, Alisanus GmbH ------------------------------------------------------------------ c/o Fink Telecom Services, Clarastreasse 3, 4058 Basel, Switzerland E-Mail: andreas@fink.org https://www.fink.org Mobile: +41-78-6677333 Office: +41 61 6666330 Skype: andreasfink Jabber/XMPP: andreas@fink.org ICQ: 8239353 ------------------------------------------------------------------

Am 14.09.2016 um 18:33 schrieb Jeroen Massar jeroen@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.

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.

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

Apple chose to use Multipath TCP instead...

OS X has a implementation of SCTP since OS X 10.3.8. Its open source. Apple has not added it to the kernel (besides promising it many many many times) because it would mean changing their NAT & Firewall as well and as there is no user demand, they where too lazy and rather wanted to spend time on nice shiny guy stuff. The kext is kernel dependent due to a missing API to link in a layer4 protocol so every new version needs awaiting new kernel sources to be published and recompiling (10.12 however worked out of the box with 10.11 sources). I have like 20 radars open with Apple about it (*big sight*).

Linux has SCTP built in since a long time. Solaris, has it. HP/UX has it. Windows I actually don't know.

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.

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*).

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()) However there are additional features which neither TCP or UDP have such as seamless adding removing IP's on a established session, Multipath support. stream multiplexing, concurrent establishment of a connection from both sides (think of tunnels for example) and others. From a developers point of view there's a lot in it, especially if you care about reliability. SCTP is proven, reliable, established and well supported in the Unix arena. Developers just have to know about that its there and it is useful for many things.

That's why I think the key is to let developers know that there's a cherry to be picked up. And I would be happy to present its benefits and features.

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.

Andreas Fink

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 <jeroen@massar.ch mailto:jeroen@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#Implement...

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