[tsvwg] Two comments about removing the 16 kB limitation in draft-ietf-tsvwg-dtls-over-sctp-bis-02
li.yan18@zte.com.cn Tue, 11 January 2022 02:11 UTC
Return-Path: <li.yan18@zte.com.cn>
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 AA2A63A0C0D for <tsvwg@ietfa.amsl.com>; Mon, 10 Jan 2022 18:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 J_9UIkOJwsY5 for <tsvwg@ietfa.amsl.com>; Mon, 10 Jan 2022 18:11:10 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA343A0C0C for <tsvwg@ietf.org>; Mon, 10 Jan 2022 18:11:09 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4JXvLg5S7pz8PxD2; Tue, 11 Jan 2022 10:11:07 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 20B2Abbo014207; Tue, 11 Jan 2022 10:10:37 +0800 (GMT-8) (envelope-from li.yan18@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid202; Tue, 11 Jan 2022 10:10:37 +0800 (CST)
Date: Tue, 11 Jan 2022 10:10:37 +0800
X-Zmail-TransId: 2afd61dce71d8427c1cc
X-Mailer: Zmail v1.0
Message-ID: <202201111010370879854@zte.com.cn>
Mime-Version: 1.0
From: li.yan18@zte.com.cn
To: claudio.porfiri@ericsson.com, magnus.westerlund@ericsson.com, john.mattsson@ericsson.com, tsvwg@ietf.org
Cc: zhou.xingyue@zte.com.cn, deng.zhiren@zte.com.cn, li.meng5@zte.com.cn, ma.jun3@zte.com.cn, li.yan18@zte.com.cn
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 20B2Abbo014207
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 61DCE73B.001 by FangMail milter!
X-FangMail-Envelope: 1641867067/4JXvLg5S7pz8PxD2/61DCE73B.001/10.30.14.239/[10.30.14.239]/mse-fl2.zte.com.cn/<li.yan18@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 61DCE73B.001/4JXvLg5S7pz8PxD2
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Z1dh7lWo5dnS9HU7hYyizQ3WKqg>
Subject: [tsvwg] Two comments about removing the 16 kB limitation in draft-ietf-tsvwg-dtls-over-sctp-bis-02
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: Tue, 11 Jan 2022 02:11:15 -0000
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 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: li.yan18@zte.com.cn www.zte.com.cn