netdev - Re: [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation of SCTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Sep 2020 02:04:51 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     Michael Tuexen <tuexen@...muenster.de>
Cc:     network dev <netdev@...r.kernel.org>, linux-sctp@...r.kernel.org,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Neil Horman <nhorman@...driver.com>,
        Tom Herbert <therbert@...gle.com>, davem <davem@...emloft.net>
Subject: Re: [PATCH net-next 00/15] sctp: Implement RFC6951: UDP Encapsulation
 of SCTP

On Wed, Sep 30, 2020 at 12:40 AM Michael Tuexen <tuexen@...muenster.de> wrote:
>
> > On 29. Sep 2020, at 15:48, Xin Long <lucien.xin@...il.com> wrote:
> >
> > Description From the RFC:
> >
> >   The Main Reasons:
> >
> >   o  To allow SCTP traffic to pass through legacy NATs, which do not
> >      provide native SCTP support as specified in [BEHAVE] and
> >      [NATSUPP].
> >
> >   o  To allow SCTP to be implemented on hosts that do not provide
> >      direct access to the IP layer.  In particular, applications can
> >      use their own SCTP implementation if the operating system does not
> >      provide one.
> >
> >   Implementation Notes:
> >
> >   UDP-encapsulated SCTP is normally communicated between SCTP stacks
> >   using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both
> >   ends.  There are circumstances where other ports may be used on
> >   either end, and it might be required to use ports other than the
> >   registered port.
> >
> >   Each SCTP stack uses a single local UDP encapsulation port number as
> >   the destination port for all its incoming SCTP packets, this greatly
> >   simplifies implementation design.
> >
> >   An SCTP implementation supporting UDP encapsulation MUST maintain a
> >   remote UDP encapsulation port number per destination address for each
> >   SCTP association.  Again, because the remote stack may be using ports
> >   other than the well-known port, each port may be different from each
> >   stack.  However, because of remapping of ports by NATs, the remote
> >   ports associated with different remote IP addresses may not be
> >   identical, even if they are associated with the same stack.
> >
> >   Because the well-known port might not be used, implementations need
> >   to allow other port numbers to be specified as a local or remote UDP
> >   encapsulation port number through APIs.
> Hi Xin Long,
>
> I really appreciate that UDP encapsulation gets implemented in Linux.
>
> The FreeBSD implementation initially had a bug due to missing text in
> RFC6951. Please make sure the implementation also follows
> https://www.ietf.org/id/draft-tuexen-tsvwg-sctp-udp-encaps-cons-03.html
Hi, Michael

Thanks for sharing this doc.

3. Handling of Out of the Blue Packets:
This patchset can handle it well.

4. Handling of SCTP Packets Containing an INIT Chunk Matching an
Existing Associations:
These cases responding with ABORT, I will need to add.

>
> The plan is to revise RFC6951 and let RFC6951bis include the contents of
> the above Internet Draft. But this most likely will happen after the
> NAT document is ready and RFC4960bis finished...
understand.

>
> If you want to do some interop testing, a web server supporting SCTP/UDP
> is running at interop.fh-muenster.de. You can find a client (phttpget) at
> https://github.com/NEAT-project/HTTPOverSCTP.
got it.