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

[Spyridon Mastorakis <[e-mail]>]

Hi Colin,

Thank you for checking in. I think I can revise the draft. Once Dave pushes out the updated version of the path steering draft, we will also update the trace route draft.

Thanks,
Spyros

On Aug 25, 2022, at 4:39 PM, Colin Perkins <[e-mail]<mailto:[e-mail]>> wrote:

Non-NU Email

Hi,

Can I check if you have what you need to progress with the updates to this draft, or if you still need input/confirmation from Chris?

Colin



On 9 Aug 2022, at 16:25, Colin Perkins wrote:

Spyros – thank you!

Chris – could you please check if the following would address your concerns?

Thanks,
Colin




On 1 Jul 2022, at 12:22, Spyridon Mastorakis wrote:

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]<mailto:[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]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Ck_l3JqxhS1GBV4FC0GZ9yNSHQAmGDDxHwyH_qxYPljEt7_FZEOymbblf1Re5Ilt9oDVo4a6Ux6ZCuQE_ZM$

_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!GpmPMnfIPnKFCUWW0LqABDRfGdJT6cw0VXLZeheaWxlALjc2DaRzcK4cg6BNoQkzaFNqghFWUkTQa4oXBA$

_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!GpmPMnfIPnKFCUWW0LqABDRfGdJT6cw0VXLZeheaWxlALjc2DaRzcK4cg6BNoQkzaFNqghFWUkTQa4oXBA$