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

[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 ping 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:19, 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

Overall, I found the document very well structured and written. It's clear a lot of work has gone into it. I mainly have questions on the semantics of the ping protocol, especially around how forwarders handle echo requests and responses. Sorry in advance if I misunderstood anything!

Section 3:

 *  Test whether a specific named object is cached in some on-path CS,
    and, if so, return the administrative name of the corresponding
    forwarder.

What would be an example of an administrative name in this case? And is this name also a valid prefix for content objects? (This is clarified almost immediately after this bullet, but it wasn't first clear when read on its own.) I assume this is the case since one might want to obtain various diagnostic information about the CS in question, so adding a use case for this information might be helpful.

An example of a content object name in a CS could be something like "/funny-video/_seq=1” (i.e., a segment of a video) and the administrative name of a forwarder that has cached this object could be something like "/my-ISP/forwarder1”.


Section 3:

 *  Perform some simple network performance measurements.

What sort of measurements? As outlined earlier in this section, the path an interest and content object might take can vary widely, so it's not immediately clear what sort of measurements would be useful for a client to obtain. Elaborating on that here might be helpful.

Such measurements could include RTT and loss rate.


Section 3:

 In order to provide stable and reliable diagnostics, it is desirable
 that the packet encoding of a ping echo request enable the forwarders
 to distinguish a ping from a normal Interest, while also allowing for
 forwarding behavior to be as similar as possible to that of an
 Interest packet.

I'm not sure this has been justified. It would be possible for the ping encoding to match that of a "normal" interest, right? If the purpose of distinguishing is to allow forwarders to alter forwarding behavior, e.g., by not aggregating PIT entries, then couldn't clients force this by appending random name components to their ping interests (or something)? Note that I don't disagree with the outcome -- I just don't know if "desirable" is the right word here.


It is desirable in the sense that a ping echo request may need to be handled in a different way than regular Interests, not only in terms of not aggregating PIT entries. For example, if a forwarder has cached the content object that is “pinged” by a client, then the forwarder will need to generate an echo reply for this echo request and send it back to the client.

Section 3:

 It is also important, in the case of ping echo requests for the same
 name from different sources to have a mechanism to avoid those
 requests being aggregated in the PIT.  To this end, we need some
 encoding in the ping echo requests to make each request for a common
 name unique, hence avoiding PIT aggregation and further enabling the
 exact match of a response with a particular ping packet.

This seems like it would enable PIT DoS attacks, which is probably something that warrants discussion in the security considerations.


I agree. Happy to add some discussion in the security considerations section.

Section 3:

 Note that ICN ping is a protocol that estimates the perceived RTT
 based on a single request-reply exchange. A measurement application
 is needed to make proper use of this protocol to explore multiple
 paths and compute various statistics, such as the variance, average,
 maximum and minimum RTT values as well as loss rates.

This probably belongs in the introduction as one of the main features of the protocol, especially since this protocol is just a building block for higher-level measurement and diagnostic tools.


Sure. Happy to add that to the introduction as well.

Section 4.1:

 The name consists of the
 prefix that we would like to ping appended with a nonce typed name
 component as its last component.

Presumably this is a randomly generated nonce, so it would be useful to say that. It also doesn't appear to have any encoding requirements (base64 string? hex string? something else?), which seems appropriate given its purpose, but that might also be good to note.

I agree with you. A base64 string should work for this purpose. Happy to add appropriate clarifications.


Section 4.1:

 As described below, the nonce is ignored for CS checking.

This seems somewhat confusing, since the echo responise has a TTL of 0, effectively invalidating the CS. I concluded that the nonce is used for CS checking, but nothing will ever match because the TTL of any response is 0. Is that not correct?


Echo replies have a TTL value of 0. However, if a content object that has already been cached in the CS of a forwarder is “pinged”, then this object could have any TTL value and that’s the case where we could have a CS hit (essentially determining that the “pinged” object is in the CS of a forwarder). In other words:

- We do not want to retrieve cached echo replies (e.g., when we send multiple ping requests in the same way as IP ping works today).
- We would like to be able to determine if a “pinged” content object is cached by a forwarder. The content object may have any TTL value.

Section 6:

 *  The echo request's base name exactly matches the name of a
    content-object residing in the forwarder's CS (unless the ping
    client application has chosen not to receive replies due to CS
    hits as specified in Appendix A).

I thought this could not happen since echo content objects have a TTL of 0. I'm probably misunderstanding something, so clarification here would be helpful to me.

This refers again to the case of “pinging” a specific content object as I mentioned in my response above. In this case, we would like to determine if a specific content object has been cached by a forwarder. If that’s the case, the forwarder would create an echo reply and include its administrative prefix in it. The reply will be sent back to the client. This reply will have a TTL value of 0.

Section 8:

This section has some good material, but I think it's probably worth noting the implications of being able to probe the network. Examples of malicious behavior might be, for example, abusing the privileged forwarding behavior for echo requests to attack a specific forwarder. (Being able to traverse different paths using path labels might exacerbate this problem.)

Another example might be the ICN equivalent of port knocking, where the attacker tries to discover certain forwarder implementations and for the purpose of exploiting those vulnerabilities, somehow. Basically, the ICN ping protocol provides much more verbose information to clients than the IP equivalent, and noting the delta between the two -- and what one can do with that delta -- seems useful for experimenters.

That sounds good. Happy to add some discussion 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!CXdT5m5NVkbH9ski1HW5TSOyglp-LjBn_3V1IEjpv63P7smQM5XqV4XqD_FAs09mSvyy_1DiGAOrIfpHqTw$

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

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