[icnrg] Technical question on CCNx Specs

Ken Calvert <calvert@netlab.uky.edu> Wed, 22 April 2020 15:58 UTC

Return-Path: <calvert@netlab.uky.edu>
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 3E85E3A0F79 for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 08:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netlab.uky.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjgkrI5KKzpr for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 08:58:42 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu [128.163.140.42]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3783A0F78 for <icnrg@irtf.org>; Wed, 22 Apr 2020 08:58:42 -0700 (PDT)
Received: from culp.local (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netlab.uky.edu (Postfix) with ESMTPSA id 912D018181 for <icnrg@irtf.org>; Wed, 22 Apr 2020 11:58:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netlab.uky.edu; s=default; t=1587571119; bh=XXZD+rOZCcVTmeSasi5z+MX7xXbmEyuYxQry5MhQSxY=; h=From:Subject:Date:To:From; b=qN2dRJFocrOLsI/qx00sJ2I4ESE5AWxDbuT43QsCTCA0E4tveen8m5ktxMvmTLzk0 rj0kmV2lATJcHeBIdkbKaDrkGszNZB69zEwMy0m6i0YRXnXHI91/AXPuoydiaumCr3 2Vm0vozr9KX4Coxy7+a5fyix1tWfsEdPVkPkGWvM6mW+JEIgm2KZwaZSxYJ3cXPE53 CWqo10rg1L90RJeTrTTIBtS29vjCRXKt8yimCz+GzskKnKXGe05K3Jug1uBdBEOmKi erKraTICoW2vJR8r1P8YzZoh7Y2nDevHulPo9BJ+5IK3qCC2qUSpnxSeW40xmDoDev ywjz9Jv8lf5fw==
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
Message-Id: <AD85B3A5-D597-4DFE-8258-2F012B9B7FC0@netlab.uky.edu>
Date: Wed, 22 Apr 2020 11:58:36 -0400
To: icnrg@irtf.org
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/YOhWHnxUQLJqctByorwLv6dUOhU>
Subject: [icnrg] Technical question on CCNx Specs
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
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, 22 Apr 2020 15:58:44 -0000

Folks -

I am implementing a CCNx forwarder from RFCs 8569 and 8609, as a way of understanding the protocol; as a side effect it is a test of the specs.

I have a nitty-gritty (but simple) question I can't resolve with the RFCs.  I'd prefer not to look at other implementations, so I'm asking it here.  It's about the what is covered by the signature (or whatever mechanism is used).

Section 8.1 of 8569 says:  "The validation is calculated from the beginning of the CCNx Message through the end of the ValidationAlgorithm section (i.e., up to but not including the validation payload).  We refer to this as the validation region.  The ValidationPayload is the integrity value bytes, such as a MAC or signature."

There is an ambiguity here regarding what constitutes the "validation payload" (vs. "ValidationPayload", sic).  My question is whether the first 4 bytes (type + length) of the Validation Payload TLV are part of the validation region (i.e., covered by the signature, HMAC, CRC, or whatever).  RFC 8609 (Section 3.6.4.1) says  that the Validation Payload TLV is NOT part of the ValidationAlgorithm TLV.  So the first sentence quoted above seems to say that its header is NOT covered, while the last sentence (as well as common sense about security) would lead one to think that it IS covered.

Thanks for any hints.

Ken