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

Dirk Kutscher <> Wed, 15 June 2022 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6B27C1594A8 for <>; Wed, 15 Jun 2022 09:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cP0PaLv6On9A for <>; Wed, 15 Jun 2022 09:43:14 -0700 (PDT)
Received: from ( []) (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 162C4C14F613 for <>; Wed, 15 Jun 2022 09:43:13 -0700 (PDT)
Received: from [] ([]) by (mreue107 []) with ESMTPSA (Nemesis) id 1MD9CZ-1nt1nU2XJJ-009C5G; Wed, 15 Jun 2022 18:43:05 +0200
From: Dirk Kutscher <>
To: Christopher Wood <>
Date: Wed, 15 Jun 2022 18:43:04 +0200
X-Mailer: MailMate (1.14r5852)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_9734A612-528C-4B13-A3C0-8B8E9D0D9236_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:WGKp7ePCAaevOZXqNWbKjFjAg2kqw6nkZosIIzoDYeYcmxMsip/ 4WFkhNqWVZHMivqhFYCwoFcXeqNRprMO98dxs142EMZIbaOD5Kb9RvgOXd/OuKjzXH2+wGI Y2t2bPVCC89F3m9QB1c1y4k2Xv4FiMJfW92VPN/6cvy0sUo1PetVNHeT4OyTQdFaS3RDFkF B9YjLi4Uw3ZCDR9v45pdQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:TG9v+wJKkY0=:0C4THhS/Inr5Es1NnjF/nN jcPe9pgh65tHZ4ygndZ2CJUAW/T2vx7FVxnON0SbOUdtHgXD1FT3CprLcLForePTU5e8uBVsD jmuFjnd5aoag5b/8rdAqqs7/UekoPeJl0iUPaqFkLSDCzhNUdfO/qRykHn5xhSZ0XvL33OQGb Ye/d3bHBuAK0tKQUOA+eWg+R1Yc6XihQEIbK5F8tJLjQxk4B12n4Ec2XvKCVzCEufb+NUTJg1 Lv4pl4/2aPwJO3OF4q7iqDInoE3KdVZyPJhfgV5YodqO5s/QYiJNaNPHQzaAWUsDHZUWRsoKO M3Pce7tbD2TRD/Ru8eSQl0hsAvS8QHLeUciJdSfc3tHlKQ/AHsREK8hlbwGFfYB96XcPni4p0 4vbiIq/iFC3Mw5k3dsu5eAmX2401AeW6ixqgimOZAnwdMKaNkOZpB1hBAcokDdbS2pODk1M5h k9QFdyD/9lKZAE31eXf2Yf7bBpTOJ1oFIZIV0TVuBn0wOxXfMyx4nHdbYBfQH+MT+eFH0IyDh I275PQppIr029qF4AVrcXVuVoXD/v8fevgMXgBtSAU3obHn9LoMKX54T7mqHEqa2NkU1NfvhQ 8wLu7QWYcr35kTaZLjjoztIjo8dG0/6JabffWZgl8Xmt99UIdB7m4oZK23hi19gsnoe6MgYKp 9JVNvnih8HAGPuc8+WZnzTm2q9TdcYts05Q6C7koYuYINSYrEn1Dx9Ds5rvxSrmjCJPMlkSSL MyO7BJwhLz0bL54VRk7XNvgGveoN7ypf0Pk0/A==
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: Wed, 15 Jun 2022 16:43:18 -0000

Thanks a lot for these two reviews, Chris!

Let's wait for Spyros and Dave following up on these comments.

Best regards,

On 15 Jun 2022, at 16:48, Christopher Wood wrote:

> 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
> 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?
> 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.
> Hope this helps.
> Best,
> Chris
> _______________________________________________
> icnrg mailing list