From nobody Tue Sep 11 10:57:50 2018 Return-Path: X-Original-To: Sdwan-sec@ietf.org Delivered-To: sdwan-sec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE031310D8; Tue, 11 Sep 2018 09:48:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" Cc: Sdwan-sec@ietf.org, rtgwg@ietf.org, opsawg@ietf.org, ipsecme@ietf.org, i2nsf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <153668448029.16821.1381663396484452180.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 09:48:00 -0700 Archived-At: X-Mailman-Approved-At: Tue, 11 Sep 2018 10:57:50 -0700 Subject: [Sdwan-sec] New Non-WG Mailing List: SDWAN-Sec X-BeenThere: sdwan-sec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Handling IPsec configurations in large scale SD-WAN deployment with constrained resources List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 16:48:06 -0000 A new IETF non-working group email list has been created. List address: sdwan-sec@ietf.org Archive: https://mailarchive.ietf.org/arch/browse/sdwan-sec/ To subscribe: https://www.ietf.org/mailman/listinfo/sdwan-sec Purpose: SDWAN-SEC Mailing Listing is for discussing optimized (and in some sense compromised) mechanisms in securing large scale SD-WAN deployment with constrained resources. Discussing the security risks for special type of IPsec solutions that utilize central controller to simplify some features of IPsec to fit within the common constrains of large number low power nodes managed by controller(s) via secure management channel. For additional information, please contact the list administrators. From nobody Thu Sep 13 16:01:49 2018 Return-Path: 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 To: RTGWG , "sdwan-sec@ietf.org" , IPsecME WG , "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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 23:01:23 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 a= uthentication information, there are people stating it is troublesome of us= ing 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 associ= ated with various simplification of IPsec protocol by utilizing SD-WAN cent= ral controller. The traditional IPsec scheme requires that in a fully meshe= d 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 atta= ched, the edge node has to establish multiple tunnels for tenants. For exam= ple, 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 need= s to communicate with all other nodes. Therefore, simplification facilitate= d 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 enviro= nment. To subscribe:: https://www.ietf.org/mailman/listinfo/sdwan-sec --_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

During the IETF 102 RTGwg discussion of draft-dm-net= 2cloud-gap-analysis on using BGP to carry IPsec configuration (such as Publ= ic 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 diffi= cult 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 disc= ussing the risks associated with various simplification of IPsec protocol b= y utilizing SD-WAN central controller. The traditional IPsec scheme require= s 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 authentica= te the devices, and each node is responsible for maintaining and managing 9= 99 keys. In addition, when an edge node has multiple tenants attached, the edge node has to establish multipl= e tunnels for tenants. For example, for a network with N nodes, a node A ha= s 5 tenants app attached to it, then the node A has to maintain 5*(N-1) num= ber 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 subscr= ibe:: https://www.ietf.org/mailman/listinfo/sdw= an-sec

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F66B1473F5sjceml521mbschi_--