[icnrg] Comments on CCNinfo
"David R. Oran" <daveoran@orandom.net> Thu, 11 April 2019 20:30 UTC
Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8433120319 for <icnrg@ietfa.amsl.com>; Thu, 11 Apr 2019 13:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.308
X-Spam-Level:
X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc5xEJf4f1sX for <icnrg@ietfa.amsl.com>; Thu, 11 Apr 2019 13:30:10 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5831200B4 for <icnrg@irtf.org>; Thu, 11 Apr 2019 13:30:10 -0700 (PDT)
Received: from [198.168.15.22] ([IPv6:2001:470:818c:1:d5c2:4fe4:c54c:3cb0]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id x3BKU7wt009852 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for <icnrg@irtf.org>; Thu, 11 Apr 2019 13:30:09 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Thu, 11 Apr 2019 12:34:04 -0400
X-Mailer: MailMate (1.12.4r5625)
Message-ID: <28C48893-C834-45FC-A694-7E2D4D0BD203@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_85CFC528-C1DE-43AB-ADDB-E99E88093FD3_="
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/DQNDfc72Pzn6dHtObimWfqHCOxU>
Subject: [icnrg] Comments on CCNinfo
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2019 20:30:12 -0000
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. ***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. ***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, and avoids signed Request messages (which have all the problematic aspects of signed Interests). 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. ***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. * 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. * 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. ***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. ***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. **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/ 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 “/“) * 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. * 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. 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. DaveO
- [icnrg] Comments on CCNinfo David R. Oran
- Re: [icnrg] Comments on CCNinfo Hitoshi Asaeda