[Ndn-interest] issue in the NDN packet encoding spec 0.3.0

[Nick Briggs]

Hi Junxiao—

I’ll have a look at the changes soon. There may need to be changes in client libraries to enforce this and potentially changes in debug/validation code to detect errors

Sent from my iPhone
(Where it’s hard to do code/document reviews)

> On Jun 7, 2019, at 9:13 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Nick
> 
> Thanks for reporting this issue. I have entered this bug as https://redmine.named-data.net/issues/4946 , and the fix has been merged.
> 
> Yours, Junxiao
> 
> 
>> On Mon, May 20, 2019, 13:47 Nick Briggs via Ndn-interest <ndn-interest at lists.cs.ucla.edu> wrote:
>> I was reading through the NDN packet spec, at https://named-data.net/doc/NDN-packet-spec/current/tlv.html, currently documenting version 0.3, and noticed an issue as follows:
>> 
>> When the variable length encoding for Type and Length was specified there was no requirement to use the minimum length encoding for any given value.  That is, a length of 0x20 MAY be encoded as 0x20, or 0xFD0020, or 0xFE00000020, or even 0xFF0000000000000020.
>> 
>> This has consequences in the canonical ordering and matching code as specified in https://named-data.net/doc/NDN-packet-spec/current/name.html -- the suggestion that one can use "memcmp" on the wire encoding of the Name field's TLV-VALUE is incorrect.  As currently specified, even a simple equality match for Names must decode each individual T and L value from the top level Name TLV through the component T and L values.
>> 
>>> If components component1 and component2 have different types, then
>>> component1 is less than component2 if numerical value of TLV-TYPE(component1) is less than numerical value of TLV-TYPE(component2)
>> 
>> For example, the numerical value of TLV-TYPE encoded as 0x42 is equal to that of a TLV-TYPE encoded 0xFD0042)
>> 
>>> If components have the same type, then
>>> If a is shorter than b (i.e., has fewer bytes), then a comes before b.
>>> If a and b have the same length, then they are compared in lexicographic order based on absolute value of octet values (e.g., ordering based on memcmp() operation.)
>> again, if TLV-LENGTH(a) was encoded 0x20 and TLV-LENGTH(b) was encoded 0xFD0010 a simple memcmp as specified in
>> 
>>> The canonical order can be enforced by directly comparing the wire encoding of the Name field’s TLV-VALUE (i.e., excluding TLV-TYPE and TLV-LEGNTH of the whole Name TLV):
>>> int
>>> canonicalOrder(Name lhs, Name rhs) {
>>>    int result = memcmp(lhs.value(), rhs.value(), min(lhs.value_size(), rhs.value_size()));
>>>    if (result == 0) {
>>>      result = lhs.value_size() - rhs.value_size();
>>>    }
>>>    return result;
>>> }
>> will produced an incorrect result.
>> 
>> You probably need to say that a VAR-NUMBER MUST use the minimum length encoding necessary to represent the value and that failure to do so will result in unspecified behavior.
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190607/454e079d/attachment.html>