Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Jeroen Massar]

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 > >:
>>
>> 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 

[swinog] PCH peering survey 2016

[Bill Woodcock]

Background:

Five years ago PCH conducted the first, and to date only, comprehensive survey 
characterizing Internet peering agreements.

The document that resulted can be found here: 
https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011.pdf 


That document was one of the principal inputs to an important document that the 
OECD publishes every five years, one that recommends communications regulatory 
policy to OECD member nations: 
http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=DSTI/ICCP/CISP(2011)2/FINAL&docLanguage=En
 


The survey had several useful findings which hadn’t previously been established 
as fact—most notably the portion of peering relationships that are “handshake” 
agreements, without written contract. These findings have improved the 
regulatory environments in which many of us operate our networks.

At the time of the 2011 survey, we committed to repeating the survey every five 
years, so as to provide an ongoing indication of the direction peering trends 
take. It’s now five years later, so we’re repeating the survey.

The survey is global in scope, and our goal is to reflect the diversity of 
peering agreements in the world; we’re interested in large ISPs and small ISPs, 
ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, 
private and public. Our intent is to be as comprehensive as possible. In 2011, 
the responses we received represented 86% of all of the world’s ISPs and 96 
countries. We would like to be at least as inclusive this time.

Privacy:

In 2011, we promised to collect the smallest set of data necessary to answer 
the questions, to perform the analysis immediately, and not to retain the data 
after the analysis was accomplished. In that way, we ensured that the privacy 
of respondents was fully protected. We did as we said, no data was leaked, and 
the whole community benefited from the trust that was extended to us. We ask 
for your trust again now as we make the same commitment to protect the privacy 
of all respondents, using the same process as last time. We are asking for no 
more data than is absolutely necessary. We will perform the analysis 
immediately upon receiving all of the data. We will delete the data once the 
analysis has been performed.

The Survey:

We would like to know the following five pieces of information relative to each 
Autonomous System you peer with:

• Your ASN
• Your peer’s ASN (peers only, not upstream transit providers or downstream 
customers)
• Whether a written and signed peering agreement exists (the alternative being 
a less formal arrangement, such as a "handshake agreement")
• Whether the terms are roughly symmetric (the alternative being that they 
describe an agreement with different terms for each of the two parties, such as 
one compensating the other, or one receiving more or fewer than full customer 
routes)
• Whether a jurisdiction of governing law is defined
• Whether IPv6 routes are being exchanged (this year, we’ll still assume that 
IPv4 are)

The easiest way for us to receive the information is as a tab-text or CSV file 
or an Excel spreadsheet, consisting of rows with the following columns:

Your ASN: Integer
Peer ASN: Integer
Written agreement: Boolean
Symmetric: Boolean
Governing Law: ISO 3166 two-digit country-code, or empty
IPv6 Routes: Boolean

For instance:

42  715  false  true  us  true 
42  3856  true  true  us  true 

We are asking for the ASNs only so we can avoid double-counting a single pair 
of peers when we hear from both of them, and so that when we hear about a 
relationship in responses from both peers we can see how closely the two 
responses match, an important check on the quality of the survey.  As soon as 
we've collated the data, we'll strip the ASNs to protect privacy, and only the 
final aggregate statistics will be published. We will never disclose any ASN or 
any information about any ASN. We already have more than 8,000 ASN-pair 
relationships documented, and we hope to receive as many more as possible. We'd 
like to finish collecting data by the end of September, about two weeks from 
now.

If you’re peering with an MLPA route-server, you’re welcome to include just the 
route-server’s ASN, if that’s easiest, rather than trying to include each of 
the peer ASNs on the other side of the route-server. Either way is fine.

If all of your sessions have the same characteristics, you can just tell us 
what those characteristics are once, your own ASN once, and give us a simple 
list of your peer ASNs.

If your number of peers is small enough to be pasted or typed into an email, 
rather than attached as a file, and that’s simpler, just go ahead and do that.

If you have written peering agreements that are covered by non-disclosure 
agree

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Roger]

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.



you gona get hated by java  programmer,
but for me i could say only  FULL ACK! :D




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

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Andreas Fink]

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


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

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Jeroen Massar]

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 ? :)

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

WebRTC is supposed to go partially over SCTP, never seen it actually used.

Apple chose to use Multipath TCP instead...

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.

Greets,
 Jeroen



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

Re: [swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Andreas Fink]

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 :
> 
> 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 :
> 
> * 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: andr...@fink.org https

[swinog] SwiNOG #30 - 4th November 2016 - (Calling for Papers)

[Simon Ryf]

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 :

* 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