IETF Logo Mail Archive

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

Colin Perkins <csp@csperkins.org> Fri, 15 January 2021 18:35 UTC

Return-Path: <csp@csperkins.org>
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 527DF3A1083; Fri, 15 Jan 2021 10:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=csperkins.org
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 8FpcfgBHFmRX; Fri, 15 Jan 2021 10:35:25 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 B6CF63A107F; Fri, 15 Jan 2021 10:35:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=FKkF8aW1m7N3oR0kIHW1TTUsKGaQp9wyOv75spnxvBY=; b=1t4peK7VEcJW4SIBumgb7qZmgc /J66wdzuNzGeiLWiA0WPEN8lITjJ/VMXIBPCAQIn922E2DF3oNI/HNxQ0nFSCPmh3WKDzchRZHJ0D eoRC7YbhcHLSPiR7Fe1rPblm0B8tNq2tNMZ749yzXH9NHco9wYuqqEKmU8QMfxFefMe5eLGJOUSv5 7NTgnLLk5WYMKK8DqvPGx3e4Szh1hhlerp/Pk+h8T+49OuKWtjWQgRjg4UDjgZ1u4Vei5MuWNJsx0 c/l48BJGJko20sTIfhnYMH704mLThMxKgPFKpsTZLm0/GNWceHgSxvtwweAcxViY+pCmocV1I3Rw2 vpTsxOng==;
Received: from [81.187.2.149] (port=43575 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1l0TwO-0007oU-9m; Fri, 15 Jan 2021 18:35:24 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <18a6633f-53af-4fdb-b815-8708ec0344ee@www.fastmail.com>
Date: Fri, 15 Jan 2021 18:35:15 +0000
Cc: The IRSG <irsg@irtf.org>, draft-irtf-icnrg-nrsarch-considerations@ietf.org, icnrg@irtf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3794AC60-E4AC-4CEC-B4D0-819DFAA97742@csperkins.org>
References: <18a6633f-53af-4fdb-b815-8708ec0344ee@www.fastmail.com>
To: Christopher Wood <caw@heapingbits.net>
X-Mailer: Apple Mail (2.3445.104.17)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/tP7vmZQpS0ubtoWj4hEhqMYwJ1Q>
Subject: Re: [icnrg] [irsg] Review of "Architectural Considerations of ICN using Name Resolution Service"
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: Fri, 15 Jan 2021 18:35:28 -0000

Chris – Thank you for the review!

It seems there’s some discussion, and possibly a revised draft, needed to address these comments, before the draft can proceed in the publication process.

Colin


> On 11 Jan 2021, at 14:54, Christopher Wood <caw@heapingbits.net> wrote:
> 
> 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


-- 
Colin Perkins
https://csperkins.org/

v2.23.0 | Report a Bug | By Email