Re: [icnrg] Technical question on CCNx Specs

Marc Mosko <> Wed, 22 April 2020 17:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39FFC3A10A9 for <>; Wed, 22 Apr 2020 10:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OwreDuBwqqdj for <>; Wed, 22 Apr 2020 10:13:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 258AC3A1098 for <>; Wed, 22 Apr 2020 10:13:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=GIFB8fueD+qQi5feYs94CeeUJ+tqzK/kQaz4HmGSssQETR6AP7DxlW+XxX8IYxRC1oFA/JgElXv8flgUsdOxkfdw0lHlYBZm06/j/Xx+7r3O7h9FXi7j0TS1pdt++VFh2DD09OoQc6eyewWgvk9Xopn1+c1xjhbFRbTBRJv5oDFUpCeNTf7Es2+9Y/qwdblU7S56xEhxi6qD/EnBkK5EmNUWmUpYInV8ra68+28gBhUD+eAAXX6tqaLNf6ui1pTuWEBq9Scqw/r2EKjv3cQlbiQgDjwVSK7d5a3e9l5+9EdrCb7JuiaI2Male0vzjwNDNbuuSYGJupK4AjEBrIDWJg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pwKg7BHunoVMbpv5BJGFLFSk1GN52EjgxsJBdQnPHZA=; b=KGiU1rCUob3dSOKdXlz1HQRsvxwH+sGHbzjtYEtwNYz90XPIP5PWD+jtOBjUbsnQW+XyQ72gr8uMUxN+3wB1sDXP6ndzzb248begpoc6C5rWEJTYBg1nLEYxQHhLWgObqiCLFIp0WKDU9T+TSqOkYCr2WlTEJ3qN14g4nJ5ENctAkOZjWG+kPt8JcnYtHq1Kn690I4yaT3CKxKSRqsjEjxDQCiCdvA29r1y021czE28eqZhQTDqqeDjeEtL0PyKgxRor31YLTWKUAqwfURzdUh6+WEY8JcKG6JY++/onBGB7cYTpdQsSI9IKnoeq85sBc0u7QuCzJXoah1pMAWT9+g==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pwKg7BHunoVMbpv5BJGFLFSk1GN52EjgxsJBdQnPHZA=; b=BkAmdutiD3g5qpxTK0B7sd7yISb/zwXwnsDUULfWxQrVMsmV1puMEmzuhv0lMNBIZpK0xCJuU9YJO/HdVwia6WEKDKk8EOTPpargBkLbBT/rPqZVm5uTVBGIUJiei7swy4XPfa+ryBmRAgT1m7f4dllh1dZd0QtS1a+kxRyOn7g=
Received: from (2603:10b6:a03:106::29) by (2603:10b6:a03:f8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Wed, 22 Apr 2020 17:13:30 +0000
Received: from ([fe80::e56e:1f6e:a036:156c]) by ([fe80::e56e:1f6e:a036:156c%4]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 17:13:30 +0000
From: Marc Mosko <>
To: Ken Calvert <>, "" <>
Thread-Topic: [icnrg] Technical question on CCNx Specs
Thread-Index: AQHWGL7wbetP0dxadkSafg2Ag515zqiE69iA
Date: Wed, 22 Apr 2020 17:13:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.35.20030802
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3cb0465b-8262-4beb-b058-08d7e6e07ae6
x-ms-traffictypediagnostic: BYAPR15MB2949:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03818C953D
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(376002)(39840400004)(346002)(6486002)(71200400001)(26005)(6506007)(33656002)(478600001)(5660300002)(186003)(110136005)(36756003)(2616005)(296002)(316002)(8936002)(966005)(81156014)(8676002)(6512007)(66556008)(2906002)(64756008)(76116006)(66476007)(86362001)(66946007)(66446008); DIR:OUT; SFP:1101;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: haLMyPgSojWO7Sirx6HWtjToQGIZh2msA6WQHJ3LUcqwlIzb0oaI1PcnzHrr+c7QJxdkJ/3+5Uthz3dhlqpyUHSNv9cDcqPtWYWOBbTf0xQKY+hcvyiPe+MqVh8y7JGfbURLkpuTfe67ePNyOrooAt4GvRxz1AmIl77WX3mkSo5pabKP0bpG8IbrB8t1+9acpAqR0kb0oqSM2UxSscTpzpBECsNmu2Ux9UYX0r7u1cex0gGPoKn0DOgS8rQSSxmApdzxQ9zf/hKzBfH0EZnH8ctCiolMMmABCtdTzeZyIp78TePVFJu9WSdtU2qxl24gQBsQLfyGOH4jPNmynwXYmqs72Vq+xaQNNbWwnnateaMaDwk6iw65VlV9zeRMBavufZm1rVPpIJtA6M/SqDmSnwpvhHLd+JbRpzZ8Y1im/5lxHzIz4Laxuf4fIwkYKBXlC/DzSBU9sWHMqXD4WKaPMGkzrZ7f5DqvWD8ldpNKOKUXsSwUuOJKqm2Wku7MbgVU7hClGbzrLHkIUxvAgRdUPg==
x-ms-exchange-antispam-messagedata: PjWEOFopmKtwPQmuOAzOsHL2xaaISWVO0oUBNiZUd21f2fw54UH2Dw/hsEVieuFgvxdvZLQjdEnri1rAPrgA/l7USU73t/+mUwThJS3BVQ8eEd/0MbNfEJ3ijFx4DxEZRZqtRk2wDKhh81siISL6CQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3cb0465b-8262-4beb-b058-08d7e6e07ae6
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 17:13:30.3976 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /+l63W7ddmlB/xD+mAx2I0uMWBSUZA8zkB0qRZC+JHxHBgYBuQvT7cUIbDcMWpa4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2949
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:13:38 -0000


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.


´╗┐On 4/22/20, 8:59 AM, "icnrg on behalf of Ken Calvert" < on behalf of> wrote:

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