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

[Colin Perkins <[e-mail]>]

Hi,

Thanks - to what extent do this, and icntraceroute, depend on the path 
steering draft?
Colin


On 26 Aug 2022, at 3:44, 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 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$