Re: [icnrg] Comments on draft-oran-icnrg-reflexive-forwarding-02

Dirk Kutscher <ietf@dkutscher.net> Fri, 03 June 2022 18:50 UTC

Return-Path: <ietf@dkutscher.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 49559C14F72E; Fri, 3 Jun 2022 11:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXlcXHeOaGO0; Fri, 3 Jun 2022 11:50:43 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C198EC14F725; Fri, 3 Jun 2022 11:50:39 -0700 (PDT)
Received: from [192.168.1.50] ([95.89.114.110]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N0nzR-1nccWH2oGz-00wpi9; Fri, 03 Jun 2022 20:50:36 +0200
From: Dirk Kutscher <ietf@dkutscher.net>
To: Ken Calvert <calvert=40netlab.uky.edu@dmarc.ietf.org>
Cc: icnrg@irtf.org
Date: Fri, 03 Jun 2022 20:50:32 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <96AE3092-534B-42BA-BB78-2E131354BC65@dkutscher.net>
In-Reply-To: <A575B682-D9B5-43E2-B6CA-0394D022D895@netlab.uky.edu>
References: <A575B682-D9B5-43E2-B6CA-0394D022D895@netlab.uky.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_D11B0B71-FE99-44B0-9EA5-7CA0920F712D_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:MC79IwVWS/QEgSj6r6xhB6yj38osfpfK3U/nT/EeFJIous7nZri bGivGzu8n5BZ43knZ3ngKh6MlhaGS4hFFj5tWKQzI9hzHfWHvYeGHBWAIGHjRNoT4zGNCef Yzz4xn4HCf89DidxRROpXNL/Vt3s8mq+GL60Nxdd7OdzTOlKV6FyETQhpTlXUDsP6Y563mP 5Sun30SG5MFWwKtgpC5lA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:VtdDYqk5UyE=:YyrBd2DnN13hbn/CVoOYFR /EMNqS2jf4orWTAJoA6UHcaRjZdIJmovQyGMiV6sQ1oTu2lG2DSPYyWtpR3ZJnbWcOuYNS+32 U29g/bvHWZzZ+cUphwQSKBWOrIqxXMIm96betEtnut9kf4UIxHczy5C9kfcX84wcQv6CdN83M S6W1bu6SInCTDDoUIJZPAK6Fcf8y8DKnvuNPIDlfMSKDAMsxfhEmYWhGUTMYp0hVSZtYjk5yj /4kWC6GRjiTpoBYqzNXY21X3xsLExkHRToFfmv9R5sdTvvg+VXXfZonXZbpH/cqZzIqgtP9mi OcOhxYyBN6YF1YjTS5ol8X1NnPMxMnLxGnrqkCBlK0jm1Opu3MlXQzTP0NxwfV85dm8lRZNhT d1eceooaqXePginq5O89Mz9m/NZs9QrLQ7gkJIVUplq/0GNydE0ONn1mEbsM14a9JVFzBSMCx RBX6kO59fupEbvjcKuPEAbMqiOotjy7lGqbtp3c+qPhGGnmamEAJxDF5UiFeft912qrvzVF4p PoHVsL6e4pSx+3fyfKklfF8sdgdUdR7dpcixf6+MsXUnVKZBQI6OZj7MlULXAg75qpn6jCz4t j5GXtgc7WM3SPG9uBjEoYoiX1yBRhxROWfCh5CJLLSfFU/XrqRPIZMZwL6JzIJUdlP1IZYxVD LI3/thgyxbhdKBjvP0nZdBO68kX+OgLLFMnOk/n3WKmJlmmrLiOumZwQ0FBptnRZK9DHOnQuG Exrz5GHrpHzW9j5xCdWoMLkYuSWC5/X8NY+12w==
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/5GMkkdt4CxR4SOAo30TKEcTvioY>
Subject: Re: [icnrg] Comments on draft-oran-icnrg-reflexive-forwarding-02
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
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, 03 Jun 2022 18:50:47 -0000

Hi Ken,

excellent – thanks a lot for the review – really super-helpful. We fill fix the nits.

On your other comments:


> Section 3:
> Figure 2 - I know it is challenging to fit everything in the ASCII art, but the notation is a little inconsistent and therefore (to me) confusing.  For example, what is the difference between "FPT(I2)" and "FPT of I2"?

No difference intended – will make the notation consistent.

> And is it the intent that the forward PIT token sent upstream over a link will ALWAYS be used as the RPT for reflexive Interests sent downstream over the same hop?  And mutatis mutandis (up<->down, forward<->reverse) for the corresponding Data objects?  Or is this an implementation choice?

If PIT tokens are used, then the RPT SHOULD be generated from the FTP, to enable the forwarders on the downstream path to access the corresponding PIT entry.

> Suggestion: give specific placeholder values for the various FPTs/RPTs in the example, e.g., "FPT=X", "RPT=Y", and show them in the message labels.

ACK.

> Section 5 - Constructing names for reflexive Interests:  Isn't case #3 subsumed by case #1?

Technically yes, but we wanted to highlight the use of manifests as a (likely useful) option.

> Also, could not a manifest specify other methods of constructing names for the producer to retrieve, e.g., routable ones (as opposed to just "suffixes that may be used" with the RNP)?  IOW: the RNP/manifest pattern offers a clean way to switch to routed prefixes, which seems like it might be useful in some (e.g., mobile) use cases.  Maybe worth calling that out, though I still think it should be part of case #1.

We did not mention that on purpose because this would open the door to reflection attacks (client could make the server access many objects on a third-party producer).

> Also - "Append a FPT TLV to the Interest if the forwarder requires the downstream forwarder to supply an RPT..."  - I'm a bit confused about this.  My (possibly incorrect) understanding was that PIT tokens are an optional optimization.  Though they need to be supported for the whole reflexive forwarding scheme to work, I don't see how one forwarder can "require" another to use them.  In fact, it seems like things will still work - in this specific part of the protocol - if the downstream forwarder ignores the FPT here.  If I'm wrong, maybe it would be good to clarify where PIT tokens MUST be used. Otherwise I was going to suggest "Optionally add a FPT TLV to the Interest for the downstream forwarder to use as RPT in any returned Data for this Interest" ? (I told you these were nits!)

Yes, you are right – the wording is not ideal. The tokens are optional. The forwarder can offer the FPT to upstream forwarders...

> Section 7.1.2 -
> IF Interest contains an RPT
>    use RPT to lookup [-> look] up PIT entry...
> ELSE ...
> What happens if either lookup fails?

Good point. We should exclude some "default face" forwarding in these cases.

> Section 10.2.1 - "It is therefore worth noting that the object is bound to the reflexive Interest full name via the hash..." - what hash?  The hash that is part of the Data object signature?

The name is a hash – need to rephrase this.

> Section 10.2.2 - T_RETURN_PROHIBITED - cite CCNx RFCs?

Possibly. Technically, this draft is supposed to update RFC8569 and RFC8609.

>
> Section 12.1, Table 2, entry for T_RPT - I believe "upstream" in the description should be "downstream".

Yes!

> Section 13.1 - "with Length 9 bytes" -> "with Length 16 bytes".

ACK.


> Finally, about backward compatibility and partial deployment (Section 11): if the third alternative (neighbor capability negotiation protocol) is taken, maybe path switching could be used to tunnel through non-supporting routers?  But that is kind of begging the question...

Yes, incidentally we had an initial design for reflexive forwarding that used path steering. We didn't go forward with it because this would create yet another dependency. In our view, PIT tokens are the way to go – they useful for high-speed forwarding as well.

Thanks again!

Dirk



> Cheers,
> Ken
>
>
>
>
>
>
>
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg