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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 06 February 2019 19:11 UTC

Return-Path: <jmh@joelhalpern.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 DBBA3130F55 for <sfc@ietfa.amsl.com>; Wed, 6 Feb 2019 11:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 1vD7C00qAtIN for <sfc@ietfa.amsl.com>; Wed, 6 Feb 2019 11:11:42 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788BA130FA0 for <sfc@ietf.org>; Wed, 6 Feb 2019 11:11:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43vrf52WvLz1W36f; Wed, 6 Feb 2019 11:11:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1549480301; bh=eNWLRDuOBJ8B/a/Ivc0Q3bNS9ORCaCpukdFyf7uuYgM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BV+N2rtXYA7fkXNC9mOkSIiBYJ3HeZhlT4Ko0sSnUKOSqCnt0gvTM8FXuOsV8HBZ1 K269bKMI3ScZD8uoEEMa+oyHwzZeV/KRccUMqeEgNNX9lB+4ctSvcEsX3vBJZCi8Gu qjur07/ldVJ1TuvmDuMyGExaCxrUAUsex6U4myh4=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43vrf44NCnz1W38d; Wed, 6 Feb 2019 11:11:40 -0800 (PST)
To: "sfc@ietf.org" <sfc@ietf.org>
Cc: "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
References: <132127FF-2EBF-4C72-8BC6-BC5015960B00@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <fc81e365-3dbc-1cac-4984-7d03a4c2b6a6@joelhalpern.com>
Date: Wed, 06 Feb 2019 14:11:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <132127FF-2EBF-4C72-8BC6-BC5015960B00@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/P48YFGPXx0y38uxSWcDJKu6WTY4>
Subject: Re: [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: Wed, 06 Feb 2019 19:11:49 -0000

The working group has not said much.
 From what little we have seen, and from the judgment of the chairs, the 
document editors should make the changes to focus on SSSS.

Thank you,
Joel (& Jim)

On 2/6/19 2:30 AM, Shwetha Bhandari (shwethab) wrote:
> As a co-author and implementor of the SSSS approach, I would also prefer 
> keeping it as the only approach for proof of transit and remove the 
> nested encryption related text.
> 
> Thanks,
> 
> Shwetha
> 
> From: <ao.ting@zte.com.cn>
> To: <jmh@joelhalpern.com>
> Cc: <fbrockne@cisco.com>, <sfc@ietf.org>
> 
> Subject: Re: [sfc] 
> =?utf-8?q?proof-of-transit=3A_continue_with_both_approache?= 
> =?utf-8?q?s=2Cor_choose_one=3F?=
> 
> I agree with Joel. Since SSSS already has mechanism to provide ordered 
> verification requirment, only this one approach is enough.
> 
> Regards.
> 
> 敖婷Ting Ao
> 
> 原始邮件
> 
> 发件人:JoelM.Halpern <jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com&gt>;
> 
> 收件人:Frank Brockners (fbrockne) <fbrockne@cisco.com>;sfc@ietf.org 
> <sfc@ietf.org> <mailto:sfc@ietf.org&gt>;;
> 
> 日期:2018年12月17日04:53
> 
> 主题:Re: [sfc] proof-of-transit: continue with both approaches,or 
> choose one?
> 
> <no hats>
> 
> Personally, the argument for just using SSSS, given that it now can
> 
> provide ordered verification, seems quite persuasive to me.
> 
> Yours,
> 
> Joel
> 
> <hat floating back on slowly>
> 
> On 12/15/18 3:19 PM, Frank Brockners (fbrockne) wrote:
> 
>> 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
> 
>> 
> 
>> 
> 
>> 
> 
>> _______________________________________________
> 
>> sfc mailing list
> 
>> sfc@ietf.org <mailto:sfc@ietf.org>
> 
>> https://www.ietf.org/mailman/listinfo/sfc
> 
>> 
> 
> _______________________________________________
> 
> sfc mailing list
> 
> sfc@ietf.org <mailto:sfc@ietf.org>
> 
> https://www.ietf.org/mailman/listinfo/sfc
> 
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>