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

[Christopher Wood <[e-mail]>]

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