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

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 <caw@heapingbits.net> 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
>>> icnrg@irtf.org
>>> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Ck_l3JqxhS1GBV4FC0GZ9yNSHQAmGDDxHwyH_qxYPljEt7_FZEOymbblf1Re5Ilt9oDVo4a6Ux6ZCuQE_ZM$
>>
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg