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

Colin Perkins <> Thu, 25 August 2022 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FF13C15948E for <>; Thu, 25 Aug 2022 14:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.407
X-Spam-Status: No, score=-4.407 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, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lpQI5fj05ezv for <>; Thu, 25 Aug 2022 14:39:17 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id A77DCC15948B for <>; Thu, 25 Aug 2022 14:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=MBErCCkBQxoffiv6fYjAkASkmMW6oSnuNmeZa7oQjv8=; b=0gcoKesssuuab+hJkwcLwcHzGs xyX/v8vVMQ3GtrkP9Ep34zzJaibLhK3Ds0YXmGPqqkQK7b08flrOjSeh4OgoSh2kxEHzsqF8ykZSS eDZRT9X16yQEyujuf5hulLmvGFp581UhsvCQtssUlgEERSB6iNWHC5Cy1+LnVRdX7D3puAwYnlLak CQNnhC7ooJf0VXyGjW1oaWqcf9yDRfeXvGnXLXbPal1EKiocjatbuOBhCcW+N3Dxy0g+FtBlPD7tp B1ZPd1uJt23LdZEWAyXq+B2tVdbOyEqvCou6kqfH5CRfNvEkwFFujdvjAiXJhaV2Oj892jw3w/7q2 LVhckv1g==;
Received: from [] (port=38564 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1oRKZF-00Czwk-To; Thu, 25 Aug 2022 22:39:14 +0100
From: Colin Perkins <>
To: Spyridon Mastorakis <>, Christopher Wood <>
Date: Thu, 25 Aug 2022 22:39:06 +0100
X-Mailer: MailMate (1.14r5913)
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BlackCat-Spam-Score: 0
Archived-At: <>
Subject: Re: [icnrg] Review of draft-irtf-icnrg-icntraceroute
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Aug 2022 21:39:22 -0000


Can I check if you have what you need to progress with the updates to this draft, or if you still need input/confirmation from Chris?


On 9 Aug 2022, at 16:25, Colin Perkins wrote:

> 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 <> 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 mailing list
> _______________________________________________
> icnrg mailing list