[icnrg] Review of "Architectural Considerations of ICN using Name Resolution Service"

Christopher Wood <caw@heapingbits.net> Mon, 11 January 2021 14:54 UTC

Return-Path: <caw@heapingbits.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 F19D43A0E3A; Mon, 11 Jan 2021 06:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=sClQ8FZo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FogFY0L1
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 EFShZTleLlKK; Mon, 11 Jan 2021 06:54:57 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580D23A0E39; Mon, 11 Jan 2021 06:54:57 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 534B02558; Mon, 11 Jan 2021 09:54:56 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Mon, 11 Jan 2021 09:54:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=1zWCB0wLmMhTF4aByzN/fjOdzDouT+5690/KNSOGMEQ=; b=sClQ8FZo 3aAXynWT7pXvLwHyHcIoSaYUDxTY7YX3AYRiJc6SqwfGBjVpBoIoIqlHcxk9rpKT HvMmNobTAGYQHsGcOH2njKzIyXdhZEj2bThVKtBnN32k1vVL1KJnENn4TaqlbvSH UMyOv424zJtnbxKOUfKGEwCRLVObJqKgT1NgkThaPFSUT5+7yjl3a83qbTD0NAKz ENbifbKf87E7Jta/a6hn8ZkNfOEmghl8MF9P62pmnMKaD0xTsMUpENT+Bfvo+8ER scP2rKlTXfkXnVmv/t6k3288hNuZd8nqY0RKzzc1LjdIPTbyRpjuh8C0hQ2vGOdu NLFJSs0PuzGZyw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=1zWCB0wLmMhTF4aByzN/fjOdzDouT +5690/KNSOGMEQ=; b=FogFY0L14JOLLEVoRZ3/LWT1Vj0vFv1R+PPLQFnP9AqF2 O71R8clkNzshrPexWsKr3GS/ePAvN/0AEPU7M+BScxfyMicvBR5nkk8129WsMt6Z 0vKL9YJWsAHAALxDXhOpGONyxjn0FvLNbLbx0lxZvwDalQCVJXxMOcYJyLGBl0KB 75YEHP5Y/wKAJNTOJqAQqDD8ZWHwAXzWDCJaEt9pwwK4MM5U5WRm1kjprhCagIVh FxfhBKrvov95fwVxCnBU8nW7VLx0vPu8Op5lLFhkhk0Ed12tWj1emFQNc1dRdUTe p0rsgFuM6n4nH0Ok2pP88fgiOpf/f4G5NaDp8Pc+A==
X-ME-Sender: <xms:v2b8X94PjLtM4Rs1_rPe0QzqZa78anbGXG2auF6Lfp38AuF6e7443A> <xme:v2b8X65Rgh0SKrQdP5h5C3aMfu5E2jf-bdMswMHdTq2naM80VsScYs0IPTa5hMklL AwO0V82-mkSjS9PnO8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdehuddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehh vggrphhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeeftddthfdtke ejvdfftddtkeevjeevudefhfdvuefgheffkedvkedufffhffenucffohhmrghinheprghr gihivhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:v2b8X0dzp82yShAZP0-iS29lD4U2NeS3kCy52ytwFIzUxMBM0g2eJA> <xmx:v2b8X2JLNR6320tzFj5kfrL8Zat-rdip8NIOuUeJTdMFGOSRgFyx8g> <xmx:v2b8XxLpBnXB70L0fAJIuUUFZn3-5nuKWEie233_Ik9d_KqXa8fz5A> <xmx:v2b8XzwSv21Zu-BCGf717cLASammGOBEh8_yxzNhUNUDHwbXEVPECQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2800A3C00A1; Mon, 11 Jan 2021 09:54:55 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560
Mime-Version: 1.0
Message-Id: <18a6633f-53af-4fdb-b815-8708ec0344ee@www.fastmail.com>
Date: Mon, 11 Jan 2021 06:54:29 -0800
From: "Christopher Wood" <caw@heapingbits.net>
To: irsg@irtf.org, draft-irtf-icnrg-nrsarch-considerations@ietf.org, icnrg@irtf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/yY5CzPlaY41-T2L_chW3m7BaLuE>
Subject: [icnrg] =?utf-8?q?Review_of_=22Architectural_Considerations_of_I?= =?utf-8?q?CN_using_Name_Resolution_Service=22?=
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: Mon, 11 Jan 2021 14:54:59 -0000

Document: draft-irtf-icnrg-nrsarch-considerations-05

The summary of the review is: Ready with issues

Comments: 

Given that this is a considerations document for ICNRG, I think the level of detail is probably fine here. My biggest concern is the lack of discussion around NRS mapping management. The document states:

   When an NRS is utilized in an ICN architecture, security threats may
   increase in various aspects...

And then briefly describes "Name Space Management." It states that producer authentication is required, but I would like to see some more discussion there. In particular, is authentication required for only insertion into the NRS? What about updates or removal? (Something like BEAD [1] might help deal with deletion.)

On a related topic, how do clients (resolvers) know if they received the most up-to-date version of an NRS mapping? Should these be stored in cacheable content objects, or in new protocol messages that are not cached? This relates to the discussion around mobility, and I'm not sure how much detail you want to add here. Maybe just mentioning the possibility of stale content as a consideration will suffice.

Lastly, how a NRS impacts client behavior seems a bit unclear at the moment. This document seems to suggest that names can only map to other NDOs, and not, for example, prefixes. Should it be possible to query the NRS with a name prefix, and the NRS performs LPM to return the mapped value? What are the implications for clients if they can query by prefix? Should they always query the NRS before sending an interest for a name?

I hope this helps.

Best,
Chris

[1] https://arxiv.org/pdf/1512.07311.pdf