Re: [icnrg] [irsg] IRSG Poll: draft-irtf-icnrg-challenges-03

[Dirk Kutscher <[e-mail]>]

Hi Stephen and all,

we have finally managed to look into this -- sorry, took us a bit longer...

Overall, the comments are really helpful, and we are considering them for a new revision (working on it right now). Perhaps we can discuss some of the planned changes here...

Some replies inline below

I am not sure how easy it is to parse everything though. We will eventually submit a new version, but that's still work in progress...

Cheers,
Dirk


> > - The string "authoriz" does not occur in the draft. The word
> > "authorised" does occur once in 4.2.3, not as a challenge though, but
> > rather as a putative way to overcome an ICN challenge, by, as far as I
> > can tell falling back to host based networking.  As far as I know,
> > there is no way to do authorization in an ICN without that fall-back
> > to host based networking and I think omitting that from this document is a
> major defect.  Or, to put this in terms of issuing a challenge:
> > how can I deploy a purely ICN payroll system?
> > If a technology cannot be used to develop and deploy a payroll system,
> > is that not a challenge worth mentioning?  I think it is.
> > (4.2.5 even says "without access control" implying that access control
> > is impossible in an ICN?)


Yes, that's a challenges that ought to be described -- perhaps like this:

Access control and authorization is a challenge in ICN, because of the lack of user-to-server authentication in the fundamental named-data-based communication model.

There has been work to implement access control with cryptographic methods in ICN. For example:
a.      http://conferences.sigcomm.org/acm-icn/2015/proceedings/p147-ghali.pdf
b.      https://www.ietf.org/mail-archive/web/icnrg/current/pdf9_JIQ5GBeS.pdf
c.      http://asu.pure.elsevier.com/en/publications/attribute-based-access-control-for-icn-naming-scheme

Access control in ICN often has to do with content encryption and key distribution. This is the subject of active research. 

> > - Whether or not multiple applications can be run using the same ICN
> > caches is an interesting question with both business and technical
> > aspects. Why is that not covered?

It's partly application-dependent and a business requirements discussion.
Still, we should cover this as a challenge and mention the issues we are aware of: content protection, cache poisoning, performance isolation etc. 

As a comment: I don't think we should project today's requirements or concerns on cache sharing to ICN (today, you would only share the same cache resources across applications, e.g., in ISP-operated transparent proxy caches, but not the same bits in the cache).

We should understand them, of course, but there will be a bit of speculation...

> > - 3.2: "ICN can support ... encryption" - I claim that this is not
> > true in any useful sense. Can you really justify it? If not, please don't make the
> claim.

We should clarify key distribution/management and usability challenges. There is current work that could be mentioned, e.g., 
https://www.ietf.org/proceedings/interim/2015/10/03/icnrg/slides/slides-interim-2015-icnrg-4-8.pdf



> > - 4.2.1: Where is "data object authentication" defined?  I had a quick
> > look but didn't find a good definition, though I did find a
> > (very) few uses of the term. Is this perhaps some ill-defined mixture
> > between data origin authentication and data integrity? If so, then I
> > think that may be part of the reason why pepole appear to gloss over
> > the requirement that a PKI is needed to do any better than name-data
> > integrity. (See below for more detail on
> > that.) Anyway, please define this if you keep the term, or, maybe
> > better (only because it'd probably be quicker), see if you can use
> > terms already defined in RFC4949.

Yes, we have to be stricter with the terminology. We have added new text to section 4.1 and 4.2.1. It's a bit too much to post all of that here, but we are now distinguishing data integrity and data origin authentication clearly.


> > 2. nits, near-nits and generally not critical stuff...
> > ------------------------------------------------------
> >
> > - abstract: this does mention some benefits of ICN but no specific
> > challenges at all, is that a fair reflection of the content?

Actually, the abstract lists research challenges explicitly already. We added one sentence to emphasize that:" Mechanisms for realizing these benefits is subject of on-going research in the IRTF and elsewhere."


> > - intro: why does ICN need to be a "core" network-layer primitive?
> > I think it need not be, and can be useful an an optional network-layer
> > primitive, used for (I think) mostly applications where that makes sense.

OK, we are now saying "introducing named data as a network primitive".

> > - intro: the challenging scenarios point requires that path symmetry
> > not be required. I believe CCN and derivatives still do require that,
> > whereas netinf and others do not. Maybe psirp has a need for symmetry
> > along some parts of the path. I think there is a challenge there to
> > figure out the consequences of requiring
> > (partial) path symmetry and whether or not ICN protocols should or
> > should not be designed assuming path symmetry. (It is possible that
> > someone has done that already though, I've not kept as up to date on
> > ICN as I'd like.) 4.3.1 does ack this issue to an extent but without
> > linking to the challenged n/w scenario where it can be a bigger deal.

ACK, added another challenged to 4.2.1:

Bread-crumbs routing implies a symmetric path for ICN
request and response delivery. Some network
configurations and link types prohibit symmetric path
forwarding, so it would be challenge to interconnect
such networks to bread-crumbs routing-based
infrastructure.


> > - intro: "ICN is expected to..." that kind of statement is sales-talk
> > and out of place in a document like this I think.
> > Perhaps s/expected to/promoted by some as a technolog that will/ would be
> ok.
> > (If the "by some" is felt to be too weasel-wordy in my suggestion, you
> > could fix that via a reference to some paper(s) that do make that
> > claim.)


OK, new text:
"In summary, ICN can evolve the
Internet architecture towards a named-data-based network model
with different properties and different services."

> > - section 2, 4th bullet: I don't think it is correct to say that "n/w
> > unaware of media type => unable to manage access" which is how I read
> > this. (See the Marnew w/s which was largely about that
> > topic.) If you mean something else, then perhaps rephrasing this would be
> good.

OK, I removed the bullet item and wrote this instead:
"the forwarding layer cannot cooperate with transport layer
functions,so sometimes useful functionality such as local
retransmission, local rate control have to implemented
with TCP proxies or other intermediaries."

> > - 3.1: You don't distinguish between NDO and some smaller unit here
> > (e.g. a "chunk" or similar) that may be meaningful to a convergence
> > layer or transport used between ICN caches/routers.  I guess the
> > reason is that you think there's no need for that distinction here,
> > but if that's the case, maybe saying so would be good, to avoid
> > readers getting the wrong impression? (Note: I'm not sure if such a
> > change is needed or would be good, but I did think there was a missing
> > definition on first reading.) 3.2 does mention "segments of NDOs" though, and
> "chunk" does occur later so maybe this might be worth another look (not sure).


Clarified this in the definition of NDO now.

> > - 3.1: I'm also surprised you don't need a concept related to
> > whatever/whoever creates/publishes an NDO.

Added a definition for "Publisher":
<t hangText="Publisher:">
Entity in an ICN network that publishes an NDO to the
network, so that corresponding requests can reach the
publisher. The publisher need to be identical to the
actual creator, for example a publisher could provide
the service of hosting NDOs on behalf of the actual
creators/owners.</t>


> > - 4.1: "self-certifying" is STILL a crap term and always will be.
> > It is entirely misleading as to what one gets from name-data
> > integrity. I think you should remove all mention of that unless you
> > leave in a statement that it is a challenge for ICN to ovecome the
> > misleading impression that has accrued from use of that bogus term.

Yeah, good point. We reworked the associated text.

> > - 4.1: Some forms of ICN name-data integrity (e.g. the CCN one) do, I
> > maintain, require a PKI, it is just a different PKI from the WebPKI,
> > in about the same way that DNSSEC is a different PKI from the WebPKI.

actually, CCNx is now using hashes for validating name-data integrity. PK is used for origin authentication.

> > - 4.1: What is an "aquainted hashed key"? The description here just
> > does not raise to the level where the "user" (huh, a user checks a
> > digital signature?) can "immediately verify that the data actually`are
> > from the publisher." Such sloppy language does not help describe
> > challenges, but rather hides a challenge which is how to deploy the PKI that is
> needed by signature based ICN naming schemes.
> > (You do to an extent recognise this challenge later, but that just
> > makes ignoring it here odder.)

Yes, we rephrased the paragraph and added more text:

<t>
	  There are several design trade-offs for ICN naming, which
	  affect routing and security.  Hash-based names are not human
	  readable nor hierarchical. They can however provide some
	  structure for aggregation, for instance, a name part
	  corresponding to a publisher. In hash-based names with
	  indirect binding, the key of the publisher is bound to the
	  name of NDO, and so when a user receives, e.g., the triplet
	  namely [data, key, signature], the receiving entity can
	  verify that the NDO has been generated by the possessor of
	  the private/public key pair and that the NDO has not been
	  changed in transit (data integrity). This can be done by
	  cryptographically hashing the received key and the name of
	  NDO, and comparing it with received hashed key. Then, the
	  key can be used to verify the signature.
	</t>
	<t>
	  Data origin authentication can be achieved by validating
	  public-key-cryptography-based signatures about an NDO's name
	  and content. In order to ascertain data integrity and origin
	  authenticity with such an approach, a PKI-like system is
	  required that would allow linking the corresponding public
	  key to a trust chain.
	</t>


> > - 4.2: Why is it acceptable to say "instead of discussing...
> > technical details, we ... <do something else> " in an IRTF document?

That's not acceptable. We now say:

<t>
	  Security is an active research field in ICN. This section
	  provides an overview of important security
	  features and corresponding challenges that are related to
	  shifting to information-centric communications. Some
	  challenges are well-understood, and there are (sometimes
	  multiple different) approaches to address them, whereas
	  other challenges are active research and engineering topics.
	</t>

> > - 4.2.1: RFC5280 does not require a hierarchical PKI, saying that it
> > does is a clear error that needs fixing. I've already commented on the
> > term "self-certifying, so both "approaches" presented here as the 2
> > options are problematic, and there are of course more options as well.

OK -- new text:

<t>One research challenge is then to support a mechanism to
          distribute the publisher's public keys to the consumers of
          data objects. There are two main approaches to achieve this;
          one is based on an external third party authority such as
          hierarchical Public Key Infrastructure (PKI) (see <xref
          target="RFC5280"></xref> for a description of hierarchical
          PKI) and the other is to adapt a hash-based scheme with
          indirect binding. The former, as the name implies, depends
          on an external third party authority to distribute the
          public key of the publisher for the consumers. In a
          hash-based scheme with indirect binding, the public key (or
          a hash of it) would be used as part of the name -- which is
          sufficient to validate the data integrity.</t>


> > - 4.3: (just wondering) with the DNS we have only recently recognised
> > the benefits of and documented QNAME minimisation.  Are there any
> > similar issues with routing in ICN and how that impacts on privacy?
> > (I'm not sure how one might render that as a challenge.

Name resolution could exhibit that problem. Not sure we should go into details here.

> > - 4.6: s/smooth RTT value/smoothed RTT value/ maybe? if not, then
> > maybe "smooth RTT value" needs a reference

smoothed

> > - 4.8: FCAPS could do with a reference maybe.

Done

> > - 4.8: DTN (and other acronyms, but I know that one well:-) should be
> > expanded on 1st use.

done

> > - 4.8: It seems a bit odd for this to be the section where you mention
> > DTN, would the ICN/DTN relationship be better considered elsewhere? (I
> > think a sentence or two and a ref or two would be enough to cover that
> > here.)

Added a sentence to the RBNR section

> > - 4.8: "can also leverage upon" is an odd phrase - I don't know what
> > it means myself tbh.
> >
> > - 4.9.3: So-called IoT generally has an issue that the occurrence of
> > traffic can expose the content of that traffic.  E.g. packets go to
> > light switch when person enters room => seeing (ciphertext or
> > plaintext) packets means a person has entered the room. Does ICN have
> > the same kind of issue?  I'm not sure myself but would be interested
> > in knowing, not sure if it warrants a mention here.

There would probably be similar issues. We would leave a detailed discussion to new work on privacy start ICNRG is just starting.