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

Christopher Wood <caw@heapingbits.net> Wed, 15 June 2022 14:48 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1B91BC159481 for <icnrg@ietfa.amsl.com>; Wed, 15 Jun 2022 07:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=heapingbits.net header.b=CjOWSG+Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g1ppt4Yp
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4g71UqcU5053 for <icnrg@ietfa.amsl.com>; Wed, 15 Jun 2022 07:48:17 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B590C157902 for <icnrg@irtf.org>; Wed, 15 Jun 2022 07:48:17 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id A84E732007E8 for <icnrg@irtf.org>; Wed, 15 Jun 2022 10:48:16 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute1.internal (MEProxy); Wed, 15 Jun 2022 10:48:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1655304496; x=1655390896; bh=jhq12u5/9+ ijG9Nx3OaJtLLw8ca/ekrJANj2PkII43g=; b=CjOWSG+QRXastobGvmBG/WRNti guQsAWCMBNsf4fy7rN5YKAXZ1BaetAjpQKzuUbdNPUHRPAUzErwSQ59GeEiM1lZ4 lK49f2N5yPyBmtvaBqBX2n+tgZxqaQhA2OUqiEs/A9IEIZNyYTRzACnGw0XBh7Za fxS1mMzoDqpTdcm77XXQzE4FN+kgtH2vBERa0IADgqC6yJ9kwYuC4RVdqcjiuniD PfL6QOd4eFbMqAamnZ5VGFK5f80vf7l6frrc9svxXOJBpQj+5j7+LLx5HfkacOcZ aVJkt9KimOURCr9Ymeh4le6K+v7IsKo613VVkxpVDUZWf8cuzP8sV4gv3cjg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655304496; x=1655390896; bh=jhq12u5/9+ijG9Nx3OaJtLLw8ca/ ekrJANj2PkII43g=; b=g1ppt4YpAuNjSxndAnxZbQGhy6xPQXvRr/McOxOo9SKj wZOjn8oZIAC5ccYVyUA4ueR4XBKHartfRue83qiKk+BAm9Ibl0M8NTtsjSgZY9aY KmBXaIhkhV19KatkAuq633hTvR31BCvOtymRo3m8YzQep31DCWhBFgXouflGrbUz CClvwobRM4PBwgEMC3UduDLYfIxoqwkLjLc+Hj9SDx07vqg+5pSyzQpWEztNV+6S Ks1ScBPimMOsCbIUTFSmlvO81O6BjxbPq1GbdbJrzZlBghg3cDv/aRN7Edjy0VbA bLUulKmsedg5ZypnPGxIalIGyIuWY7vCx34PC4Gp4w==
X-ME-Sender: <xms:L_GpYts5h6S8cUmEcA8EsYYtiX76hw69N6vxQgbN7lWp-64mOoRCyQ> <xme:L_GpYmeAaBMlMZxzNS2ulAuygZgiWbQtlNpagkJUimZyNCd4JU5r4l-afNEf5CP2O G0YAKXxaGxRc_w4x4A>
X-ME-Received: <xmr:L_GpYgyOL8-af2FDyUbu-i2Bs3tREGKYMtT_Oe6s9foAa2er4sEmEo-racf2MvKVyOg9p41kvF07TI-59-wQGT_rCM8BV1LMPQA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvuddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtddvnecuhfhrohhmpeevhhhrihhsthhophhhvghrucghohhougcuoegtrgifsehhvggr phhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeejiefhleegudeiudfgve ekkeeuleekfeelvdehvedvheelkeeghffhkeduffeuhfenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrd hnvght
X-ME-Proxy: <xmx:MPGpYkOv0ZDtt8PYs324vQuUeDap3cLuH3JM8ZR6qbp9898UaAfw4Q> <xmx:MPGpYt-VxfSEy9IwWpWPwOks1r9OZDFbmcjTM0gkXfJH3tji0ItTfw> <xmx:MPGpYkXGQclGbr5cSbPaTIfMjFk_gQhZGme7U0EI9xrGEvecF1ihvw> <xmx:MPGpYiK531-iqhQvdqJ8d9m03BZAleOcpevjU9Z7FS2ZBwlWtMKCcA>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <icnrg@irtf.org>; Wed, 15 Jun 2022 10:48:15 -0400 (EDT)
From: Christopher Wood <caw@heapingbits.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Message-Id: <1812AB7B-6C51-4D4F-AF19-8DC3FC1ABA9D@heapingbits.net>
Date: Wed, 15 Jun 2022 10:48:14 -0400
To: icnrg@irtf.org
X-Mailer: Apple Mail (2.3696.
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/LVrI75KhIKNhZrjhDXd6ow8cuig>
Subject: [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: Wed, 15 Jun 2022 14:48:22 -0000

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

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.

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.

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.

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.

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. 

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?

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.

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.

Hope this helps.