Re: [icnrg] [irsg] Final IRSG poll on draft-irtf-icnrg-terminology-06

[Spencer Dawkins at IETF <[e-mail]>]

Hi, David,

Top-posting, just to say that the proposed change to the Security
Considerations section provides the pointers I was hoping for, AND provides
the reminder that the relevant security considerations aren't the result of
terminology, but of the specifications that use that terminology.

So what you suggested was better than what I was thinking of. Thanks for
that.

Spencer

On Thu, Oct 24, 2019 at 7:49 AM David R. Oran <[e-mail]> wrote:

> Hi, and thanks to Vincent, Brian, Marie-Jose, and Spencer, who took the
> time to read and comment on this work during IRSG Last Poll,
>
> I’m sorry for the delay in responding, but I wanted to get all the
> comments assembled and check with the co-authors before replying (none of
> the co-authors had anything to add). Below find my proposed responses to
> the comments and the plan for an update to the document. In a couple of
> cases I have a question as the reply to the comment, so please take a look
> and give further guidance if you think it appropriate.
>
> I’ll hold off editing resubmitting the document for a few days in case you
> have further thoughts or other IRSG members want to weigh in for the poll.
>
> I’ve snipped out headers and such and grouped the comments by the person
> who made them. This makes a couple of the responses a bit redundant.
> Vincent Roca wrote:
>
> * section 2: the FIB, PIT and CS definitions are key to ICN but are not
> visible (hidden inside the « forwarding plane » definition).
> They deserve more visibility.
>
> We expect the usage model for this document to be more “lookup/search”
> rather than “Read end-to-end”, so there isn’t a lot of general exposition
> or attention to the order of the definitions part from the category
> groupings. By this logic the three data structures are all
> forwarding-related (as opposed to end-to-end semantics) so that’s where we
> put them. Unless you feel strongly about this, I’d prefer to leave this as
> is.
>
> * section 3.4, « Manifest » definition.
> Is this facility used when a content is split into several Data packets?
> An example of its possible use would be welcome I think.
>
> Yes, and potentially also for “directory-like” functions for multiple
> content object under the same prefix. The current Manifest specification
> (FLIC - an expired draft we are refreshing any day now) is mostly oriented
> toward the former usage. While we want to err on the side of being general
> and not biasing with particular concrete examples, it may be appropriate to
> add something here. Would the following rewrite be better?
>
> Old:
> “A type of Data packet that contains Full Name Links to one or more Data
> Packets. Manifests group collections of related Data packets under a single
> Name. This has the additional benefit of amortizing the signature
> verification cost for each Data packet referenced by the inner Links.
> Manifests typically contain additional metadata, e.g., the size (in bytes)
> of each linked Data packet and the cryptographic hash digest of all Data
> contained in the linked Data packets.”
>
> New:
> “A type of Data packet that contains Full Name Links to one or more Data
> Packets. Manifests group collections of related Data packets under a single
> Name. Manifests allow both large Data objects to be conveniently split into
> individual Content Objects under one name, and to represent sets of related
> Content Objects as a form of “directory”. Manifests have the additional
> benefit of amortizing the signature verification cost for each Data packet
> referenced by the inner Links. Manifests typically contain additional
> metadata, e.g., the size (in bytes) of each linked Data packet and the
> cryptographic hash digest of all Data contained in the linked Data packets.”
>
> * section 3.5:
> A figure is missing to explain the relationships between the « Name »
> (defined as a « Data packet identifier ») and the « Packet ID »
> (that is also a « unique crypto identifier for a Data packet ») which
> includes the « Name » in the hashed information, and the
> relationships between the « Exact Name » and « Full Name ».
> There are concurrent Data packets identifiers, with additional properties
> for the Packet ID, all of this being a bit confusing.
>
> Perhaps this is all a bit confusing without the context of understanding
> many pieces of the NDN or CCNx architecture. No disagreement on that.
> However, there are two downsides of trying to fix this with a figure: (a)
> it would likely need a whole bunch of additional explanation, winding up
> recapitulating things that are already documented in detail in
> specifications like RFC8569, (b) the relationships are not neatly captured
> graphically without slipping into specifying an algorithm by which you
> ascertain how, for example, to derive an Exact Name from the Full Name, or
> how Packet-ids are used in particular forwarding/matching algorithms.
>
> Again, our usage model for this document is that you’d start with some
> other specification, and get pointed here for formal definition terms used,
> as opposed to having this be the first thing you pick up when wanting to
> learn about CCNx or NDN.
>
> If you feel that we really need to “show our work” here, we’ll be happy to
> take a crack.
>
> * section 6 « security considerations »
> Instead of saying there’s nothing new, I’d rather point to the security
> considerations of already existing documents. This is more
> constructive since this type of architecture raises many security
> questions.
>
> Agree that the architecture does have lots new, and Stephen Farrell
> brought up a bunch of good points about the specifics of the crypto-related
> definitions (which we addressed in the current version). We can of course
> add references beyond the ones already in the document (especially RFC8569
> and RFC8609) if you think that helps and cross-reference them in the
> Security Considerations section.
>
> Given that the terse language in the existing text raise a red flag for
> you, perhaps we could write the following for the security considerations:
>
> “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”.
>
> What do you think? Adequate?
>
> Typo and minor comments:
>
> * intro: « in this draft… » => « in this document » seems preferable
>
> yes, will fix
>
> * section 3.1: « without that hange being detected » => change
>
> yes, will fix
>
> * section 3.2: I don’t understand sentence « Note do not have all the
> properties of data mules… »
> Missing word?
>
> Yes, should be “Note that such ICN data mules do not have all the
> properties of data mules as employed in the Delay Tolerant Networking (DTN)
> [RFC4838] specifications.”
>
> * section 3.3, « interest match in FIB » item: this is the first time the
> notion of prefix is mentioned, please add a link to
> section 3.5 where it is defined.
>
> ok, will do. Good idea.
>
> * Section 3.6, « fragmentation » definition.
> « A process of splitting PDUs into frames « => Frames as it refers to the
> « Frame » definition.
>
> assuming you mean just fix the capitalization of “Frames”, yes, will fix.
> Brian Trammell wrote:
>
> A terminology document, as a potential landing place of someone trying to
> get their head around a new area, should at least have security
> considerations by redirection. In particular, the definition of "trust"
> refers to the context of a trust model but makes no reference to trust
> models typically used within ICN deployments; I looked to the security
> considerations section for this and was disappointed.
>
> In the interest of being general, we don’t point to particular trust
> models or schemes to support them. However, there is a lot of good work
> here and that seems to be the common direction for both CCNx and NDN, so
> it’s probably appropriate to add a sentence on this and a reference to the
> Trust Schema paper for NDN. Would that alleviate your concern?
>
> The use of Packet, Segment, and Frame is a little weird for people with a
> traditional TCP/IP background. Differences in applicability between
> segmentation and fragmentation an an ICN are not really clear to me after
> reading this document. Additional discussion would be useful.
>
> Could you elaborate a bit on this? Packet is an L3 object understood by
> forwarders. Segment is a piece of a content object that had been fragmented
> to place in a Packet. Frame is the L2 thing you stuff packets in. Is this
> different from your understanding of either what the terminology doc says,
> or what the usage in for TCP/IP?
> Spencer Dawkins wrote
>
> referencing Brian’s comment above on security considerations:
> I think Brian has this exactly right - if the answer is "This document
> introduces no new security considerations", the next question from a reader
> who's new to the topic is likely to be "no new security considerations
> beyond what baseline, exactly?". In a perfect world, the baseline could be
> limited to references, with little or no expansion in this document.
>
> Would the approach suggested above alleviate your concern too?
> Marie-Jose Montpetit wrote:
>
> I have another nit in section 3.1
> Data packet immutability
> Everywhere else the titles are with uppercase so "Data Packet
> Immutability" Section 3.3 also has mixed title cases. Just decide on 1 way?
>
> Will fix - go with upper case consistently (unless RRC editor prefers
> something different)
>
> [End]
>