Re: [tsvwg] Two comments about removing the 16 kB limitation in draft-ietf-tsvwg-dtls-over-sctp-bis-02

[Magnus Westerlund <[e-mail]>]

Hi Yan,

Thanks a lot for the feedback. Please see inline for comments and
response.

On Tue, 2022-01-11 at 10:11 +0800, [e-mail] wrote:
> Dear tsvwg members,
> Happy new year!
> 
> 
> About the current version of draft-ietf-tsvwg-dtls-over-sctp-bis-
> 02, ZTE has two comments as below:
> 1. Supplementary Note on Fragment reassembly
> It is better to add more description in section 4.1 in the current
> draft.
> The description about how to reassemble the fragemented user message
> in the DTLS layer is not clear enough, and may cause confusion for
> readers.It is recommended to add further description about it.
> For example：
> On the receiving side, after getting the user_message’ from SCTP,
>  DTLS makes use of the length field in the DTLS record header to
> decrypt the content of the first DTLS record to get m0, then m1......
> The length field in DTLS record header is very import for decryption
> of each DTLS record.According to the length field, the receiving side
> knows the end of decryption of one DTLS record and the start of the
> next DTLS record.
> Detemining which DTLS record is the last one needs to use the overall
> length of the user_message’ from SCTP to minus the lenght of each
> DTLS record.
> After the last DTLS record is decrypted, the user_message is
> reassembled: user_message = m0 | m1 | m2......

I have created a github issue for this: 
https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/issues/82

Yes, I spending a bit more descriptive text on how the receiver can
reverse the process would improve clarity. The length field is as you
write required and that is why we later have this normative statement
to ensure that it is in place: "If DTLS 1.3 is used, the length field
in the  record layer MUST be included." And thanks for proposing text,
that makes it clearer what type of aspects you want included. 


>  
> 2. Consideration of backward compatibility
> The issue of backward compatibility needs to be considered, for
> example,if the server side supports DTLS without user message size
> limitation, while the client has message size limitation, packet loss
> may occur on the client side. Therefore, a mechanism is needed to
> identify whether the peer has the requirement of user message size
> limitation.

So true backwards compatility is not really possible, what we have is
the possibility to do a fallback to RFC 6083 behavior at SCTP
association init. I think all the mechanisms for fallback is in place
but maybe the text needs to be improved to make it clearer for how it
works. So lets walk through how it is intended to function. 

An SCTP/DTLS client following this specification will in its initial
message include a couple of things. It will include SCTP-AUTH necessary
chunks including offering SHA-256 (as required by this spec) preferred
over SHA-1 (as required by RFC 4895 for common interoperability), it
will also include a SCTP adaptation layer indication chunk to negotiate
the adapatation layer that is DTLS/SCTP per this specification. 

If the SCTP server supports this specification it will respond
indicating the DTLS/SCTP adaptation layer is supported and SCTP-AUTH
will use SHA-256. 

If the SCTP server is not supporting this and only RFC 6083, it will
not understand the SCTP Adapation layer indication parameter or even if
it supports the parameter it will not understand the particular value
and not reflect it back to the client. Also, depending on support in
SCTP-AUTH it will pick the hashing algorithm of either of the offered
(SHA-1 or SHA-256). 

When the client receives the response it will know from the lack of
adapation layer but with support for SCTP-AUTH that it is likely
speaking with an RFC 6083 capable server. Based on applicaiton and
security policy the client can determine if that is acceptable or not.
And if not it terminate the SCTP association. 

A client only supporting RFC 6083 will simularly not offer the SCTP
adaptation layer indication for DTLS/SCTP and include SCTP-AUTH,
potentially with only SHA-1. Thus the SCTP server can make a decision
based on server instance and upper layer protocols if there are
services that can run with RFC 6083 and if the security policy allows
it, then the server responds per RFC 6083. 

I hope the above is clear enough that there are potential for fallback
when it is possible. However, if the upper layer application can't be
constrained to below 16k byte messages it doesn't help. And in addition
there are some difference in security properties that also need to be
considered. 

I have created an issue for this: 
https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis/issues/81

Cheers

Magnus Westerlund