[Anima] Re: pls comment: "Lightweight GeneRic Autonomic Signaling Protocol"(draft-zhu-anima-lightweight-grasp-00)
Longwei Zhu <lwzhu@bupt.edu.cn> Thu, 11 July 2024 14:16 UTC
Return-Path: <lwzhu@bupt.edu.cn>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD26CC14F6B5 for <anima@ietfa.amsl.com>; Thu, 11 Jul 2024 07:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xa3vwrro_MAQ for <anima@ietfa.amsl.com>; Thu, 11 Jul 2024 07:16:40 -0700 (PDT)
Received: from smtpbgjp3.qq.com (smtpbgjp3.qq.com [54.92.39.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67567C14F682 for <anima@ietf.org>; Thu, 11 Jul 2024 07:16:38 -0700 (PDT)
X-QQ-mid: bizesmtp84t1720707391tssskmc9
X-QQ-Originating-IP: dTxbMEW/bbzASN1JY9IBMWmk/zOjpCF35DZlNpI4cxU=
Received: from zhu ( [114.247.179.32]) by bizesmtp.qq.com (ESMTP) with id ; Thu, 11 Jul 2024 22:16:30 +0800 (CST)
X-QQ-SSF: 0000000000000000000000000000000
X-QQ-GoodBg: 0
X-BIZMAIL-ID: 15508854479933375451
Date: Thu, 11 Jul 2024 22:16:31 +0800
From: Longwei Zhu <lwzhu@bupt.edu.cn>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <tencent_33CBF5A4183363DB76625258@qq.com>, <da9f05da-3174-46ec-8ca3-274fec457698@gmail.com>
X-Priority: 3
X-GUID: 4AEB4FFD-9B82-4D87-B807-3B27C0264EDD
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.259[en]
Mime-Version: 1.0
Message-ID: <BA453D1584242FBF+2024071120033936851714@bupt.edu.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart123786082554_=----"
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:bupt.edu.cn:qybglogicsvrgz:qybglogicsvrgz8a-0
Message-ID-Hash: IXMI6RI5JBZ66APDNENME4OMEHAVV55L
X-Message-ID-Hash: IXMI6RI5JBZ66APDNENME4OMEHAVV55L
X-MailFrom: lwzhu@bupt.edu.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: anima <anima@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: pls comment: "Lightweight GeneRic Autonomic Signaling Protocol"(draft-zhu-anima-lightweight-grasp-00)
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/sfiL4EybCy8QbjQj8LWpkiH3w2A>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>
Hi Brian,
Thanks for your questions and suggestions!
Here are my responses and explanations to the questions:
######Q1:
>> I think this requires some extra specification - the recipient must also cache the nonce in order to detect repeats. I think a repeat needs to be acknowledged, but not processed a second time.
Your consideration is necessary, and a duplicate detection mechanism on the recipient side based on the nonce cache will be supplemented.
######Q2 :
>> I don't see a discussion of message integrity (i.e. the replacement for the TCP checksum). Are you relying on the UDP checksum? Is there a negative acknowledgment if there is a checksum error?
There is no checksum mechanism in LW-GRASP (to avoid additional complexity), thus it relies on UDP checksum. And, the negative acknowledgment is not considered in this draft. When there is a checksum error, the packet will be discarded silently and the message will be retransmitted later. A negative acknowledgment may be effective and will be considered carefully.
######Q3:
>>CBOR does not require you to limit this to 8 bits. So you could define it as larger, e.g. 16 bits, but start assigning from zero ...
The length of the Objective number can be defined to be larger, but we think 8 bits is enough for now. It is open to negotiation.
>> Also, do you expect the objectives to be standardised and registered like normal GRASP objectives, or will they be local?
The only difference between the LW-GRASP objectives and the standard GRASP objective is the identifier, the former uses the number while the latter uses the text string. Thus, the LW-GRASP objectives can be defined as generic or private like the standard GRASP, which are specified in the draft as:
"The first two bits of objective-num indicate the LW-Objective type (00, 01, and 10 stand for generic LW-Objective; 11 stands for privately defined LW-Objective), and represent the number of LW-Objective together with the remaining six bits. Each generic LW-Objective MUST be assigned a unique objective number and be made public to all LW-GRASP nodes when it's registered. When a private LW-Objective is defined, it MUST also be assigned a uniquely distinguishable objective number and be made public within the specific private domain."
>> For example, if you wanted to use "PrefixManager" and "PrefixManager.Params" from RFC8992, would you give them numbers in addition?
Both the generic and privately defined LW-GRASP objectives must be assigned a unique objective number for identification, just like every standard GRASP objective must have a unique objective name. However, given the possible differences between the use case (e.g., Prefix Management) using LW-GRASP and GRASP, the draft only assigns numbers to experimental objectives. The number of other potential LW-GRASP objectives should be assigned when the corresponding use case is defined.
######Q4:
The limited security capabilities of resource-constrained devices are a real issue. More security issues concerning constrained nodes and their possible solution will be considered.
Regards
Longwei Zhu
Sender: Brian E Carpenter
Send Time: 2024-07-11 11:30
Receiver: 朱龙薇
cc: anima
Subject: Re: [Anima] pls comment: “Lightweight GeneRic Autonomic Signaling Protocol”(draft-zhu-anima-lightweight-grasp-00)
Hi Longwei,
I have a few questions:
#1:
>> 3.1. Reliable transmission for confirmable LW-GRASP messages
...
>> If the LW-GRASP confirmable message does not get an acknowledgment within the retransmission timeout, then the message MUST be retransmitted, but there is no need to regenerate the Nonce, just keep it the same as the original message.
What happens if the recipient has accepted the message and processed it, but the acknowledgment is lost? Some GRASP messages (especially M_NEGOTIATE) are not idempotent, so simply repeating a message could be dangerous.
I think this requires some extra specification - the recipient must also cache the nonce in order to detect repeats. I think a repeat needs to be acknowledged, but not processed a second time.
#2:
I don't see a discussion of message integrity (i.e. the replacement for the TCP checksum). Are you relying on the UDP checksum? Is there a negative acknowledgment if there is a checksum error?
#3:
>> 4.2.1. LW-Objective option
...
>> objective-num = 0..255
CBOR does not require you to limit this to 8 bits. So you could define it as larger, e.g. 16 bits, but start assigning from zero; that would make no difference on the wire unless you actually *needed* more than 256 values.
Also, do you expect the objectives to be standardised and registered like normal GRASP objectives, or will they be local? This needs to be explained. For example, if you wanted to use "PrefixManager" and "PrefixManager.Params" from RFC8992, would you give them numbers in addition? ("PrefixManager" = 10, "PrefixManager.Params" = 11)
#4:
>> 7. Security Considerations
The security people insisted that in RFC 8990, we specified use of TLS even over the ACP. This was for defence against internal attackers. (I did implement an alternative, draft-carpenter-anima-quads-grasp, but it still needs a full crypto library.)
Regards
Brian
On 05-Jul-24 01:29, 朱龙薇 wrote:
> Dear ANIMA WG members,
>
> We have proposed the draft “Lightweight GeneRic Autonomic Signaling Protocol”(draft-zhu-anima-lightweight-grasp-00, https://datatracker.ietf.org/doc/draft-zhu-anima-lightweight-grasp/)
>
> The draft aims to design a lightweight version of GRASP, i.e., LW-GRASP, with shortened messages and a message-oriented built-in reliability mechanism with the acknowledgment and retransmission capability based on Nonce. The LW-GRASP can work reliably over UDP, which avoids additional overhead caused by TCP,thus can be more suitable for resource-constrained IoT nodes. Furthermore, the possible IP-independent method for LW-GRASP is also discussed.
>
> We would like to hear opinions from the WG. All kinds of comments are welcome.
>
> Thanks
>
> Longwei Zhu
>
>
> _______________________________________________
> Anima mailing list -- anima@ietf.org
> To unsubscribe send an email to anima-leave@ietf.org