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

[Spyridon Mastorakis <[e-mail]>]

Hi Chris,

Thank you very much for your feedback! Please see my response to each of your comments inline. If you agree with my responses, I can go ahead and update the draft.

Please let me know.

Thank you again!
Spyros

> On Jun 15, 2022, at 9:48 AM, Christopher Wood <[e-mail]> wrote:
> 
> Non-NU Email
> 
> 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

Thanks for pointing out this typo!

> 
> 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?

This value is based on the protocol specification. We have mentioned it at the end of Section 4.2.

> 
> 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.
> 

My understanding is both in CCNx and NDN, changing the name of a request would invalidate the state in PIT, therefore, a response will not reach the client. To this end, it is unclear to me how much damage swapping out the name of a request could cause in our case. Indeed, unless requests are signed and the signature is verified, a forwarder could swap out the names of requests, but the corresponding response will not reach the client. I suppose a malicious forwarder could still see the response before the response is dropped. I am happy to mention that in Section 8.

> Hope this helps.
> 
> Best,
> Chris
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Ck_l3JqxhS1GBV4FC0GZ9yNSHQAmGDDxHwyH_qxYPljEt7_FZEOymbblf1Re5Ilt9oDVo4a6Ux6ZCuQE_ZM$