Re: [icnrg] [EXT] Question on the NIST NDN forwarder

Junxiao Shi <shijunxiao@email.arizona.edu> Wed, 22 April 2020 16:01 UTC

Return-Path: <shijunxiao@email.arizona.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 8AD083A0F9D for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 09:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=email-arizona-edu.20150623.gappssmtp.com
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 3rF7ZTmanwzN for <icnrg@ietfa.amsl.com>; Wed, 22 Apr 2020 09:01:27 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075173A0F9C for <icnrg@irtf.org>; Wed, 22 Apr 2020 09:01:26 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id c3so2415431otp.8 for <icnrg@irtf.org>; Wed, 22 Apr 2020 09:01:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email-arizona-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MPqk1MGKa6b9a0xrluzNagRx8GQi+fDXGRtP1B36Ot8=; b=ieckNRKfW7BcOZ9JPjm/KO3Dgv8yaTK5wrl6yg0nw9lxBKsPmvvQcjMoFgLF/ovqgs zcvHZmEfM/WiIsV71EEzhS8vBixN2k7Kobr1qItbYS0Friwyx6MciflZnGQeSbt1iFpV jFINfhF1yAQBjCU8+6HSq0m5G8ZXsLDe/PEKvwEsDOyfoL3a0gvRjhsh88MAxZ14YZFE 441y8iQbQ5IinkgIAqzgu73h03yG7rJ5CO3eZcxeFmn4ZiSfSbp/QPPdbdDukrFnl4pz PQagP9jzzusVcA7HA8Tsyb+ZNdoxS7CSaxdM+WR/8Py3pVOTnIBww3BiozBOf9Xjg7R6 uibQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MPqk1MGKa6b9a0xrluzNagRx8GQi+fDXGRtP1B36Ot8=; b=r9750vyJg7bgh1hec1EP5D6KR9aTtM6Yq2gWFY0UvvxlRfZPHVMaUXK1K5EwzdRii/ P40BmXHixmfYSzqMCUHT36hQwKxSLfxv6SpW8+RnBmCwsrIHbmk2TBccWzrXRpeQNV6B WEiAORnkiLpoZHHPTeKG50rDLrBMitJ5WFImGalhmyygJEzAvzeV9iVnIeUXYLkYTvgO Vtoz5Xi/INkI1hEZUtqkTH9ioV/7w0qKcgKLlUIGDtriAO4CmJr9TPx5DC1tBjyxUYwE 8oM5zgTYynD7xjW2nL4iyRQNqAmsYBvjVz6KbrW6ZVKcsduj6XOScDiHlW47l/xwx425 hFdw==
X-Gm-Message-State: AGi0PubyJDw3QjRV/vlBSQgfsYUH19pqRPl+cbX4i75TGxl2gTuPaub/ 2V/xexHhOIDqaLVF1w+PEccPGD6/akO+lhckLrf9hSUMo3jah0KZeIy44n9MAV1kizY8wAwb/By a4ZvF194GLcs=
X-Google-Smtp-Source: APiQypKSjiRDqZHn+Uk0WlC+7OhsYKjCb1CgU4EFN5yOhN3YtDxy4lBHIpcI64G+lmai3W/QtXcPj6tbz/W/NoADKzs=
X-Received: by 2002:a9d:67c2:: with SMTP id c2mr16585812otn.227.1587571285141; Wed, 22 Apr 2020 09:01:25 -0700 (PDT)
MIME-Version: 1.0
References: <060E1A5C-4B55-4850-900A-6A29C8596861@orandom.net> <CAOFH+Ob2WnjDueHDftfJJ+_DWyH64gd9An7TDMKrNk8h45EbLg@mail.gmail.com> <9CAE2FCA-658A-4032-BDDE-7326BB1C151F@orandom.net> <CAOFH+OYfnfaNvpWJM7v7PQ=kQgPV8UgxOHukf=U-T4rbBpMCTQ@mail.gmail.com> <ED69CEE8-2079-4F2C-AAFC-832513EC21EF@orandom.net>
In-Reply-To: <ED69CEE8-2079-4F2C-AAFC-832513EC21EF@orandom.net>
From: Junxiao Shi <shijunxiao@email.arizona.edu>
Date: Wed, 22 Apr 2020 12:00:48 -0400
Message-ID: <CAOFH+OYbSyOOFG_geLMQu8Kb8tS2woh253EtHQBezFYAug0Dsw@mail.gmail.com>
To: "David R. Oran" <daveoran@orandom.net>
Cc: "Shi, Junxiao" <junxiao.shi@nist.gov>, ICNRG <icnrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000081dccb05a3e33e5f"
X-ua-ms: gsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/3egOOIao2EEmufRNa04GGHVHQJY>
Subject: Re: [icnrg] [EXT] Question on the NIST NDN forwarder
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 16:01:29 -0000

Hi Dave

> I assume the L2 (or whatever tunneling protocol used) is cryptographically
> protected or of course all hell can break loose by believing crafted
> hop-by-hop PIT tokens.
>
No, L2 is not cryptographically protected.
NDN-DPDK runs over native Ethernet and only supports point-to-point
connections. Each connection is a direct attach cable or a pair of fiber.
If someone runs NDN-DPDK using a tunneling protocol, it's their
responsibility to setup site-to-site VPN with encryption.

NDN-DPDK has protection against "outdated" PIT tokens.
First, PIT entry index portion of the PIT token is not a memory address,
but a 48-bit index number assigned by the PIT-CS Composite Table (PCCT).
PCCT maintains in a hash table of token to entry mappings. If the upstream
sends back a packet with an old PIT token (i.e. PIT entry removed), chances
are, the PIT token would not be found in the hash table.
Second, even if a PIT entry is found by the PIT token, the forwarder MUST
still verify that the Data satisfies the Interest, through name comparison.
The forwarder cannot blindly trust the PIT token without verifying the name.

PIT token cannot solve all cache poisoning problems, but the hazard is no
worse than doing name lookups everywhere.

Yours, Junxiao