Subject: Comment: draft-ietf-tsvwg-sctp-udp-encaps-03.txt

From: Steve Padgett <[email-masked]>
Date: Tue, 27 Mar 2012 10:14:09 +0200

Minor comment on this doc (follow-up from today's WG session) -

The "UDP checksum MUST NOT be zero" and "UDP checksum ...  MUST be
computed" seems strong, given that the "SCTP checksum MUST be
computed".  The UDP checksum is at that point only protecting the UDP
ports (the SCTP checksum is stronger and protects the rest of the
data), and if the ports were wrong the process wouldn't get the packet
delivered to it anyways.

Adding in extra overhead to this protocol implementation (in
userspace, above the kernel) to verify on packet receipt that the udp
checksum was present seems strange.  I'm not even sure if you can do
this in most operating systems at the user layer.

It was mentioned in the session today that 'most NICs already do UDP
checksum offloading so this isn't an issue' - but what if this is
running between two processes on the same machine over the loopback
interface?  Over that interface UDP checksum'ng may not be implemented
by the kernel.  Should SCTP over IPv4 UDP on the loopback interface
then fail because checksumm'ng is not being done (when MUST was
enforced)?

My preference is that this should be that the UDP checksum remains
optional to the host operating system, but with a preference of using
UDP checksums (eg, change the MUST to a SHOULD).

Thanks,
Steve

On Sun, Mar 11, 2012 at 6:00 PM,  <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF.
>
>        Title           : UDP Encapsulation of SCTP Packets
>        Author(s)       : Michael Tuexen
>                          Randall R. Stewart
>        Filename        : draft-ietf-tsvwg-sctp-udp-encaps-03.txt
>        Pages           : 10
>        Date            : 2012-03-11
>
>   This document describes a simple method of encapsulating SCTP Packets
>   into UDP packets and its limitations.  This allows the usage of SCTP
>   in networks with legacy NAT not supporting SCTP.  It can also be used
>   to implement SCTP on hosts without directly accessing the IP-layer,
>   for example implementing it as part of the application without
>   requiring special privileges.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-03.txt
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 27 Mar 2012 08:22:17 +0000

I'd be also in favor of changing the MUST to a SHOULD - even though current HW can not do encapsulated checksums, not requiring two independent checksum/crc calculations would appear to allow faster implementations in HW eventually...

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Steve Padgett
> Sent: Dienstag, 27. März 2012 10:14
> To: [email-masked]
> Subject: Comment: draft-ietf-tsvwg-sctp-udp-encaps-03.txt
> 
> computed".  The UDP checksum is at that point only protecting the UDP ports
> (the SCTP checksum is stronger and protects the rest of the data), and if the
> ports were wrong the process wouldn't get the packet delivered to it
> anyways.
> 
> Adding in extra overhead to this protocol implementation (in userspace,
> above the kernel) to verify on packet receipt that the udp checksum was
> present seems strange.  I'm not even sure if you can do this in most
> operating systems at the user layer.
> 
> checksum offloading so this isn't an issue' - but what if this is running
> between two processes on the same machine over the loopback interface?
> Over that interface UDP checksum'ng may not be implemented by the
> kernel.  Should SCTP over IPv4 UDP on the loopback interface then fail
> because checksumm'ng is not being done (when MUST was enforced)?
> 
> optional to the host operating system, but with a preference of using UDP
> checksums (eg, change the MUST to a SHOULD).
> 
> Thanks,
> Steve
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Transport Area Working Group
> Working Group of the IETF.
> >

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Mar 2012 10:58:03 +0200

> this in most operating systems at the user layer.
I'm not sure I understand your argument.

When implementing this in userspace, I use UDP sockets. So the checksum
is being done by the kernel. On FreeBSD I can control the UDP checksum
using a sysctl, but it is system wide.
> then fail because checksumm'ng is not being done (when MUST was
Hmm. That is an argument. Some kernels cheat here...
> UDP checksums (eg, change the MUST to a SHOULD).
Hmm. What about stating that UDP encapsulation SHOULD be done, and is
up to the host operating system. Would that be OK for you?

Reading the code, I can do this for SCTP/UDP/IPv4 also in the kernel
to make use of the sysctl (on FreeBSD). For UDP/IPv6 there is no
sysctl. So it will be always on (except for possibly loopback).

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Mar 2012 11:13:46 +0200

> sysctl. So it will be always on (except for possibly loopback).
Update: Considering a kernel implementation (which is where we have this right now
in FreeBSD and Mac OS X NKE):
Looking at the FreeBSD and Mac OS X kernel, the SCTP code can't access the variable
controlled by the sysctl net.inet.udp.checksum, which controls if the UDP checksum
is computed or not. So makeing this sysctl'able by using the host configuration,
it requires a change to the current UDP code.

I also would prefer things the same for IPv4 and IPv6. So what do you gain by
using the the same SCTP association UDP checksum for the packets using SCTP/UDP/IPv6
and without UDP checksum for SCTP/UDP/IPv4.

Best regards
Michael

---

From: Steve Padgett <[email-masked]>
Date: Tue, 27 Mar 2012 11:58:29 +0200

>> up to the host operating system. Would that be OK for you?

You mean the UDP checksum SHOULD be done, right?  (not
"encapsulation"?).  Assuming that, then yes, that's fine with me.

> and without UDP checksum for SCTP/UDP/IPv4.

My point is that I just don't see having the application trying to
control (or require) what might be a global kernel-level thing being
very tenable.  I agree it's very likely to be 'on' (in all cases), but
if (for whatever unknown reason) it doesn't happen to be on, that
should be fine here as well -- it doesn't appear to break anything if
it is the udp checksum is not present.

>From an implementation standpoint - wouldn't the same code/association
still work for both IPv4 & IPv6?  Basically, you just leave that
decision (whether UDP does the checksum) up to the UDP layer.

Thanks!
Steve

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 27 Mar 2012 13:15:08 +0200

> "encapsulation"?).  Assuming that, then yes, that's fine with me.
Yepp, I mean UDP checksum computation. Sorry for the typo.
> decision (whether UDP does the checksum) up to the UDP layer.
OK, just that it is hard to get the SCTP stack using the UDP settings when
running the stuff in the kernel.

best regards
Michael

---

From: Randy Stewart <[email-masked]>
Date: Tue, 27 Mar 2012 07:28:57 -0400

On Mar 27, 2012, at 4:58 AM, Michael Tuexen wrote:

> Hmm. That is an argument. Some kernels cheat here…

I think you will find that most kernels, cheat for SCTP/TCP and UDP. If the
data is coming over the loopback then they just skip the c-sum.

R

>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-udp-encaps-03.txt

-----
Randall Stewart
[email-masked]