Re: [tsvwg] [Fwd: I-D Action: draft-westerlund-tsvwg-dtls-over-sctp-bis-00.txt]
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 10 February 2021 11:42 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47633A0D6B for <tsvwg@ietfa.amsl.com>; Wed, 10 Feb 2021 03:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_Sm8EsdXPgQ for <tsvwg@ietfa.amsl.com>; Wed, 10 Feb 2021 03:42:27 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA23A003F for <tsvwg@ietf.org>; Wed, 10 Feb 2021 03:42:26 -0800 (PST)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2518D1B00055; Wed, 10 Feb 2021 11:42:20 +0000 (GMT)
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <161070670982.3503.691422081028831338@ietfa.amsl.com> <1aebe31b1b3881ac566e38f619a543915e0878b9.camel@ericsson.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <2e2b03c7-4c34-0501-99fc-c9a3d424a73d@erg.abdn.ac.uk>
Date: Wed, 10 Feb 2021 11:42:19 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <1aebe31b1b3881ac566e38f619a543915e0878b9.camel@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/S-gkYLeHpeHNFdsyttsj3JekcGs>
Subject: Re: [tsvwg] [Fwd: I-D Action: draft-westerlund-tsvwg-dtls-over-sctp-bis-00.txt]
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 11:42:30 -0000
I have a few comments below... On 15/01/2021 10:52, Magnus Westerlund wrote: > TSVWG, > > We have just submitted a draft that is intended to specify a replacement to RFC > 6083 (DTLS over SCTP). The main reason for updating this RFC is that it contains > a limiation that the SCTP user messages protected by DTLS was limited to 16383 > bytes. It was realized in 3GPP that they have several signalling messages that > could become larger than that. Thus, from us author's perspective addressing > this issue at the root, i.e. in the IETF RFC that specifies DTLS protection of > SCTP user messages is the best plase to solve this. > > 3GPP will discuss the general issue more in two weeks time at their meeting. > However, this work should be completed during this 3GPP release which means at > the earliest end of the year, but likely sometime in the first half of next > year. > > When addressing the main issue of message sizes that are supported we are also > addressing some additional issues including cipher requirements for the HMAC of > the SCTP messages. > > So I hope there are some interest in supporting this work. > > Cheers > > Magnus Westerlund I read the new ID, and I think I understand the motivation, I do have a few comments (as an individual WG member): Thanks for this contribution relating to the maintenance of the DTLS over SCTP spec! There are a few typos in rev 00, which seem relatively easy to fix, and may help anyone reading this with a view to whether it is complete and could bve adopted, so I'm listing some here: - Typo? /For receiver supporting partial delivery/For a receiver supporting partial delivery/ - English unclear in this part? /This as the receiver can move parts of the DTLS protected user message from the SCTP receiver buffer into a buffer for DTLS processing. . And when each complete DTLS record have been received from SCTP it can in its turn be processed and the plain text fragment can in its turn be partially delivered to the user application. / - Typo? … any or the limitation? /To ensure that the sender have some understanding of limitation on the receiver size - /To ensure that the sender have some understanding of the maximum receiver size/ Although this sentence could also be easier to erad if it were to start with /A TLS extension… … question: is this topic linked to the change in section 5.2? - I found this sentence a little unclear: /In cases where one or more user messages are affected by packet loss of it's DATA chunks more data may requiring buffer in the receiver./ - - I found this sentence unclear. Maybe this could be better as something like: - /If one has partial delivery in both SCTP API and the ULP API and parital processing in the DTLS/SCTP implementation the buffering space in the DTLS/SCTP layer should be no more than two DTLS records. /If an implementation supports partial delivery in both the SCTP API and the ULP API, and also parital processing in the DTLS/SCTP implementation, then the buffering space in the DTLS/SCTP layer ought to be no more than two DTLS records./ - In Section 3.5, the text probably would benefit from being slightly clearer that the /DTLS Path MTU discovery function MUST NOT be used/, since this appears an important detail. - Would an additional ref to sect 4.4 of DTLS help make this clearer? - I was unsure about: /Connection ID SHOULD NOT be negotiated./ - is this better as: /The DTLS Connection ID SHOULD NOT be negotiated. - If so, this could cross perhaps ref section 9 of DTLS? /SHOULD register and use a separate payload protocol identifier (PPID) / - Please add where/how this is registered? - Sect 4.7 Where is renegotiation described … could there also be perhaps a cross ref? - In Sect 4.8: / As renegotiation is not used in DTLS 1.2, all user data is sent in epoch 1./ - I’m not sure I understand. Is the “all data” statement related to DTLS 1.2, or 1.3 or something completely different? - Typo: add ’s’ /to define a setting that represent the policy/to define a setting that represents the policy/ - Typos?:/A SCTP client that receives an INIT-ACK which doesn't contain the DTLS-supported message but do include /A SCTP client that receives an INIT-ACK that doesn't contain the DTLS-supported message but does include/ I hope this might help prepare a -01 version of the ID. Best wishes, Gorry (as individual)
- [tsvwg] [Fwd: I-D Action: draft-westerlund-tsvwg-… Magnus Westerlund
- Re: [tsvwg] [Fwd: I-D Action: draft-westerlund-ts… Gorry Fairhurst
- Re: [tsvwg] [Fwd: I-D Action: draft-westerlund-ts… Magnus Westerlund