[tsvwg] Re: Deb Cooley's Discuss on draft-ietf-tsvwg-sctp-zero-checksum-10: (with DISCUSS and COMMENT)

Deb Cooley <debcooley1@gmail.com> Tue, 11 June 2024 18:19 UTC

Return-Path: <debcooley1@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1E5F5C1D4CD8; Tue, 11 Jun 2024 11:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Jm5LdUevdC-T; Tue, 11 Jun 2024 11:18:57 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE72C18DB8A; Tue, 11 Jun 2024 11:18:52 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id e9e14a558f8ab-3748ebe7e53so24419015ab.1; Tue, 11 Jun 2024 11:18:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718129931; x=1718734731; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ikg1IlRq9yZE55uh1xtmIMmAUjD2oEyt0Hz56ZxNcPE=; b=Nm4LxSQXbANsM+SEneC9U9DElg7iOPqFFNZP+TijVrm/4sFyXoabk3sOSZ6/pW6TQT vUyChglkNNK2Te85fPy2gb/pmnjtV6ej3LUIjwxTUN9NnNas77AgqHTtXMmElZ+Pn8Xb tRNRzSJHLqv7Py9UB7RBFhx2oxq4thYZRD7v1mXdBP/DzQZojF4a4OmNTi1IN9lQ2nJn ng0m9hEFtsoVY8MgSVuwl8yletLVxMwEJ7tyMkNDJRtFtSRLANczhNluAVR3M2s2My5w aqR0uhCaYOYvcLiovpz7Xa8EgrNPtqrr17MAokjQ2lmQDz1pB2Xg0OZ5Xju8mGCW88HW lEyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718129931; x=1718734731; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ikg1IlRq9yZE55uh1xtmIMmAUjD2oEyt0Hz56ZxNcPE=; b=V0KtvE4LsaoGRZIY8NvctunxsVr+TD8mV/SOmgk59B8a4Zz1fLOnpSqHVYnXJ0v7MM ej7d1ab596YXTaZ8lvA6Ek4h5Byl8bQKoOxbmHvK/87evH8hkqeLxKeD8aDPJNKi6nSs CHYR7z946SKqQUtKTmk+h8yG3XLiR0x9jgu7wFHpdmZOlQroaQo3LLnt0zDzUASpupv8 8gd8f8dsTqiZVKUBtfSLDBWf0bofc5cH1Wd/BcCpNHHz9OVZmQjtZRyjskBxPyvUtzqa p5M1TvfAocfyMmRf5MUimZSn2+/FaWWoX6QEJ4rrQN3G3QBAvwS+cXvrWEPJ5ua4nigG t7Dw==
X-Forwarded-Encrypted: i=1; AJvYcCXTlOzNrcDgDXsdr9jDy1qPYtm7SZ/EWbKm916O6b9ugiS5YWp+X5yDzmY4/2injphj0PrKxsQ94z+5AcqPxXhMyUESQMWIkcTTUxHGq2jovmLH20Wpw33EfGOaFfnBWdmvWE00TcZ8qlS05vNlAI5ZYciT2mAve89Xrv/7owXoCiY0Pw==
X-Gm-Message-State: AOJu0YzYs5cDhxV68ApF65UAgYjcR+Iyt7KtF7hSwfnaLvUdB6ObNEWe W23EwRNJ4chvZnAK/b1uKHJ3Pmx8+BIA41oR/grErwfJWGnqNrbxvyKauEpxNGwNN8vBYn7UA6q dCOvRAxsjPqaX8zFfhZZ9vW4wtA==
X-Google-Smtp-Source: AGHT+IFY3stscyOacyEJvayaNRelhIqlyxNLFWgSUbwNTqWAxZ+t103CM5SC/30YzdOKuCbvmFBv2af1b87tPAQxZsg=
X-Received: by 2002:a05:6e02:1805:b0:375:c34c:dfa5 with SMTP id e9e14a558f8ab-375c34ce139mr20648095ab.26.1718129930614; Tue, 11 Jun 2024 11:18:50 -0700 (PDT)
MIME-Version: 1.0
References: <171777230482.20251.8346371564760157384@ietfa.amsl.com> <A20D6FE1-2120-48C0-BDF3-6413FE9E50A4@lurchi.franken.de> <CAGgd1Oc_5wot62=i_-5TMXb2DB0JjZcoj1ufjZCy7zYtv8dHjw@mail.gmail.com> <08D9D3F9-DF0E-493A-833D-0ACC1414F230@lurchi.franken.de>
In-Reply-To: <08D9D3F9-DF0E-493A-833D-0ACC1414F230@lurchi.franken.de>
From: Deb Cooley <debcooley1@gmail.com>
Date: Tue, 11 Jun 2024 14:18:37 -0400
Message-ID: <CAGgd1OfdomkJig01ehqPhZXXGtiizXQMK2Op3s4g1Z7CRhM3+g@mail.gmail.com>
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Content-Type: multipart/alternative; boundary="000000000000314313061aa14c4c"
X-MailFrom: debcooley1@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, draft-ietf-tsvwg-sctp-zero-checksum@ietf.org, tsvwg-chairs <tsvwg-chairs@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: Deb Cooley's Discuss on draft-ietf-tsvwg-sctp-zero-checksum-10: (with DISCUSS and COMMENT)
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/a1CbQ8sHq1Fip6Y3aVexYQUskCI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

I'm certainly not arguing that CRC32c is the best integrity mechanism ever,
because it isn't.  This draft has basically allowed its removal because
there is something better protecting the integrity of the data.  There
needs to be something written in the Security Considerations about that.
Even if it is to reference the requirements in Section 3 with a short
rationale.  Or it can reference the part of the IANA section where the
requirements are listed, again with a short rationale.  It doesn't have to
be long, and it can reference the requirements you already specified.

An aside:  As for tunnels vs auth modes, is it even possible to meet the
two requirements with an authentication mode, where the packet is not
obscured from any device between sender and recipient?  I suspect that the
answer is 'no'.


On Fri, Jun 7, 2024 at 5:02 PM Michael Tuexen <
michael.tuexen@lurchi.franken.de> wrote:

> > On 7. Jun 2024, at 20:47, Deb Cooley <debcooley1@gmail.com> wrote:
> >
> > Are the only two options DTLS or SCTP AUTH?  If so, the draft doesn't
> make
> > that clear.
> The only option currently being defined is SCTP over DTLS. One additional
> could be based on SCTP AUTH, but that will require additional details for
> dealing with middleboxes expecting correct CRC32c checksums. This is
> described in the document. Other additional method could be based on the
> DTLS or CRYPTO chunk, currently being proposed by Ericsson. However, these
> would also need some mechanisms to deal with middleboxes.
> Since these mechanisms are not required for SCTP over DTLS (the middleboxes
> don't see the CRC32c at all), and this might be the largest deployment
> scenario (WebRTC), this is left to the document describing such an
> alternate error detection method.
> Best regards
> Michael
> >
> > Deb
> >
> > On Fri, Jun 7, 2024 at 1:28 PM Michael Tuexen <
> > michael.tuexen@lurchi.franken.de> wrote:
> >
> >>> On 7. Jun 2024, at 16:58, Deb Cooley via Datatracker <noreply@ietf.org
> >
> >> wrote:
> >>>
> >>> Deb Cooley has entered the following ballot position for
> >>> draft-ietf-tsvwg-sctp-zero-checksum-10: Discuss
> >> Hi Deb,
> >>
> >> thanks for the review. Please see my responses in-line.
> >>
> >> Best regards
> >> Michael
> >>>
> >>> When responding, please keep the subject line intact and reply to all
> >>> email addresses included in the To and CC lines. (Feel free to cut this
> >>> introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> >>> for more information about how to handle DISCUSS and COMMENT positions.
> >>>
> >>>
> >>> The document, along with other ballot positions, can be found here:
> >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-zero-checksum/
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> DISCUSS:
> >>> ----------------------------------------------------------------------
> >>>
> >>> Currently Section 9 says roughly that there are no changes to the
> >> Security
> >>> Considerations to RFC 9260.  I have two comments:
> >>>
> >>> 1.  Since this draft is proposing to remove an integrity mechanism in
> >> SCTP,
> >>> there should be an update to the paragraph in RFC9260 Security
> >> Considerations,
> >>> specifically 12.2.2.  Protecting against Data Corruption in the Network