[Nfd-dev] [EXT]Re: Try NDNCERT (based on Interest-Data exchange) and get an NDN certificate today

[Zhiyi Zhang]

Hi Junxiao,

I've added RestartSec in the systemd file and removed the status field from
NEW packets.
I also restarted the service on Suns.

Best,
Zhiyi

On Wed, Feb 17, 2021 at 1:58 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:

> Sorry. This has been on my to-do list for two weeks but new urgent
> todos keep showing up.
> I will escalate it and do it today.
>
> Best,
> Zhiyi
>
> On Wed, Feb 17, 2021 at 1:28 AM Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>> Hi Zhiyi
>>
>> It's been 12 days since I reported the implementation error. Have you
>> updated the implementation and deployment?
>>
>> Yours, Junxiao
>>
>>
>> On Fri, Feb 5, 2021, 14:52 Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>>> Hi Zhiyi
>>>
>>> Anyway, I've tested the service.
>>>>> CA profile retrieval is working now.
>>>>>
>>>>> However, the NewResponse packet is encoded incorrectly - it contains
>>>>> an unrecognized TLV element of critical type 0x9B.
>>>>> Packet capture is attached.
>>>>>
>>>>> I can see that the offending line is here:
>>>>>
>>>>> https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L91
>>>>> The protocol doesn't have a Status field in this packet:
>>>>>
>>>>> https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3/0d11d48d9ebee022eee71dee14f1342e0905a620#232-packet-format
>>>>>
>>>>
>>>> I remembered we have this status field in the original doc. I guess it
>>>> was removed in later edits.
>>>> Anyway, do you think we should have this field in the NEW Data packet
>>>> to indicate the current status?
>>>>
>>>
>>> What are the possible values for the Status field in NewResponse? If
>>> there's only one possible value, it's unnecessary to include this field.
>>> Note that error conditions would cause the CA to generate an ErrorMsg
>>> packet instead of NewResponse.
>>>
>>>
>>>>
>>>>>
>>>>> Your decoding function is not implementing TLV evolvability correctly.
>>>>>
>>>>> https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L102
>>>>> If it encounters an unrecognized or out-of-order field of a critical
>>>>> TLV-TYPE. However, the current decoding function would erroneously accept
>>>>> any unrecognized or out-of-order fields of critical TLV-TYPEs.
>>>>> All new NDN software is expected to properly implement TLV
>>>>> evolvability. Please see ndn::Interest type in ndn-cxx for an example.
>>>>>
>>>>
>>>> Okay. BTW, should there be some helper functions from NDN libraries to
>>>> help with this?
>>>> I feel it's not very developer-friendly considering the alternatives
>>>> like JSON.
>>>> Compared with forwarder development, maybe we should relax this
>>>> requirement for application development?
>>>>
>>>
>>> Yes, this functionality should ideally come from the library.
>>> Two of my three libraries have *evolution-aware decoder* functionality.
>>> See code samples here:
>>>
>>> https://github.com/yoursunny/NDNts/tree/a42b94a793e479aaeac163bec8d30e328875ea58/packages/tlv#evdecoder
>>>
>>> https://github.com/yoursunny/NDNph/blob/10e1b0ea77af890a0d7b8453060529924b7dadc8/src/ndnph/packet/interest.hpp#L412-L436
>>> You can either ask the library maintainer of other libraries to add this
>>> feature, or switch to one of my libraries.
>>>
>>> Nevertheless, it is your responsibility as application maintainer to
>>> ensure the evolvability guidelines are in the application, especially for
>>> NDNCERT that is a critical part of the NDN testbed infrastructure.
>>>
>>> Yours, Junxiao
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210217/27b945ba/attachment-0001.html>