Re: [icnrg] Technical question on CCNx Specs

Ken Calvert <> Wed, 22 April 2020 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 751153A1157 for <>; Wed, 22 Apr 2020 10:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ExyWv62S6Rhl for <>; Wed, 22 Apr 2020 10:50:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4864C3A1156 for <>; Wed, 22 Apr 2020 10:50:27 -0700 (PDT)
Received: from culp.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D0A3418181; Wed, 22 Apr 2020 13:50:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1587577824; bh=7EAn1PJIPH9sXZxyx1BN9qIsdCh8bPi7OBI9vdMD79E=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=T5dcxbKTFk3PiWIJ7PJCR4tE1Py1qGaufRcTQqZEYos7W5p51bGrQmoL79ygn7gXl Zt0BccckcYrMcH7HcRGbIcsbVyjdSQl3ziU7v7W3d2VdnMGnCLLC/Zk2bQpJw1MJg2 e6b1zX9wyYFnMyKVvOSgRuVudaRwfHjSloiQ93JW+Ip/aPtwei27JqB+i1KsPFSBEy ud9XFqFNGYiJc1LO2h/5te7ZDHkp1vzeCTk4yNUzo+HOtgAEkP28g6DMbysI43Q381 66868WMIIFUVoOGWsRqrsh4qOjXeeh+mnsSvqi9+EM/rlvJpN3VLGX8flxN91t4VSt 1yYQ0LVxS89Dg==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Ken Calvert <>
In-Reply-To: <>
Date: Wed, 22 Apr 2020 13:50:21 -0400
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Marc Mosko <>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <>
Subject: Re: [icnrg] Technical question on CCNx Specs
X-Mailman-Version: 2.1.29
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, 22 Apr 2020 17:50:30 -0000

Hi Marc - 

Thanks for the speedy clarification.  I agree that leaving the TL outside the validation region is basically harmless.


> On 22 Apr 2020, at 13:13 PM, Marc Mosko <> wrote:
> Ken,
> RFC 8569 does not imply any particular encoding mechanism, like the TLV form of 8609.  So, 8569 will not make distinctions about TLV headers.  One could be using S-expressions or a fixed order length encoding or JSON.  Each particular encoding would need to say what it means to be a field.
> In terms of RFC 8609, a field, like ValidationPayload, is all three of the T, L, and V.  The value of the field is just the V.  So, for validation in specific, the protected region begins with the CCNx Message "T" and ends with the last byte of the ValidationAlgorithm "V".  The entire ValidationPayload TLV is not included.
> Let's look at what this means.
> 1) The "T" must be T_VALIDATON_PAYLOAD.  If it is anything else, it is either skipped or there's no validation payload to compare and the check would fail.
> 1.1) I believe it is possible for someone to insert a T_ORG or T_PAD between the validation algorithm and validation payload.  This would be outside the validation region but still considered part of the PacketPayload TLVs (8609, Sec 3.1).  A T_PAD would be skipped.  A T_ORG would be optionally processed if one knows how to process it and one expects it to be there.
> 2) If the "L" is not correct, the validation will fail.  
> 2.1) Someone could shorten the L, in which case there are not enough bytes to match so the check fails.
> 2.2) Someone could lengthen the L, in which case it would run past the end of the packet and the check would fail due to illegal formatting.  Someone could also increase the fixed header PacketLength, but that would also run past the end of the received datagram, so that would fail due to illegal formatting without even getting to the validation check.  Or, there's just more bytes than the expected validation payload and the check fails.
> 3) Someone changes the V.  Well, that's the point of the validation algorithm, so hopefully the check would fail for any good validation algorithm.
> So, if someone changes the T and L, the check fails.  
> 8609, Sec 3.3.3 allows hash values to be left truncated to specific sizes.  In specific, a T_SHA-512 could be sent as a 32-byte version.  However, all important hash values are inside the validation region, so they cannot be changed.  If a producer decides to send a T_SHA-512 as 32-bytes, that's their usage.  Sec 3.3.3 does not allow, for example, an HMAC output to be truncated.
> Marc