[Sdwan-sec] Issues of draft-dm-net2cloud-gap-analysis using BGP to carry IPsec configuration (such as Public key, etc) and Peer authentication information

Linda Dunbar <linda.dunbar@huawei.com> Thu, 13 September 2018 23:01 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: sdwan-sec@ietfa.amsl.com
Delivered-To: sdwan-sec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CEB130E91; Thu, 13 Sep 2018 16:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Nmbw9XmMWm3z; Thu, 13 Sep 2018 16:01:19 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1F56E12008A; Thu, 13 Sep 2018 16:01:19 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 851E82471B21E; Fri, 14 Sep 2018 00:01:13 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 14 Sep 2018 00:01:15 +0100
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.77]) by SJCEML701-CHM.china.huawei.com ([169.254.3.36]) with mapi id 14.03.0415.000; Thu, 13 Sep 2018 16:01:10 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: RTGWG <rtgwg@ietf.org>, "sdwan-sec@ietf.org" <sdwan-sec@ietf.org>, IPsecME WG <ipsec@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Issues of draft-dm-net2cloud-gap-analysis using BGP to carry IPsec configuration (such as Public key, etc) and Peer authentication information
Thread-Index: AdRLtFx4qME4Sg99T4W5aAeVt14v2w==
Date: Thu, 13 Sep 2018 23:01:09 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B1473F5@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.218.180.231]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/sdwan-sec/2NbOq7V4P9VFXR3uyoe99SzAWqc>
Subject: [Sdwan-sec] Issues of draft-dm-net2cloud-gap-analysis using BGP to carry IPsec configuration (such as Public key, etc) and Peer authentication information
X-BeenThere: sdwan-sec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Handling IPsec configurations in large scale SD-WAN deployment with constrained resources <sdwan-sec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sdwan-sec>, <mailto:sdwan-sec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sdwan-sec/>
List-Post: <mailto:sdwan-sec@ietf.org>
List-Help: <mailto:sdwan-sec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sdwan-sec>, <mailto:sdwan-sec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2018 23:01:23 -0000

During the IETF 102 RTGwg discussion of draft-dm-net2cloud-gap-analysis on using BGP to carry IPsec configuration (such as Public key, etc) and Peer authentication information, there are people stating it is troublesome of using BGP to carry IPsec configuration & authentication request because it is difficult for a BGP node to guarantee not forwarding the BGP advertisement (even if the update is marked as Not Forward).

Can someone elaborate why?

Thanks, Linda Dunbar

P.s. a new mailing list has been created to for discussing the risks associated with various simplification of IPsec protocol by utilizing SD-WAN central controller. The traditional IPsec scheme requires that in a fully meshed network, each device has to manage n2 key exchanges and (n-1) keys. As an example, in a 1,000-node network, 1,000,000 key exchanges are required to authenticate the devices, and each node is responsible for maintaining and managing 999 keys. In addition, when an edge node has multiple tenants attached, the edge node has to establish multiple tunnels for tenants. For example, for a network with N nodes, a node A has 5 tenants app attached to it, then the node A has to maintain 5*(N-1) number of keys if each tenant needs to communicate with all other nodes. Therefore, simplification facilitated by SD-WAN controller is needed for large scale deployment. However, it is necessary identify the associated risks, so that the industry can make the informed decision on risks that can be tolerated for their specific environment.

To subscribe:: https://www.ietf.org/mailman/listinfo/sdwan-sec