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)