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

[Colin Perkins <[e-mail]>]

Thanks.
Colin


On 26 Aug 2022, at 3:43, Spyridon Mastorakis wrote:

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