Re: [icnrg] [EXT] I-D Action: draft-irtf-icnrg-icntraceroute-06.txt

[Junxiao Shi <[e-mail]>]

Dear folks

I had a look at this document for the parts related to NDN.

In Section 5.1, the MustBeFresh element is referred to as a "selector".
Since 2018-Feb, the concept of "selector" is eliminated in NDN packet
format.
MustBeFresh is usually referred to as "the MustBeFresh element".

In Section 5.2 Figure 9, "Path label TLV" is indented too much so that it's
very easy to miss.

In Section 5.2, "the value of the ContentType TLV is 0".
Since ContentType defaults to zero, you may as well omit this element
altogether.

In Section 5.2 Figure 11, TrReplyCode TLV-VALUE is defined as 2*OCTET.
This value is actually a non negative integer, not a bit field or byte
field.
NDN's convention for encoding such numbers is to use NonNegativeInteger,
instead of a fixed-length field.
https://named-data.net/doc/NDN-packet-spec/current/tlv.html#non-negative-integer-encoding

In Section 7 first approach, "a forwarder at the border of the region,
where an Interest name becomes routable has to remove the LINK Object from
the incoming Interests".
This statement is outdated.
Since 2017-Jun, the Interest carries a ForwardingHint, not the LINK Object
(that is itself a Data packet).
Since 2021-Dec, the ForwardingHint is simply a sequence of (supposedly
routable) names; Lixia's opinion is that it should contain a single name,
although the spec still permits multiple names.

In Section 7 second approach, "To ensure that the generated replies will
reach the client, the border forwarder has also to rewrite the name of a
reply and prepend the routable prefix of the corresponding request".
In NDN packet format, the Data name is part of its security envelope.
When the border forwarder rewrites the name of a traceroute reply (that is
a Data packet), the signature becomes invalid.
You need to specify how to handle this situation.
Possible solutions are:

   - The border forwarder must first verify the original signature, then
   re-sign the packet. Implication: the client cannot verify the signature of
   the traceroute reply originator, but must trust the border router.
   - The traceroute reply originator must sign the packet as if it carries
   the routable prefix. Implication: the traceroute reply originator must know
   the routable prefix.
   - The client must strip the routable prefix before verifying the
   signature. Implication: the client must know the routable prefix.


In Appendix A, "Moreover, the client application might not wish to receive
replies due to CS hits. In NDN, the exclude filter selector can be used".
Since 2018-Feb, the concept of "selector" is eliminated in NDN packet
format, so that there's no exclude filter anymore.

Yours, Junxiao

On Tue, May 3, 2022 at 10:26 AM <[e-mail]> wrote:

>
>         Title           : ICN Traceroute Protocol Specification
>         Authors         : Spyridon Mastorakis
>                           Jim Gibson
>                           Ilya Moiseenko
>                           Ralph Droms
>                           Dave Oran
>         Filename        : draft-irtf-icnrg-icntraceroute-06.txt
>         Pages           : 20
>         Date            : 2022-05-03
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icntraceroute/
>
>