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

From: <[email-masked]>
Date: Tue, 11 Jan 2022 10:11:10 +0800 (CST)

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......

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.

More details welcome further discussion.

Yan Li

Kind Regards,

李燕 LiYan

RAN产品经营团队/无线规划部/无线产品经营部

RAN Product Operation Team/Wireless Product Planning Dept./Wireless Product Operation Division

南京市雨花台区软件大道50号 中兴通讯南京二区 1号楼

No.50 Software Avenue，Yuhuatai District, 

Nanjing, P.R.China, 210012

M: +86 13913811347
E: [email-masked]
www.zte.com.cn

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Jan 2022 15:09:15 +0000

Hi Yan,

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

On Tue, 2022-01-11 at 10:11 +0800, [email-masked] wrote:
> 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. 

> 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

---

From: <[email-masked]>
Date: Wed, 12 Jan 2022 11:48:57 +0800 (CST)

Hi Magnus,

Many thanks for response,especially detailed explanation about fallback mechanism. It is very clear for us to understand the compatiblity between this specification and RFC 6083 peers.

I aggree with you it may be better to add explicit description in specification to make it clearer for how the fallback mechanism works.

Kind Regards,

Yan Li

李燕 LiYan

RAN产品经营团队/无线规划部/无线产品经营部

M: +86 13913811347
E: [email-masked]
www.zte.com.cn

原始邮件

发件人：MagnusWesterlund
收件人：[email-masked];李燕00060790;
抄送人：周星月00082238;李猛10047822;马俊10024791;邓志仁10269642;
日 期 ：2022年01月11日 23:09
主 题 ：Re:Two comments about removing the 16 kB limitation in draft-ietf-tsvwg-dtls-over-sctp-bis-02

Hi Yan,

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

Dear tsvwg members,

Happy new year!

For example：

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.

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