Re: [icnrg] Review of draft-irtf-icnrg-icntraceroute

[Dirk Kutscher <[e-mail]>]

Thanks a lot for these two reviews, Chris!

Let's wait for Spyros and Dave following up on these comments.

Best regards,
Dirk





On 15 Jun 2022, at 16:48, Christopher Wood wrote:

> Like the ping document, I found this to be very well structured and written. The use case for the protocol is clear, the protocol itself -- including the forwarder behavior -- is simple, and the security and privacy considerations are thorough.
>
> Section 1.
>
>    To this end, the problem of
>    ascertaining the characteristics (i.e., transit forwarders and
>    delays) of at least one of the available routes to a name prefix is a
>    fundamendal requirement for instumentation and network management.
>
> nit: s/instumentation/instrumentation
>
> Section 6.
>
>    The TrReply Code TLV value of the reply is set to indicate the
>    specific condition that was met.  If none of those conditions was
>    met, the TrReply Code is set to 4 to indicate that the hop limit
>    value reached 0.
>
> Perhaps I overlooked it, but why does the TrReply Code need to be 4? Is it because there are three prior conditions for the final reply in the session?
>
> Section 8.
>
>    This approach does not protect against on-path attacks, where a
>    compromised forwarder that receives a traceroute reply replaces the
>    forwarder's name and the signature in the message with its own name
>    and signature to make the client believe that the reply was generated
>    by the compromised forwarder.  To foil such attack scenarios, a
>    forwarder can sign the reply message itself.  In such cases, the
>    forwarder does not have to sign its own name in reply message, since
>    the message signature protects the message as a whole and will be
>    invalidated in the case of an on-path attack.
>
> Could a compromised forwarder swap out the name of a traceroute request with the name of its choosing? If so, perhaps this should also be listed in the paragraph above? To be honest, I forget the semantics for how content object response signatures are verified, so this might not be an issue.
>
> Hope this helps.
>
> Best,
> Chris
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg