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

Colin Perkins <csp@csperkins.org> Fri, 26 August 2022 09:10 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5297DC1524D0 for <icnrg@ietfa.amsl.com>; Fri, 26 Aug 2022 02:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv5Al56vrN_B for <icnrg@ietfa.amsl.com>; Fri, 26 Aug 2022 02:10:15 -0700 (PDT)
Received: from mx2.mythic-beasts.com (mx2.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AADEC1522B9 for <icnrg@irtf.org>; Fri, 26 Aug 2022 02:10:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=39SnM3OIldnRcS1q/w6Jgc5fAoX+KzldJ436Dczghts=; b=IyCQE4VgW7+GB/YqBWVdzqPIdV 1b28ihxf/CVcTu4aGIxCNFuGMWjWlK4/j9psR/zjC7RYITyA59MeL+NF5A29uoW8VtfJitsDVnM1S vfLA3MWa+86b62aQXgZLTo9AdBJQVEjDHgarUx2aV9obASB4elWqP0+FGj4jAZMFpnubEHu5qxMu3 P+qmNe0VRYEgptrHJ9pnJP4T/YNMBg/8cWLx8CizpJRqwqRITGFOMdRSmOswxrP0Lp3Z9WLevAzPz 91YEBljWiSplUGcEJejy5guxYOsSwvLZvUa9WBvOHZMNcN6sWakEr4LbMyRLmTqR9WAfGZwcBbT9M VfwhV0vw==;
Received: from [81.187.2.149] (port=37005 helo=[192.168.0.72]) by mailhub-hex-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <csp@csperkins.org>) id 1oRVLt-005UeZ-JI; Fri, 26 Aug 2022 10:10:09 +0100
From: Colin Perkins <csp@csperkins.org>
To: Spyridon Mastorakis <smastorakis@unomaha.edu>
Cc: Christopher Wood <caw@heapingbits.net>, icnrg@irtf.org
Date: Fri, 26 Aug 2022 10:10:01 +0100
X-Mailer: MailMate (1.14r5913)
Message-ID: <DB6315D1-4C1D-4929-9FA9-D4A97E3E471E@csperkins.org>
In-Reply-To: <7D75BAF5-0D65-4BA8-A2F1-1FE4C3C28737@unomaha.edu>
References: <1812AB7B-6C51-4D4F-AF19-8DC3FC1ABA9D@heapingbits.net> <E0C479EC-7818-4453-966B-4B14A30E53D8@unomaha.edu> <48253DA5-9DCE-4542-948F-671E1C70985E@csperkins.org> <6F147DBA-A4F5-464C-9BF9-21971B8ED4D8@csperkins.org> <7D75BAF5-0D65-4BA8-A2F1-1FE4C3C28737@unomaha.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_55C4E4E0-B4A2-4FFB-86D7-91BEA05323AC_="
Embedded-HTML: [{"plain":[153, 9128], "uuid":"1295BC2A-A922-4BF2-BEA9-201F867528AE"}]
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/SHB9ru6-Kd6aQmBwbPijjZB765A>
Subject: Re: [icnrg] Review of draft-irtf-icnrg-icnping
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2022 09:10:20 -0000

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 
> <csp@csperkins.org<mailto:csp@csperkins.org>> 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 
> <caw@heapingbits.net<mailto:caw@heapingbits.net>> 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
> icnrg@irtf.org<mailto:icnrg@irtf.org>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!CXdT5m5NVkbH9ski1HW5TSOyglp-LjBn_3V1IEjpv63P7smQM5XqV4XqD_FAs09mSvyy_1DiGAOrIfpHqTw$
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org<mailto:icnrg@irtf.org>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!C1DxOlSHA6-T8akDLXgVttVQHKN1P4e1Fb7DzaFILUTkdIXiImSxY6l6FM1xzqNu-pz9PVp0pQdf7z8WEw$
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org<mailto:icnrg@irtf.org>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!C1DxOlSHA6-T8akDLXgVttVQHKN1P4e1Fb7DzaFILUTkdIXiImSxY6l6FM1xzqNu-pz9PVp0pQdf7z8WEw$