Re: [icnrg] Review of draft-irtf-icnrg-icntraceroute

Colin Perkins <csp@csperkins.org> Tue, 09 August 2022 15:25 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 77998C14CF16 for <icnrg@ietfa.amsl.com>; Tue, 9 Aug 2022 08:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.406
X-Spam-Level:
X-Spam-Status: No, score=-4.406 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_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
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 b46F4M6sU2Bb for <icnrg@ietfa.amsl.com>; Tue, 9 Aug 2022 08:25:26 -0700 (PDT)
Received: from mx1.mythic-beasts.com (mx1.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 ADBA9C14792A for <icnrg@irtf.org>; Tue, 9 Aug 2022 08:25:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=wh+iAXSIAg7PfITRWyVHS/vFmdQpeRoxX7nRxcFx6+g=; b=nuURuXvV5CzKGZQa+sNftUeG5u sPEQpBt2GxB8iGgtC/Pb9GcVhNVICvb0bdMJ5eyDj8/kFZGcctKc6RMVYAknR11dn/Imudd7BUSTb tDGQ1WeoQhQ52vDfep/uJ/Lbivfh74H4GskqIfcAtOAj14Jc/r4KeFnuwGgLEc9rSQy2ZxgIEQwTc 8o+SjRbhsBcfwsHVPB6WtrFrWDq6RRsEv1q8A6BCUg+sJB+eq0X0cU1osfT1N0FjM5h0k975IBuo2 vf6oMANWRp5+fiJlpS2n6e+P9ufaIpslsKYOE+69/C6mWQOBxkpExz8ERTkwb6jA87+847lA3VuZJ 3Ugh4lvA==;
Received: from [81.187.2.149] (port=46569 helo=[192.168.0.72]) by mailhub-cam-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <csp@csperkins.org>) id 1oLR6g-006YK4-RU; Tue, 09 Aug 2022 16:25:23 +0100
From: Colin Perkins <csp@csperkins.org>
To: Spyridon Mastorakis <smastorakis=40unomaha.edu@dmarc.ietf.org>
Cc: Christopher Wood <caw@heapingbits.net>, icnrg@irtf.org
Date: Tue, 09 Aug 2022 16:25:14 +0100
X-Mailer: MailMate (1.14r5907)
Message-ID: <57C45821-5AAE-4648-B6D0-A2A6C08E537A@csperkins.org>
In-Reply-To: <E838CC2F-4BB2-4E9A-8946-60D913FE7306@unomaha.edu>
References: <DC888366-23E6-4FD0-9FD0-24AACB98BCF9@heapingbits.net> <E838CC2F-4BB2-4E9A-8946-60D913FE7306@unomaha.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/LY326YU_-5VPn5mTFFOvgUrRd5I>
Subject: Re: [icnrg] Review of draft-irtf-icnrg-icntraceroute
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: Tue, 09 Aug 2022 15:25:31 -0000

Spyros – thank you!

Chris – could you please check if the following would address your concerns?

Thanks,
Colin




On 1 Jul 2022, at 12:22, Spyridon Mastorakis wrote:

> Hi Chris,
>
> Thank you very much for your feedback! Please see my response to each of your comments inline. If you agree with my responses, I can go ahead and update the draft.
>
> Please let me know.
>
> Thank you again!
> Spyros
>
>> On Jun 15, 2022, at 9:48 AM, Christopher Wood <caw@heapingbits.net> wrote:
>>
>> Non-NU Email
>>
>> Like the ping document, I found this to be very well structured and written. The use case for the protocol is clear, the protocol itself -- including the forwarder behavior -- is simple, and the security and privacy considerations are thorough.
>>
>> Section 1.
>>
>>   To this end, the problem of
>>   ascertaining the characteristics (i.e., transit forwarders and
>>   delays) of at least one of the available routes to a name prefix is a
>>   fundamendal requirement for instumentation and network management.
>>
>> nit: s/instumentation/instrumentation
>
> Thanks for pointing out this typo!
>
>>
>> Section 6.
>>
>>   The TrReply Code TLV value of the reply is set to indicate the
>>   specific condition that was met.  If none of those conditions was
>>   met, the TrReply Code is set to 4 to indicate that the hop limit
>>   value reached 0.
>>
>> Perhaps I overlooked it, but why does the TrReply Code need to be 4? Is it because there are three prior conditions for the final reply in the session?
>
> This value is based on the protocol specification. We have mentioned it at the end of Section 4.2.
>
>>
>> Section 8.
>>
>>   This approach does not protect against on-path attacks, where a
>>   compromised forwarder that receives a traceroute reply replaces the
>>   forwarder's name and the signature in the message with its own name
>>   and signature to make the client believe that the reply was generated
>>   by the compromised forwarder.  To foil such attack scenarios, a
>>   forwarder can sign the reply message itself.  In such cases, the
>>   forwarder does not have to sign its own name in reply message, since
>>   the message signature protects the message as a whole and will be
>>   invalidated in the case of an on-path attack.
>>
>> Could a compromised forwarder swap out the name of a traceroute request with the name of its choosing? If so, perhaps this should also be listed in the paragraph above? To be honest, I forget the semantics for how content object response signatures are verified, so this might not be an issue.
>>
>
> My understanding is both in CCNx and NDN, changing the name of a request would invalidate the state in PIT, therefore, a response will not reach the client. To this end, it is unclear to me how much damage swapping out the name of a request could cause in our case. Indeed, unless requests are signed and the signature is verified, a forwarder could swap out the names of requests, but the corresponding response will not reach the client. I suppose a malicious forwarder could still see the response before the response is dropped. I am happy to mention that in Section 8.
>
>> Hope this helps.
>>
>> Best,
>> Chris
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/icnrg__;!!PvXuogZ4sRB2p-tU!Ck_l3JqxhS1GBV4FC0GZ9yNSHQAmGDDxHwyH_qxYPljEt7_FZEOymbblf1Re5Ilt9oDVo4a6Ux6ZCuQE_ZM$
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg