Re: [tsvwg] [Fwd: I-D Action: draft-westerlund-tsvwg-dtls-over-sctp-bis-00.txt]

[Magnus Westerlund <[e-mail]>]

Thanks,

Getting feedback is excellent. We will address your comments and plan to submit
a new draft before the cut-off date next week.

Cheers

Magnus

On Wed, 2021-02-10 at 11:42 +0000, Gorry Fairhurst wrote:
> 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)
>