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

[Nick Briggs]

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/20190520/a3eeea86/attachment-0001.html>