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

[Dirk Kutscher <[e-mail]>]

Dear all,

during the IRSG poll for the challenges draft we received this extensive review from Stephen, which I found quite useful, so I'd like to share it and also give people a chance to discuss it.

The result of this discussion would be reflected by the authors in a potential update of the document.

Cheers,
Dirk


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Donnerstag, 24. Dezember 2015 21:07
> To: Dirk Kutscher; Internet Research Steering Group ([e-mail])
> Subject: Re: [irsg] IRSG Poll: draft-irtf-icnrg-challenges-03
> 
> 
> Hi all,
> 
> I have no objection to this being published however I do think there are a couple
> of significant weaknesses that really ought be addressed beforehand if the
> authors/RG are willing to do that.
> 
> To repeat: I'm not objecting to publication. These are comments I probably
> would have made earlier had I had the time, but I didn't, sorry.
> 
> Cheers,
> S.
> 
> PS: I didn't cc the rg list in case folk here want to chat 1st, but this or a later
> version after such a chat probably should be sent to the list. I've no problem if
> someone just replies to this and cc's the list. (I'm subscribed there.)
> 
> PPS: Should dirk be the RG-chair running this poll? Better if a non-author does
> the paperwork in cases like that isn't it?
> 
> 1. stuff that'd really be better addressed...
> ---------------------------------------------
> 
> - 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?)
> 
> - 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?
> 
> - 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.
> 
> - 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.
> 
> 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?
> 
> - 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.
> 
> - 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.
> 
> - 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.)
> 
> - 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.
> 
> - 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).
> 
> - 3.1: I'm also surprised you don't need a concept related to whatever/whoever
> creates/publishes an NDO.
> 
> - 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.
> 
> - 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.
> 
> - 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.)
> 
> - 4.2: Why is it acceptable to say "instead of discussing...
> technical details, we ... <do something else> " in an IRTF document?
> 
> - 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.
> 
> - 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.
> 
> - 4.6: s/smooth RTT value/smoothed RTT value/ maybe? if not, then maybe
> "smooth RTT value" needs a reference
> 
> - 4.8: FCAPS could do with a reference maybe.
> 
> - 4.8: DTN (and other acronyms, but I know that one well:-) should be expanded
> on 1st use.
> 
> - 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.)
> 
> - 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.
> 
>