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 -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
