[sfc] proof-of-transit: continue with both approaches, or choose one?

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Sat, 15 December 2018 20:19 UTC

Return-Path: <fbrockne@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299AF130E46 for <sfc@ietfa.amsl.com>; Sat, 15 Dec 2018 12:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level:
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ledEKZXg6V0H for <sfc@ietfa.amsl.com>; Sat, 15 Dec 2018 12:19:31 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2395F130E44 for <sfc@ietf.org>; Sat, 15 Dec 2018 12:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10573; q=dns/txt; s=iport; t=1544905170; x=1546114770; h=from:to:subject:date:message-id:mime-version; bh=zvA5Uxya7hZ9NXQjYgypsx+ap/x2cZ24poI+7bslECc=; b=l6bzfOV5uQ8GrpYzx0hxEnfzmAUlueOK/Fzp9Ts2fFqW4OxQy+QlJbyV FVUSiGEmAO3WKHvonNs1qBJH6Wy5RXMIExK1vaVmQj9sgK4nNW6iU/aqt XV1SMVnsUAYdkEdxGFJaU4BeQ788MkETVwRTByPwSs5XpyqaAiOmICsDe 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAAAzYRVc/5tdJa1iGwEBAQEDAQEBBwMBAQGBUwQBAQELAYENdmaBAjGYA5QKhVsUgWYLAQEjh1AiNgcNAQMBAQIBAQJtHAELhXBeATVLJgEEG4MbgRxkD6YkhC0BAwIChWYFinyBQheBQD+BEYYwAgOBGYEEhSACjzWRZAkChwuDQIcFIJFSiTyEdosLAhEUgScmDiOBVnAVO4JtgiYXiF6FP0GNKIEfAQE
X-IronPort-AV: E=Sophos;i="5.56,358,1539648000"; d="scan'208,217";a="485584598"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2018 20:19:25 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wBFKJPX4028913 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <sfc@ietf.org>; Sat, 15 Dec 2018 20:19:25 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 15 Dec 2018 14:19:24 -0600
Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1395.000; Sat, 15 Dec 2018 14:19:24 -0600
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: proof-of-transit: continue with both approaches, or choose one?
Thread-Index: AdSUr4tJY6f8O8P3RGmbsA+imZnrVw==
Date: Sat, 15 Dec 2018 20:19:24 +0000
Message-ID: <210af706ed8d4b73aa8c77a24777d622@XCH-RCD-008.cisco.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.117.11]
Content-Type: multipart/alternative; boundary="_000_210af706ed8d4b73aa8c77a24777d622XCHRCD008ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/SLbW7qBiH9FmMp3ek5YbcafQK7A>
Subject: [sfc] proof-of-transit: continue with both approaches, or choose one?
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Dec 2018 20:19:34 -0000

During the SFC WG at IETF 103 in Bangkok we raised the question, whether we could simplify the draft and choose a single algorithm for proof-of-transit only (see also https://datatracker.ietf.org/meeting/103/materials/minutes-103-sfc-01). Given that we could not come to a conclusion, we decided to take the discussion to the list.

Background:
draft-ietf-sfc-proof-of-transit-01 describes two different approaches: "nested encryption" and "Shamir's secret sharing scheme (SSSS)". We documented both approaches in the initial version of the draft, because the two approaches had different qualities: While SSSS was computationally cheaper (each node only needs to perform two additions, a multiplication and a modulo-division), nested-encryption allowed to verify that packets traversed a set of nodes in a particular order ("ordered POT - OPOT") - something that the SSSS-approach in the initial version of the draft did not offer. With the changes discussed in IETF 102 and now documented in draft-ietf-sfc-proof-of-transit-01, both approaches offer order preservation.
In summary, we can now observe the following qualities of the two approaches:

  *   SSSS: Allows verification that a given set of nodes has been traversed in a specific order (POT and OPOT). SSSS without order preservation requires 2 additions, 1 multiplication, 1 division per node participating in POT. Order preservation on top of that requires an additional XOR (or similar).
  *   Nested-encryption: Allows verification that a given set of nodes has been traversed in a specific order (POT and OPOT). The computational effort of nested encryption depends on the crypto algorithm chosen and typically higher than SSSS, i.e. it requires/benefits from hardware with specific capabilities (e.g. AES-NI).

Question:
Given that both approaches both solve the problem of POT and ordered POT, should we consider simplifying the draft and describe only a single approach? If so, which approach should we choose?
I.e. when taking the computational effort into account and the fact that options increase the burden for any implementor, we could decide to only describe the SSSS approach in the draft.

Thoughts? Opinions?

Many thanks, Frank