Re: [icnrg] Comments on CCNinfo

[Hitoshi Asaeda <[e-mail]>]

Hi Dave,

Thank you very much for your careful review.

Comments inline.

> On Apr 12, 2019, at 1:34, David R. Oran <[e-mail]> wrote:
> 
> Here are my comments on the current CCNinfo draft (-01). They are all with <Chair Hat off>.
> 
> However, with <Chair Hat on>, I’d like the ICNRG participants to give this draft serious attention cycles soon, as it appears fairly mature, has been implemented, and constitutes our first comprehensive tool for managing CCNx-based networks. It would be good if we could move this forward quickly.
> 
> General Comments
> 
> Positioning
> After a fairly close reading my view is that there is minimal overlap in functionality and likely usage between CCinfo and our other proposed tools, ICN Ping and ICN Traceroute. It therefore makes sense to advance all three of these and sort out later how they are best used either separately or together.

Thanks.

> Overall Design
> The design is reasonable, and while one might quibble with some of the choices (e.g. use of hop-by-hop header fields rather than separate CCNx data objects for the report contents), it hangs together well, at least as far as I can see. It integrates with the forwarding architecture of CCNx rather than being implemented as a separate application on top, which brings some delicate tradeoffs in how forwarders work. The changes do seem manageable though, and should not adversely affect a fast forwarding path since the Request and Reply messages are demultiplexed though being carried in custom CCNx packet types, meaning they can be punted to a slow path at low overhead as needed.

Thanks for your summary.

> Security Approach
> The overall approach to security, while probably workable, is glaringly non-ICN like in design. It uses policy and access control machinery rather than data-oriented security. I’d really like to revisit this and seriously consider a different design that secures the report blocks using encryption,

We do not mandate or recommend the use of the traditional IP address/port-based access control, while it can be used for the lightweight solution. As you think, the node/router validity can be done by a data-centric authentication mechanism with asymmetric cryptography. In the data-centric authentication, nodes/routers identify the target node/router by referring her certificate and signature enclosed in the request/reply message, and decide whether they allow/disallow the request/reply by referring their approved node/router lists.

The detail specification of data-centric authentication is out of scope of this draft. In fact, we have proposed one of the sophisticated approaches for consumer/path/publisher authentication (and hence cached cob authentication as well) in CCN. It is published as the IEEE Trans. article titled "Data-Centric Authentication (DCAuth)". The current CCNinfo I-D (-01) refers this article. And as the potential protocol specification based on DCAuth, my colleague, Ruidong, presented as "HopAuth" in the last ICNRG meeting.
We think it is valuable to propose the HopAuth I-D as the potential "data-centric" authentication mechanism. HopAuth is the general authentication mechanism in CCN, but can be also used with CCNinfo.

>  and avoids signed Request messages (which have all the problematic aspects of signed Interests).


I have a question. Why singed requests should be avoided? What is the problem of signed interests? Is your concern the cost of verification procedure and the performance? Are there any other problems?

> An alternative design would:
> * Sign and encrypt individual report blocks using keys owned by the individual forwarders
> * Prepend each report block with the CCNx Name of the forwarder that generated it, or even better name each report block explicitly.
> * Use the same methods to fetch the signing and encryption keys as is used for regular content
> * Employ schematized trust to represent the policy.

Thank you for your idea.
Maybe I'm not sure the detail procedures you have been thinking, and not sure how it is sufficiently secure and robust.
We may want to submit a HopAuth I-D before the next IRTF and then discuss for the data-centric authentication.

> Terminology
> There’s some inconsistent use of terminology that ought to get cleaned up. 
> * Sometimes the draft talks about “routers” and sometimes about “forwarders” In almost all cases I suspect “forwarder” is the right term to use.

We defined "routers" and "content forwarders" in the Terminology section; "router" is a router facilitating CCN-based content retrieval in the path between consumer and publisher, while "content forwarder" (or simply "forwarder") is a router that is either a caching router or a first-hop router that forwards content objects to consumers.
If I should change some of these explanations, could you give some hints; how the statement should be changed?

BTW, I admit there are some misuse of these words in some other sections; we'll carefully check these words in the draft and correct in the revision. Thanks.

> * both ccnxsemantics and ccnxmessages take care to clearly separate the packet from the message. These are muddled together here and while there are double lines in the figures delineating the boundary, the draft needs to be a lot clearer about which TLVs apply at the packet level (and hence in hop-by-hop headers) and those in the Request/Reply messages and hence in the message part of the whole packet. Describing the operation in those terms would also make for a more understandable specification.

Ok, let me think how the explanation can be much clearer in the revision.
In fact, the structure is not so complex; as Figs.7 and 12 show with double lines, only Request block TLV (inserted by user) and Report block TLV(s) (inserted by router(s)) are located in the hop-by-hop header. Other TLVs, i.e., Reply block TLV and Reply sub-block TLV(s) (inserted by content forwarder), are located in the message.
If you still think there are some ambiguities or bad statements in the current draft, please tell me. I'd like to correct the ambiguous statements.

> * some fields like HopLimit and ReturnCode are defined in ccnxmessages. The draft gives the impression you are redefining them here - be clear that these are handled identically for all ccnx packets and CCNinfo packets/messages are not special in this way.

CCNinfo's HopLimit and ReturnCode fields are specific for CCNinfo. Defining these fields is consistent with the definition of the ccnxmessages draft as CCNinfo uses the own packet type values, i.e., PT_REQUEST and PT_REPLY, and the CCNinfo's HopLimit and ReturnCode fields are categorized as "PacketType specific fields" defined in ccnxmessages. Therefore I don't think any contradiction.

> Identifying Forwarders/Routers
> I think it’s a mistake to define node identifiers as a separate protocol element that needs assignment via a non-ICN namespace. These should be handled as CCNx names, specifically:
> * a Name for the forwarder itself whose prefix is:
> * a Name prefix for each of the management data objects that can be returned in a CCInfo report block.

CCNinfo is aimed to investigate/discover the topology information or in-network cache distribution or conditions. Therefore, the node identifier specified in the report block should be capable of indicating the network location or equipment. If this requirement is satisfied, any identifier can be used for the node identifier. As the typical example, the current draft mentions that the node identifier could be an IPv4/v6 address. However, if other node identifiers, say unique node names, are defined within the target network and can make users recognize the location/equipment, routers/forwarders can use them instead of an IP address.
(Well, how the node name (ascii code?) can be mapped into the node identifier field is not defined in the current draft. The revision will cover this thought if necessary.)

> Registries
> The draft contains registry assignments that are associated with ccnxmessages and not the current draft. This needs adjustment to:
> * Refer to the corresponding registry in ccnxmessages rather than repeating them here
> * Suggest values for the new assignments, but do so via an IANA actions section - again mirroring how thing are laid out in ccnxmessages.

In this draft, we define several new type values but all these values do not overlap any values defined in ccnxmessages and are compliant with the spec.
On the other hand, it is obvious that we need to explicitly add the IANA consideration section to explicitly say the necessity of IANA registry. It has not been described in the current version but in the revision. Thanks.

> Detailed comments
> 
> I didn’t do a really comprehensive proof reading, but here are some things I noted:
> 
> Page8: 
> * s/forwards back to the node/forwards back toward the node/

Done.

> Page 18: 
> * Object size seems too small to cover the entire size of a cache, which could easily be terabytes in size if the forwarder supports a backing store. I suggest scaling this number in KB or MB since smaller granularity seems of limited utility. It’s also unclear if this is just unexpired objects or all objects. Further, it also seems unclear if this is a count of everything under the prefix supplied by the user or everything (the two are the same if the user asks for “/“)

If you agree, we'll scale up the object size from byte to KB. Currently, the maximum size expressed by 32 bit field is about 4.29GB, but it will be then about 4.29 TB in the revision.
The object size means the total size of kept (unexpired) content object(s) for the specified name.

Regarding the prefix specification, Section 3.2.1.1. (Reply Sub-Block) says:

"CCNinfo allows to specify the content name either with a prefix name (such as "ccn:/news/today") or an exact name (such as "ccn:/news/today/Chunk=10"). When a CCNinfo user specifies a prefix name, s/he will obtain the information of the matched content objects in the content forwarder.  On the other hand, when a CCNinfo user specifies an exact name, s/he will obtain only about the specified content object in the content forwarder."

Also we do not allow users to specify only the scheme name (i.e., ccn:/). This will be explicitly mentioned in the revision.

Object size is for all objects. I explain later in this mail.

> * It’s not clear if these numbers, especially the counters, are supposed to survive reboots. If not, you need to report uptime, or better absolute time of last reboot to be able to post-process data in a management application.

I think it's up to the implementations, though, general CCN implementations refresh the cache and the counters whenever reboot. What the spec needs to specify is: "if the cache is refreshed after reboot, the counter MUST be also refreshed (i.e., set to 0), and if the cache remains after reboot, the counter MUST be kept as well."
What do you think?

> * Some of the numbers, like total received interests, can be difficult/expensive to provide in a distributed forwarder design, or one that just shards the PIT and CS. It’s probably worth pointing this out somewhere.

Thanks for the comment.
I should clearly mention that the # received interest is the total number of the "all" cached content objects (after boot), not "unexpired" cached cobs. On the other hand, object size, object count, first seqnum, and last seqnum are the number of "unexpired" cobs. In the draft, I mentioned "(cached)" instead of "unexpired", but it seems ambiguous. I changed the word to "unexpired" in the revision.

BTW, what does "distributed forwarder design" mean? All of these numbers are per router. Do you imagine some other situation?

> Page 22:
> * I’m kind of at a loss to figure out how a forwarder in general knows whether it’s a “first hop” forwarder and why this matters. Some more explanation might help.

I think this is an implementation specific question, but a very important question as well.
I'll post a new thread for this question.

Thank you.

Regards,

Hitoshi