[icnrg] Updates to the ICNRG Terminology Document: draft-irtf-icnrg-terminology

"David R. Oran" <daveoran@orandom.net> Fri, 17 January 2020 16:20 UTC

Return-Path: <daveoran@orandom.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 A0C13120024; Fri, 17 Jan 2020 08:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kbe8wpjwCSJh; Fri, 17 Jan 2020 08:20:02 -0800 (PST)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693AB120018; Fri, 17 Jan 2020 08:19:59 -0800 (PST)
Received: from [] ([IPv6:2601:184:407f:80ce:9574:8edf:6314:7529]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 00HGJoKg019295 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jan 2020 08:19:52 -0800
From: "David R. Oran" <daveoran@orandom.net>
To: "Colin Perkins" <csp@csperkins.org>, "Mirja Kuehlewind" <ietf@kuehlewind.net>, "Benjamin Kaduk" <kaduk@mit.edu>
Cc: ICNRG <icnrg@irtf.org>, draft-irtf-icnrg-terminology@ietf.org
Date: Fri, 17 Jan 2020 11:19:45 -0500
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <5DA61530-586A-4BE3-9ECA-6F02AE9899CE@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_164F7870-7018-4914-AA7E-10A91357C0BF_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/hR3JFU8uUHdbem7pIXnbs5EnV9s>
Subject: [icnrg] Updates to the ICNRG Terminology Document: draft-irtf-icnrg-terminology
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
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, 17 Jan 2020 16:20:10 -0000

Many thanks to Benjamin and Mirja for their comments on the -07 draft 
that went through IESG conflict Review. I have produced a -08 version 
that hopefully addresses the comments adequately. Below please find my 
responses with notation of the consequent changes.

These are also captured in the Issue Tracker section of the document’s 
Github repository: 

The -08 version is available through the data tracker at 

Note: I did not copy either the whole IESG nor the IRSG on this message 
to reduce noise. If any of you think they should see it, please redirect 
or forward.


###Comments from Mirja###

- Sec 3.3. defines *Interest aggregation* and says "Not the same as 
Interest suppression.”, however, Interest suppression is not 

Ah: good catch. This is a bit of a historical hangover from when the 
architecture talked about suppression and aggregation as different in 
some ways. It turns out that aggregation is the more general and more 
accurate way to describe the designs. So, I’m getting rid of that 

- Nit in sec 4.4: s/can be turned into into a database/can be turned 
into a database/ -> 2x into


###Comments from Benjamin###

####Section 2####

- Trust: “Data authenticity is distinct from data trustworthiness, 
though the two concepts are related.  A packet is authentic if it has a 
valid name-to-content binding.  A packet is trustworthy, i.e., it  comes 
from a reputable or trusted origin, if this binding is valid in the 
context of a trust model.  Section 6 discusses this further.” I think 
I see what is intended here, but distinguishing between "valid" and 
"valid in the context of a trust model" is a pretty subtle 
differentiation. Some more discussion about a given named entity being 
expected to produce certain content might help (but then again, might 

I was inclined to leave this as is, but perhaps adding something like 
what you suggest is actually helpful. So, I added the sentence before 
the reference section 6: “The trust model provides assurance that the 
name used for a given piece of content is appropriate for the value of 
the content”. We can remove or further change this during RFC editor 
processing if you think this doesn’t help (or further obfuscates).

- Forwarding Plane: The canonical way of implementing packet forwarding 
in an ICN network relies on three data structures that capture a node's 
state: a Forwarding Interest Table (FIB), a Pending Interest  Table 
(PIT), and a Content Store (CS).  It also utilizes Interest forwarding 
strategies which takes input from both FIB and measurements to make 
Interest forwarding decisions.  When a node”
nit: "take input" to match "strategies" plural.


####Section 3.1####

Data packet Immutability: “After a data packet is created, the 
cryptographic hash binding the name to the content ensures that if 
either the content or the name changes, that change will be detected and 
the packet discarded.
nit: previous discussion referred to the name-to-content binding as a 
"signature", not as a "hash".

Right, changed to “signature”

####Section 3.5####

Nonce:”A field of an Interest packet that transiently names an 
Interest instance (instance of Interest for a given name).  Note: the 
use "nonce" as defined here for NDN does not imply semantics that 
satisfy all the properties of a cryptographic nonce as defined in, e.g.  
[RFC4949].” RFC 4949 does not have a definition for "cryptographic 
nonce", so I assume just the regular definition for "nonce" is the 
intended reference. The only required attribute there is "random or 
non-repeating", with liveness
guarantee and replay protection being only the "usual usage" (i.e., not 
required). While I assume I don't fully understand the nuance of ICNRG 
nonce usage, my understanding is that they are intended to be 
non-repeating, at least within some time window, and serve to tie 
specific expressions of interest to data responses. That is not exactly 
the "replay protection" of RFC 4949, though it is closely related, and I 
would argue that even the "non-repeating within a time window" property 
suffices to keep the ICN usage within the RFC 4949 definition. Which is 
a long way of saying that I don't think this much disclaimer is needed.

The concern was that NDN is very loose in their nonce requirements. For 
example with guessable nonces an attacker could cause some PIT state to 
be created by one incoming interest which might inappropriately cause 
aggregation of interests from a victim that should have been forwarded. 
The point about RFC4949 not defining cryptographic nonces is well taken 
however. I toned down the disclaimed to “Note: the specification 
defining nonces in NDN do not necessarily satisfy all the properties of 
nonces as discussed in RFC4949”.

Is that better?

####Section 6####

- “While the terms defined in this specification do not in and of
themselves present new security considerations, the architectures
which utilize the terms most certainly do. Readers should look at
those specifications (e.g. [RFC8569], [NDN]) where various security
considerations are addressed in detail.” This is a great formulation; 
thank you!

We appreciate the vote of confidence!