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

["David R. Oran" <[e-mail]>]

Stephen & IRSG,

Thanks for these insightful comments. It’s definitely not too late to improve the document! After giving this some time for others to weigh in I didn’t get any further thoughts from the other authors, so excuse the delay - please take a look and make any further suggestions for based on the stuff below.

Once we settle on the outstanding questions, I’ll update the draft and resubmit to hopefully finish the IRSG poll.

Thanks again for your time and effort on this!

DaveO.

On 23 Sep 2019, at 20:59, Stephen Farrell wrote:

> Hiya,
>
> On 23/09/2019 23:12, Colin Perkins wrote:
>> IRSG members,
>>
>> This is to initiate a final IRSG poll on
>> draft-irtf-icnrg-terminology-05 with a deadline of 14 October 2019.
>
> Given that I'm coming to the game very late, I am fine
> with a ready to publish vote on this.
>
> However, had I not been so late, I'd have said this was
> not ready as I'm not sure that any of the cryptographic
> mechanism terms are properly handled.
>
Could you elaborate a bit on any stuff beyond the specifics in your comments (which we’ll try to address). We certainly don’t want to either cause confusion or be out of step with current usage.

> In particular I wonder if data packet signatures are
> really checked or not (with existing s/w)
Given this is a terminology draft, there’s no assertion that the definitions are in fact satisfied by any given implementation. Since you are curious, here’s the state of affairs as I understand it:

- The current NDN code base does in fact check signatures. While it is possible for an application to directly access the transmit/receive interfaces for NDN messages and hence do its own signature verification, general applications use one of two APIs (the most comprehensive being the “producer/consumer API - https://named-data.net/publications/techreports/tr17-consumer-producer-api/) which automatically does the verification.
- The current CCNx code base, Metis (https://github.com/parc-ccnx-archive/Metis) also verifies signatures automatically.
- Of course, just checking signatures without some notion of which signatures should be trusted to sign which packets isn’t terribly helpful. There’s a lot of good work here on trust schemas and automatons that use the name structures of objects and keys to decide what to trust. If you’re interested take a look at “Schematizing Trust in Named Data Networking (https://named-data.net/publications/schematizing_trust_ndn/). This is also implemented and used in some current applications (for an interesting use case, check out the just-published paper Lessons Learned Building a Secure, Network Measurement Framework using Basic NDN (https://conferences.sigcomm.org/acm-icn/2019/proceedings/icn19-20.pdf)

> and have to
> consider the descriptions of confidentiality as being
> mythical. I'd say fixing those parts could well be
> considered an inherent part of due diligence.
>
Well, the current NDN and CCNx designs only provide origin authentication of packets and leaves confidentiality and payload encryption to a layer above. Given that this terminology is intended to only address the usage of terms in the specifications of the NDN and CCNx protocols, what would you suggest here? While the document does have wider interest than just the NDN/CCNx communities, its genesis and value is mostly in ensuring the that the two designs use consistent terminology so the different design decisions can be compared when doing evaluations and building applications.

> Detailed comments/suggestions below.
>
> Cheers,
> S.
>
> - abstract: is ICN still "novel"?
>
Perhaps. A prior version of the document said “(ICN) is a new paradigm” and we changed it in -05. Would it be better to just say “paradigm”? I didn’t make any change to the text.

> - intro: Is there really an intention to publish an equivalent for
>   e.g.  NetInf? Be nice if there were, but it seems less likely now
> than perhaps when this effort started.
>
Good point. We’ll change it to “may be the subject…”

> - section 2: I refute the potential existence of an "irrefutable
>   binding":-) Probably better to not use such odd language in a
> terminology draft? (In case someone wants to discuss, consider a
> DNSpionage type attack against a CA issuing certificates for use in
> an ICN - doesn't matter if that'd be a hard or unlikely attack,
> it's enough that irrefutable is wrong.) Suggest s/irrefutable
> binding/strong cryptographic binding/
>
I like your suggestion. We’ll make this change.

> - s2: "Data authenticity and encryption" - hmm. Last time I asked a
>   student implementing ICN, he couldn't find any code that actually
> enforced signature verification. Is that still the case? If so,
> then it seems wrong to perpetuate a myth like this. If not - great!
See above in the answer to your general comment.

> And where can I find sample logs for mismatching interest and data
> packet caught via signature failure?
I don’t know if there’s anything beyond debug logs for the code, but this question doesn’t seem in scope for a terminology document. Is it ok to just let this slide?

> Secondly, the idea that it's
> fine and dandy that confidentiality doesn't exist within ICN seems
> nicely 20th century.
Well, it most certainly does exist, but not in the L3 protocol machinery which is what this document is addressing. Perhaps we should put something in the introduction to correctly position this as not claiming to be terminology for the whole protocol architecture, but only for the Layer 3 protocols of NDN and CCNx. Would that at least somewhat alleviate the concern?

> All in all that paragraph seems misleading.  I
> think the best fix would be to make the description contingent,
> e.g. to say something like "s/w could (but mostly doesn't) drop
> data packets that don't match interests because of signature check
> failure." And maybe say "there is no ICN confidentiality service
> (sadly)" if we want to be clear.
>
I get it, but the current text is not a statement about what an implementation does; it hopefully specifies the terminology used to describe it.

> - s2: "Trust" - meh. I don't trust text with such definitions.
>   Also, a description of the concept of "Trust" that ends with
> "trust model" seems circular. I'd just delete that para - it only
> obfuscates and doesn't help.
>
I found the paragraph just fine, which probably says more about the authors’ naïveté than the actual state of affairs. I’d prefer to leave this or even better fix it, since it would be a possibly glaring omission to have a terminology document that doesn’t say anything about trust.

> - s2: "packet mule" - there is a "data mule" concept from DTN that
>   may be what's meant here. I think using that term and referring
> to something that defines it would be better than inventing the new
> term "packet mule." Later I find you even define the term "data
> mule" in 3.2 so just using that will be better.
>
Actually, I think we are being sloppy, since this isn’t enough like the data mule concept in DTN to introduce here. Mules typically store forwarding state and instructions in the packets themselves, which is’t what NDN and CCNx do. So, thanks for catching this. I propose we change this to simply say “It can also behave as a store and forward node, carrying an interest or Data Packet for some time before forwarding it”.

> - 3.1: "Data packet immutability" - I don't believe it myself:-) If
>   you hand me a packet, I can change and forward it. I think what
> you mean is that change can be detected (in principle).  I don't
> get the last sentence.
>
I can see why this might be horribly confusing to somebody not “inside the ICN tent pissing out”. The idea which seems to not come across in the text is that ICN cares fundamentally about the relationship between names and data and in the case of NDN and CCNx makes the binding between a name and the corresponding data content immutable, with that binding enforced cryptographically. You therefore cannot, “reuse” as name to refer to a different set of bits. If this makes more sense to folks I can craft some modified language in the document. One caveat is that there is a political dimension to the definitions in the terminology draft, as it was the result of some delicate negotiation between the NDN and CCNx camps back some years ago when the two architectures were a lot different than they are today.

> - 3.3: I was puzzled by the ordering of terms here. Why be coy
>   about that? IOW, be good to explain to the reader why terms are
> in this order. (My guess: to avoid forward refs.)
>
Frankly I’m not sure what the particular motivation was. Since I doubt the usage model for this specification is to act as a “dictionary”, alphabetical or some other canonical ordering doesn’t seem to be important. Since you noticed, do you have some suggestion for what would be better? In some cases there is the advantage of no forward references, but in others it doesn’t seem to matter. I’m not proposing any change here.

> - 3.3: If there exists a useful definition of stateful forwarding,
>   then why is there not one for stateless forwarding?
Because stateless forwarding is not used anywhere in CCNx or NDN? It may be that anybody sufficiently clued knows that the “other” architecture is IP, which does stateless forwarding, and “everybody knows” what that is.

> If there is
> not then why is there not just forwarding? In which case, why do we
> need an entry in 3.3?
>
I think the reasoning is to tie the terminology directly to the form of the state that must be kept by a forwarder. Do you think this does in fact need fixing? I’d prefer to leave it as is.

> - 3.3: "data packet" ... the "and is directly secured" phrase - is
>   that true? (See earlier.)
>
Yes, I think so. Should we add “directly secured through cryptographic integrity mechanisms”?

> - 3.5: "name" ... the assertion of being "semantically meaningful"
>   seems unnecessary to me and also impossible to verify. Maybe just
> delete the phrase as it's qualified with a "usually" anyway?
>
I don’t think saying “usually semantically meaningful” is problematic, but we would not lose a lot by deleting it. I’d prefer to keep it given that there’s a lot of active work on name schemas for NDN and CCNx which do in fact delve deeply into structuring names that can be assigned meaning by applications, and in some cases, presented to users in UIs.

> - 3.5: SHA256 probably calls for a reference.
>
Will add. Thanks.

> - 3.5: "nonce" - this has a cryptographic definition that is
>   perhaps not the same (see RFC4949). Saying that explicitly would
> be good.
>
Good point. As an aside CCNx does not use nonces, but NDN still does, although they don’t have as central a role in loop detection and retransmission as they used to now that NDN added a hop limit like CCNx has. Nevertheless we’ll add a note that the usage does not satisfy all the properties of a cryptographic nonce and add the reference to RFC4949.

> - 3.7: "data integrity" also protects against deliberate
>   modification, as well as corruption.
>
Good point. Will add.

> - 3.7: "authenticity" - using HMAC? Really? That seems like a
>   totally broken idea for an ICN. Surely any symmetric scheme
> like that couldn't work with caching without allow forgery?
>
It would be good if you could elaborate here. Anybody with the key can forge, including caches, so the implicit assumption is that the “trusted domain” includes the caches. Do you have a suggestion other than getting rid of mention of symmetric keying? As an aside, we do have a TLS-like keying protocol for use cases that involve two-party exchanges - take a look at https://tools.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.html if you’re interested.

> - 3.7: all the "... confidentiality" paragraphs - this seems like
>   it'd be better omitted given the utter lack of ways in which such
> a service can be provided as part of an ICN.
I’d prefer to leave this in, but appreciate the earlier comments about the protocols the terms apply to not having confidentiality machinery built in. Would it be acceptable to add to each of these a statement that the CCNx and NDN layer 3 protocols do not provide such confidentiality and it expected that higher layers provide such?



DaveO