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

Christopher Wood <caw@heapingbits.net> Wed, 21 April 2021 14:12 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 D1A4A3A294D; Wed, 21 Apr 2021 07:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-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=hHkqsCMi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tzzOlSJB
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 JVbzu9Y16CXd; Wed, 21 Apr 2021 07:12:07 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F353A294A; Wed, 21 Apr 2021 07:12:07 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9583615D8; Wed, 21 Apr 2021 10:12:06 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute4.internal (MEProxy); Wed, 21 Apr 2021 10:12:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=m6 QtNplsvvyKch3ZrLFsif+Osu/FP2BRXqZwR0C14EY=; b=hHkqsCMiANug6bhAUs +f2Mfhl95lULIRzfwA5sFYucncSkrL3pqNjxTJuEwBrzeG6P37tQpm9w6tctgGce GKyhzdz9BwNOsbF8LOoMuJWP+lpJOZv6ZhTSIkRkU6qfo/UQMGaGnPJBK8zKH7a/ Kr08xw6G0X7I0gokQQeLq59fJ1MPTGp/vvvGyXJEfo7iFvaU1zrbPmPfJ+T9/7m1 GotxH7V476HpULbNsuCtF33uSmt6K3/GUZRvN5sjN6mEZ3dQGrg7azRvlHkIz7/Q +bf+6G8tVGpA+DtmfGsQWRE664kZ5T9kql1nNOvCBxdFsM8fjZKymzEGHaTQjvUX 60uQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=m6QtNplsvvyKch3ZrLFsif+Osu/FP2BRXqZwR0C14 EY=; b=tzzOlSJB/AJd+jHUBUqoKEJVSBJ6cTt5O0LcbfcW4onbNo5Xy4O/puhL4 wl6QrFxKydHmpza4qHzJK6lwQWT9nf0s75SqeLxCEFLSNxIW/rcm2+tIWfE9O44i QJI2aV0bpr+2fsVA65bS4z4wLoseGh9X7wTAAp2LzAzoE9uFK4AiQY0nnxtCtiJ/ 5xDmvlir4NkHi+Y3MZBBEbOY4ZnsK8sdV+x8p5UcCr5oGKqwQIfSjdM+5+Bij7xX LWGZv/HY+rDVLXK/veTBdxK9yh2AcLsREOtMfdhm2qpXWLnH0Wlat8TCS8nV3hoA oD5OuYm+lc58kh9tEUugg+CS9XUaA==
X-ME-Sender: <xms:tDKAYJUYJZ8yxerDXb2OjDRKh0v3xAatkIgCd_4PdVmBu0gCVPF8JQ> <xme:tDKAYJlxMz4xUmSw5YJKAGY7mPh8NKkFE_j3IKo9G1HNq4md6GBrn-llOxcteBo0c -WsAErWYcoJHNcNsAU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtkedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucggtffrrghtthgvrhhnpeetffdvueeigeehleeutdetteegteevieegvddvgeeh geelteduteettdfhgefgteenucffohhmrghinhepihgvthhfrdhorhhgpdgrrhigihhvrd horhhgpdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:tDKAYFYsYxKsFn38FxztGMn7Ng854PJUrlY_2r6RJXhOUorzWd53hA> <xmx:tDKAYMWQOqY8BrAVzx-pfEragVFB7-Z2Y8JFJrk4biWNur02VH7U2A> <xmx:tDKAYDlm4OzCGSKbPbsFx5UkhwwHH5EH4vR6w1SqVPMdgavw59bNHg> <xmx:tjKAYIyhctIFpRPzWonX7Doof-RUrtqzs7-ZLEZfarJp_4Zo1rg5-A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0896E160086; Wed, 21 Apr 2021 10:12:04 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b
Mime-Version: 1.0
Message-Id: <396c244b-3411-41bd-b510-41cdbeb56b36@www.fastmail.com>
In-Reply-To: <1CEF11D4-C525-4496-AEE4-55A65DD596E6@csperkins.org>
References: <md3azxhle216.md3azxhmjom3.g1@dooray.com> <1CEF11D4-C525-4496-AEE4-55A65DD596E6@csperkins.org>
Date: Wed, 21 Apr 2021 07:11:43 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "Colin Perkins" <csp@csperkins.org>, "Jungha Hong" <jhong@etri.re.kr>
Cc: "The IRSG" <irsg@irtf.org>, draft-irtf-icnrg-nrsarch-considerations@ietf.org, ICNRG <icnrg@irtf.org>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/cEYT_LJYPQYT1fnkpCaTv6UoCuE>
Subject: Re: [icnrg] =?utf-8?q?=5Birsg=5D_Review_of_=22Architectural_Consider?= =?utf-8?q?ations_of_ICN_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: Wed, 21 Apr 2021 14:12:13 -0000

On Mon, Apr 5, 2021, at 10:03 AM, Colin Perkins wrote:
> Thank you for updating the draft.
> 
> Chris – can you confirm if these changes address your concerns?

Indeed it does -- thanks!

Best,
Chris

> 
> Thanks,
> Colin
> 
> 
> 
> > On 13 Feb 2021, at 07:58, Jungha Hong <jhong@etri.re.kr> wrote:
> > 
> > Dear Chris,
> > 
> > Thanks a lot for the review.
> > 
> > The revised document, draft-irtf-icnrg-nrsarch-considerations-06 has been just submitted. 
> > We tried to address your comments as much as possible. 
> > (https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-nrsarch-considerations-06)
> > 
> > Please take a look at our responses explained in-line below and let us know again if anything is unclear.
> > 
> > Thanks,
> > Jungha Hong 
> > 
> > 
> > -----Original Message-----
> > From:  "Christopher Wood" <caw@heapingbits.net>
> > To:      <irsg@irtf.org>rg>;   <draft-irtf-icnrg-nrsarch-considerations@ietf.org>rg>;   <icnrg@irtf.org>rg>; 
> > Cc:    
> > Sent:  2021-01-11 (월) 23:55:08 (UTC+09:00)
> > Subject: Review of "Architectural Considerations of ICN using Name Resolution Service"
> > 
> > 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.)
> > 
> > [Editor’s response and revision]
> > Authentication is required for all insertion and update of mapping records. We have added text to clarify this point in Section 8 (mainly in NRS protocol and message security.) The update includes the substitution and 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.
> > 
> > [Editor’s response and revision]
> > As the approaches used in mobility management, we may consider assigning validity time or a lifetime of each mapping record. The lifetime can be renewed only by the authoritative producer or node while the cached mapping records get erased after the lifetime expires unless a lifetime extension indication is obtained from the authoritative producer. This description has been added to the first and last bullets in Section 5.1.  
> > 
> > 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?
> > 
> > [Editor’s response and revision]
> > In this document, we have assumed that name (in general) can be mapped to routable prefixes, locators, alias names, or off-path-cache pointers (in various Sections, e.g. 2, 5). We have not assumed any specific key for searching mapping records. Moreover, we have not mentioned the search key matching procedure. Clients can query by a prefix if the NRS system supports it. Clients are not required to always query the NRS before sending an interest for a named content if the ICN architecture allows ICN routers to perform name resolution. This statement has been written in Section 2 (NRS resolver, NRS client) and Section 5.1 (Name resolution).
> > 
> > I hope this helps.
> > 
> > Best,
> > Chris
> > 
> > [1] https://arxiv.org/pdf/1512.07311.pdf
> > 
> > _______________________________________________
> > icnrg mailing list
> > icnrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/icnrg
> 
>