search

sctplab / usrsctp

A portable SCTP userland stack
BSD 3-Clause "New" or "Revised" License
673 stars 280 forks source link

RFC 2960 support #91

Closed chemeris closed 8 years ago

chemeris commented 8 years ago

Does usrsctp support RFC 2960? I know it's obsolete, but there is a lot of old equipment in use which supports only RFC 2960, but there are no good open-source implementations of it AFAIK. So you have to retreat to using Cisco or other gear to talk to existing equipment.

tuexen commented 8 years ago

Sure. I'm not aware on interop problems between an RFC 2960 compliant and an RFC 4960 compliant implementation. If you run into problems, please let me know. usrsctp shares a lot of code with the FreeBSD kernel implementation and that implementation is used in the SIGTRAN environment.

chemeris commented 8 years ago

AFAIK the most important part if Adler-32 to CRC-32 migration. We should be able to respond to clients still using Adler-32 with Adler-32 to make it work. A careful reading of rfc4460 is required to figure out all differences I guess.

tuexen commented 8 years ago

You are right. But I haven't seen Adler-32 for a while. usrsctp supports https://www.ietf.org/rfc/rfc3309.txt.

stewrtrs commented 8 years ago

I don’t know of any implementation that uses Adler-32. Even Cisco’s IOS left that behind long ago (I don’t remember any option to turn it back on either).

Speaking as one of the authors of RFC 4460 whats in there (and 4960) is what was supposed to be implemented. There were not specific changes to “make the protocol different” instead it was corrections to the wording so that people could implement it correctly and inter-operate.

R

On Jul 2, 2016, at 7:26 PM, Michael Tüxen notifications@github.com wrote:

You are right. But I haven't seen Adler-32 for a while. usrsctp supports https://www.ietf.org/rfc/rfc3309.txt.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Randall Stewart rrs@netflix.com 803-317-4952

chemeris commented 8 years ago

Indeed, it seems the checksum is not the issue we're seeing.

Let me give some background first. We have a Cisco ITP and clients connecting to it with SCTP/M3UA. Some clients support only RFC 2960 and when ITP is configured in RFC 4960 mode, these clients can't connect. So we have to switch ITP to 2960 mode allow these old clients to connect.

Now, we're looking to replace the ITP with something else and looking for a good stack. We're currently trying to figure out why does this incompatibility happen, so that we have a working solution after we replace the ITP. I'll get back when we have more information.

tuexen commented 8 years ago

Capture the traffic of a working and a non-working association setup in a .pcap file. You can send them to me privately and I can have a look, if you want.

chemeris commented 8 years ago

@tuexen Can I send a file to the tuexen fh-muenster de?

So, compatibility issues I see so far:

1) usrsctp ABORTs when it received ERROR about unrecognized TSN parameter, which breaks connectivity to 2960 nodes. Compare to Linux SCTP version ignores this ERROR and keeps working. I will send you traces for this.

2) We do need to support Adler32 because of clients with equipment purchased in early 2000's. The issue I was looking at above was not related to checksum, but there are other connections where it's used. Stop supporting them is not really an option. I don't see any harm in adding Adler32 as an option with a large warning that it must not be used unless it's a compatibility issue. You can even disable this option at compile time by default.

3) I've been told there is also an issue with chunks processing difference (probably https://tools.ietf.org/html/rfc4460#section-2.1 and similar), but I haven't seen a trace myself yet. It'll take some time to get a trace for this. May be you know what can be wrong there?

tuexen commented 8 years ago

Sure, that is my email address.

Need to look into a tracefile regarding 1).

Regarding the second item, it could be added. Integration is something one has to think about. It could be compile time option, not sure if it is the best option. You really want to figure out if you can't upgrade the nodes to also support CRC32C. Even if you purchased the stuff in the 2000's, there is no software update available?

Regarding the third item, lets look at a tracefile.

chemeris commented 8 years ago

1) Sent you the traces. One is using Ubuntu 14.04 x64 LTS (kernel 3.19.0-64-generic), another one is using usrsctp current master (5d59dde8). I may be wrong, but my reading of RFC is that ERROR is not actually a fatal condition by itself and thus can be handled gracefully which is what Linux kernel seem to be doing. This allows us to connect to 2960 servers.

2) It's not our equipment - it's equipment from peers we're connecting. So we can't dictate them what to use, unfortunately. I believe it should be a runtime option, ideally on a per-socket basis, because one may have a mix of clients connected to the same STP.

tuexen commented 8 years ago

Regarding the traces: Could it be that you run the userland stack usrsctp on a machine which has an SCTP stack in the kernel? This doesn't work. This is how I think it could happen: When a packet is received, a copy of it is delivered to the usrsctp and you see the expected result. In addition, another copy of the packet is delivered to the kernel stack, which doesn't know about the association and therefore sends an ABORT. So the basic question is: Are you running usrsctp on a machine, running Linux for example, which has an SCTP in the kernel, lsmod would tell you for the Linux example? Adding again support of Adler32 which is deprecated since September 2002, is a different beast. It could be done in principal, not sure I actually want it. Adding automatic detection is a possibility, it was done at around that time a lot. @stewrtrs What do you think?

stewrtrs commented 8 years ago

Well

I don’t think I want to add support for Adler32.. It is hard for me to believe any equipment out there does it since it changed very very quickly (for the IETF). It seems to me to be reverse progress and not something I am really willing to support.

R

On Jul 3, 2016, at 1:35 PM, Michael Tüxen notifications@github.com wrote:

Regarding the traces: Could it be that you run the userland stack usrsctp on a machine which has an SCTP stack in the kernel? This doesn't work. This is how I think it could happen: When a packet is received, a copy of it is delivered to the usrsctp and you see the expected result. In addition, another copy of the packet is delivered to the kernel stack, which doesn't know about the association and therefore sends an ABORT. So the basic question is: Are you running usrsctp on a machine, running Linux for example, which has an SCTP in the kernel, lsmod would tell you for the Linux example? Adding again support of Adler32 which is deprecated since September 2002, is a different beast. It could be done in principal, not sure I actually want it. Adding automatic detection is a possibility, it was done at around that time a lot. @stewrtrs What do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Randall Stewart rrs@netflix.com 803-317-4952

chemeris commented 8 years ago

@tuexen That was indeed the case. I tried without 'sctp' kernel module and it works beautifully, thank you!

@tuexen @stewrtrs Unfortunately, there is still equipment out there working on Adler32 even today. Which is an issue for carriers who has a lot of interconnections. I know it doesn't feel right and I wouldn't want to support outdated and known-to-be-bad standard, but that's a requirement coming from practice. I would appreciate if you could add this. It's a minor effort with a significant practical outcome.