Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption

[[e-mail]]

> On 12. Apr 2023, at 14:43, Claudio Porfiri <[e-mail]> wrote:
> 
> Hello,
> About the problem with legacy midbox, unfortunately this is due to a bad design habit where nodes that should only look at IP header do deeper analysis and decide to drop packets even if they are not supposed to do any firewalling.
> It's a pity as the adoption of zero checksum may benefit also other SCTP transports other than DTLS where the payload is protected in some reliable way, and there are initiatives in that sense like the crypto chunk draft that would also benefit from zero checksum.
> As a matter of facts, the zero checksum is currently limited to the cases listed in the draft.
> For the time being the zero checksum, as specified in the draft, is welcome.
> 
> Related to the midbox behavior, recently a new version of connection tracker in Linux Kernel for SCTP has been mainstreamed that avoids deep packet inspection, so that it would work with zero checksum when SCTP is using IPV4 and IPv6. I am not aware of a similar change in BSD connection tracker.
Hi Claudio,

I'm not sure what you refer to as the BSD connection tracker. If you are referring to libalias,
I think the checksum is not checked on input, but a correct checksum is computed for all
packets containing ERROR or ABORT chunks sent by libalias. Since libalias does not change
anything in the SCTP packet, there is no need to deal with the CRC32c.

Best regards
Michael
> 
> Best regards,
> Claudio Porfiri
> 
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of [e-mail]
> Sent: Wednesday, 12 April 2023 14:20
> To: Nils Ohlmeier <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-zero-checksum-02 adoption
> 
>> On 11. Apr 2023, at 19:15, Nils Ohlmeier <[e-mail]> wrote:
>> 
>> Hello,
>> 
>> I’m supporting adoption of draft draft-tuexen-tsvwg-sctp-zero-checksum-02, because it is going to be useful for all WebRTC endpoints out there to have the option to skip the checksum step.
>> 
>> I also reviewed the draft. The only concern I found is this sentence:
>> 
>> "Since the lower layer of SCTP can not be IPv4 or IPv6 as specified in [RFC9260] or UDP as specified in [RFC6951], no problems with middle boxes expecting correct CRC32c checksums in the SCTP packets are expected.”
>> 
>> Which confuses me, because it sounds to me like this is trying to say that SCTP over IPv4 or IPv6 can not be done. Which obviously doesn’t make any sense. But I honestly fail to parse what this sentence is suppose to tell me (besides no problems with middle boxes is expected).
> Would using
> 
> One example of such a lower layer is the use of SCTP over DTLS as
> described in [RFC8261] (as used in the WebRTC context). Counter
> examples include:
> 
> * SCTP over IPv4 or IPv6 as specified in [RFC9260].
> 
> * SCTP over UDP as specified in [RFC6951].
> 
> * The use of SCTP Authentication as specified in [RFC4895].
> 
> Therefore using an incorrect zero checksum will not result in
> problems with middle boxes expecting correct CRC32c checksums in SCTP
> packets.
> 
> be clearer?
> 
> Best regards
> Michael
>> 
>> Best
>> Nils Ohlmeier
>