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

[Benjamin Kaduk <[e-mail]>]

My MUA's quoting style doesn't seem to interact very well with your MUA's
quoting style; my apologies if I inadvertently missed something.
(inline)

On Fri, Jan 17, 2020 at 11:19:45AM -0500, David R. Oran wrote:
> 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: 
> https://github.com/icnrg/draft-irtf-icnrg-terminology/issues
> 
> The -08 version is available through the data tracker at 
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-terminology/.
> 
> 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.
> 
> Thanks!!!
> 
> 
> ###Comments from Mirja###
> 
> - Sec 3.3. defines *Interest aggregation* and says "Not the same as 
> Interest suppression.”, however, Interest suppression is not 
> defined…?
> 
> 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 
> sentence.
> 
> - Nit in sec 4.4: s/can be turned into into a database/can be turned 
> into a database/ -> 2x into
> 
> Fixed.
> 
> ###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 
> not).
> 
> 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).

I think that's a good clarification; thanks!

> 
> - 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.
> 
> Fixed.
> 
> ####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?

It's more clear in that it definitely maps to a specific definition in RFC
4949.  That said, the RFC 4949 definition does not directly say
"unguessable" (and in general in IETF documents we do separately note
whether unpredictability is required), so my recommendation would be a
phrasing more like "Note: while the specification defining nonces in NDN
meets the RFC 4949 definition, the term 'nonce' is sometimes also used to
imply unpredictability, which is not the case for NDN".

However, you don't need to give my recommendation much weight, and I expect
you've already put a lot more consideration into this than I have.

-Ben

> 
> ####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!
>