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

Christopher Wood <caw@heapingbits.net> Wed, 15 June 2022 14:48 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 1C3DDC157B4F for <icnrg@ietfa.amsl.com>; Wed, 15 Jun 2022 07:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.1
X-Spam-Level:
X-Spam-Status: No, score=-7.1 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_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, 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=jveF86J8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Uyc8TRgK
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 6hlG4e6MYgAC for <icnrg@ietfa.amsl.com>; Wed, 15 Jun 2022 07:48:54 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39001C14CF17 for <icnrg@irtf.org>; Wed, 15 Jun 2022 07:48:43 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CA2D13200ACB for <icnrg@irtf.org>; Wed, 15 Jun 2022 10:48:41 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 15 Jun 2022 10:48:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1655304521; x=1655390921; bh=uqwRcS6qaQ Mgp57AwHtM9PbAkWystHdq/zKbV6r/8co=; b=jveF86J8n3P6iXYW2ZU4GhXCsn jFbEykcDW/ylNheSbCGU9+IlUHZUjeC3ZLjEWi1J6YElm8kPLgmcysJQy5SQmm+5 eXXJGDu8djQHVDwSf6RtuIi7V8EJJBRtKSFGMCZZD7WFjdVLQCbvfQzUMmoPqGag 4uCJUs8Ob/REXvH5dGLqF3kqFKeQjiKCo3iwwJla83PIOQtafC8TWFTlcFOkgU4g eZx5tjcapCzbJniP4KDJ8snSUEsFhA3W4v1j+Ms6vcjYlGuFeARTIeXz9Y6O6MIY /vpSACxnYbBP7dgpFe8nEwvjQbAaBbSqAV9R5PpjsrFCXgoZplua2z45mEcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655304521; x=1655390921; bh=uqwRcS6qaQMgp57AwHtM9PbAkWys tHdq/zKbV6r/8co=; b=Uyc8TRgKyfIgFF0dHhnzGeAYnMEkX+9FVU4UkeX0SSGr YMxRU0EtIX4QncjEbG3Uc1voy2cEv2x3hxoxgWRqDipWcHMe/BNEKfblm5i5QnDA JA0iSMTODqpYqUmwbRhePajocpXaKDeoyllqCl1mnDDojDp+xAQuENW/PoOrZ8k5 Wtr6vRLmeJ8t+zY7lgrYqk0xc5yMoXMz6ErXPCcActz/YnG4gWUUUaxCMYuu/nG7 SB5oCVCZn/qAVOBkEZVQYUIwMeg6LcEMlA+J95kQm/QJSapDCX4ReTKEiU1Ad7Wp hp4dAKDJpkZEYhbMZWv7arSRFZfgQ0rwQn+mBlPy8A==
X-ME-Sender: <xms:SfGpYgPlBXbo3slRk5DBjf-CxRT-kxNgo2Pw2LfrZMSd6x38Pxv5PA> <xme:SfGpYm9Q_YwUwkNYIQcU2ji3p1JfM-HxDbHjP9fFfQK1UK3XnDKHPne8fflMtipPG ET-XvMlSdoTkmqgbm4>
X-ME-Received: <xmr:SfGpYnRR0_3-Pjusv2SJgkwp_Sw6ZjGNUC8BHqR4Myu_FdapkEOwu1OpuHioHG_UnQs21a9qDhNwf1eC-Ny2L6rq6GXz2CYTv3k>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddvuddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtddvnecuhfhrohhmpeevhhhrihhsthhophhhvghrucghohhougcuoegtrgifsehhvggr phhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeejiefhleegudeiudfgve ekkeeuleekfeelvdehvedvheelkeeghffhkeduffeuhfenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrd hnvght
X-ME-Proxy: <xmx:SfGpYotS--HM6JJmKON0DLUIRtaLOCzLE4AgvU2uVDOKE4xQmtB55A> <xmx:SfGpYofLkuLIJ-zh0N4EHO-O3uPLNs4CZ10FoC_90ZciBuBJucTsOg> <xmx:SfGpYs2Oto4wOgRjPrBX13qHndnh-6okxS-zEwGPwOwiSQ6qSYKdqA> <xmx:SfGpYiqCa4Ln8eROJsNtV3SsEh1AdGmORU_q7ujwpmVk_Zcr8NezoQ>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <icnrg@irtf.org>; Wed, 15 Jun 2022 10:48:40 -0400 (EDT)
From: Christopher Wood <caw@heapingbits.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Message-Id: <DC888366-23E6-4FD0-9FD0-24AACB98BCF9@heapingbits.net>
Date: Wed, 15 Jun 2022 10:48:40 -0400
To: icnrg@irtf.org
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/F5XHbzS1YxEuRfEjD3J2CDptDw4>
Subject: [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: Wed, 15 Jun 2022 14:48:59 -0000

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