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

[Junxiao Shi]

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):
>
> intcanonicalOrder(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/747caa69/attachment.html>