[I2nsf] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

Linda Dunbar <linda.dunbar@huawei.com> Thu, 28 March 2019 15:00 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DDA120506; Thu, 28 Mar 2019 08:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 pmWsM0o5f9LX; Thu, 28 Mar 2019 08:00:40 -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 AEA8A1204EB; Thu, 28 Mar 2019 08:00:39 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D20BE382E8C5CAE7E0C7; Thu, 28 Mar 2019 15:00:37 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 28 Mar 2019 15:00:37 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.5]) by SJCEML701-CHM.china.huawei.com ([169.254.3.224]) with mapi id 14.03.0439.000; Thu, 28 Mar 2019 08:00:33 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: idr wg <idr@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Yoav Nir <ynir.ietf@gmail.com>, Roman Danyliw <rdd@cert.org>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
CC: Paul Wouters <paul@nohats.ca>
Thread-Topic: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration
Thread-Index: AdTldVT2DxuuWS8bQw6FDvPhnW1lPw==
Date: Thu, 28 Mar 2019 15:00:33 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B33E27F@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.220.70.227]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B33E27Fsjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/kiBq2Zv_sXKqPEPg-Bxyekkmg-8>
Subject: [I2nsf] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 15:00:50 -0000

Just to reiterate the concerns and issues I raised during IDR Thurs session discussion on using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec).
Copy I2NSF WG because there is similar discussion for over a year.
Copy IPsecme WG as the group has many experts on the IPsec configuration.


1.      I2NSF WG has an on-going discussion on Controller facilitated IPsec configuration which has been discussed for over a year.  Even though the I2NSF's  IPsec Configuration is between Controller and devices, whereas the BGP signaling IPsec Configuration proposed by draft-hujun-idr-bgp-ipsec is between peers, the configuration parameters to the devices are for the same purpose, therefore, should be aligned to avoid future conflicts to the industry.



2.      When using IPsec Tunnel between two peers, usually they are separated by untrusted domain. If Router "A" is allowed to  gets the IPsec tunnel configurations from peers across untrusted domain (instead of the today's practice of from administrators), then many issues come up, for example:



How can a router "A" trust the Traffic Selection policy from a remote peer B? If the router "A" already has its Traffic Selection policy configured for a specific IPsec tunnel, but different from the Traffic Selection policy from remote peer B, which policy should Route A enforce for the IPsec Tunnel?  If the router "A" doesn't have Traffic Selection policy specified, there are two remote nodes B & C signaling the "A" with different Traffic Selection policy, what should A do?



3.      RFC5566 only specifies a simple indication of IPsec Encap, but doesn't do any of the IPsec configuration portion.



As indicated by BESS WG chair, there are multiple drafts addressing IPsec in BESS, IDR, and WGs in Security Area, involved Chairs and ADs may need to agree where is the home for continuing the discussion to avoid future conflicts.


Cheers,
Linda Dunbar