Proposal: exposing SCTP ports for container

[rickhofstede]

While trying to expose an incoming SCTP port for my container, I found out that something like -p x:y/sctp is not yet supported. It would be great to have the flexibility of exposing ports for any protocol for a container, although SCTP currently has the highest priority on my wish list.

[scottstamp]

-- from IRC --
From what I can see, the components that back things should be compatible, but the client is parsing the spec as x:y(/proto) where /proto defaults to tcp, and can only validate to udp or tcp.

I'm not very familiar with this part of the code base and there seems to be a large number of references, so this change might be better looked at by someone more experienced. It seems like just modifying the checks for the -p flag would be sufficient.

[duglin]

ping @crosbymichael @mavenugo is there any reason, aside from trying to fail fast, that we don't just let the protocol string be passed all the way down to the iptables call and let unknown/invalid protocols be detected at that point? Then we don't need to check in docker itself and just let the underlying OS decide.

[thaJeztah]

ping @mavenugo could you answer this?

[mavenugo]

With CNM (Container Networking Model), container connectivity across multiple hosts can be achieved through various drivers/plugins. Some of the drivers such as the in-built overlay, supports these container connectivity without the need to port mapping. Hence SCTP or other protocols can just work without the need to map or expose ports.

But, in order to expose the service provided by a container to external networks that are not managed under CNM, we would have to do port-mapping and hence this request must be addressed. Also, the concept of external connectivity varies under different deployment scenario. This enhancement request should be included in that context when making design decisions.

[LK4D4]

@mavenugo @mrjana @sanimej @aboch still need to be addressed?

[razaborg]

What is the current status of this feature ?
I'm facing the problem to expose a sctp port on the host, and that still seems to be unsupported

[AkihiroSuda]

@razaborg

@ishidawataru opened PR #33922

[AkihiroSuda]

libnetwork-side PR has been opened as moby/libnetwork#1825

Anyone please look into the PR?

[Peter-eid]

@mavenugo What is the current status of this feature ?

[rkbug]

@mavenugo (Madhu), Can you please update the current status of this feature?

[verizonold]

hi can you please provide details on how SCTP is now supported? Any examples that you can share?

[thaJeztah]

I think all PR's are merged now, and will be included in Docker 18.03 (release candidates are available); see

• Support SCTP port mapping libnetwork#1825
• support SCTP swarmkit#2298
• Support parsing SCTP port mapping docker/go-connections#41
• Support SCTP port mapping docker/cli#278
• docs: mention sctp docker/cli#900
• add sctp docs docker/docs#6078

Closing this issue, because it looks like we're done, but feel free to comment in case I missed something

[verizonold]

do you know if Kubernetes supports SCTP?

[verizonold]

@thaJeztah Can you please provide me a pointer to Docker 18.03? Should I see this in Edge releases?

[thaJeztah]

It's not released yet; release candidates are available in the "test" channel, or through the install script at https://test.docker.com

[verizonold]

@thaJeztah thanks...so I just run this script on my CentOS VM? Also, I would like to try the support for SCTP. Can you please provide some doc/info on how to use this feature in docker?

[thaJeztah]

@verizonold from docker's perspective it's mainly allowing you to specify sctp in addition to tcp or udp when publishing container ports. What to use it for / how you use it for things running in your container is a bit out of scope.

[verizonold]

@thaJeztah thanks...so what is the link to the release candidates in the "test" channel?

[AkihiroSuda]

@verizonold you just need to do

# For test builds (ie. release candidates):
#   $ curl -fsSL test.docker.com -o test-docker.sh
#   $ sh test-docker.sh

Kubernetes-part hasn't been worked out yet.

[teknoraver]

Hi all.

Are memory cgroups limits enforced for SCTP kernel buffers?
I hope I'm wrong, but looking at the code it seems not.
Please do proper testing before enabling SCTP by default.

[thaJeztah]

@AkihiroSuda ^^ think you may have more insight into that

[AkihiroSuda]

@teknoraver You're talking about SCTP-equivalent of memory.kmem.tcp.limit_in_bytes, right?
I'm not sure Linux has equivalent of that for SCTP.

[teknoraver]

@AkihiroSuda exactly that one. One to avoid that a process will waste all the system memory?

[AkihiroSuda]

Although not specific to SCTP buffer, does docker run --kernel-memory (which sets memory.kmem.limit_in_bytes) works for you?

[Jacob-E]

Is there a way to run userspace sctp stack in the container?
Currently , if we try that, the kernel sctp ends up sending an ABORT .

[teknoraver]

I don't think so.
Running an userspace layer 4 protocol requires you to have RAW socket permissions, which is unlikely in containers.

[teknoraver]

Hi,

I recently discovered this, which is strictly related to this issue:

https://access.redhat.com/security/cve/cve-2019-3874