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

"Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com> Mon, 01 April 2019 22:21 UTC

Return-Path: <jun.hu@nokia.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A72D120021; Mon, 1 Apr 2019 15:21:40 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 IbcLDhlel36w; Mon, 1 Apr 2019 15:21:36 -0700 (PDT)
Received: from FRA01-MR2-obe.outbound.protection.outlook.com (mail-eopbgr90092.outbound.protection.outlook.com [40.107.9.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B34120003; Mon, 1 Apr 2019 15:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pBTeGyNsSsTTjQdO3pjv57kGcOqX6C7yGm1tvwZ2aEo=; b=SKgAa48akebqkCIRPwWa0qlM8qWDPyaD3oINpwOBWOyy50/FGqGKflw9x5BqWGV/A9cdq6tkVgIngTQYgY5K1D3JC/UeMN8ED9Yf7VwYIQoURxKhsKMvLmoF4Pgd37PoYQdwipBRrI15Cz1bqFFYogmBv2LHz10Ln7S/wY7AEgc=
Received: from PR1PR07MB5755.eurprd07.prod.outlook.com (20.177.210.161) by PR1PR07MB5002.eurprd07.prod.outlook.com (20.177.208.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.11; Mon, 1 Apr 2019 22:21:32 +0000
Received: from PR1PR07MB5755.eurprd07.prod.outlook.com ([fe80::e93e:b63:6eab:e49b]) by PR1PR07MB5755.eurprd07.prod.outlook.com ([fe80::e93e:b63:6eab:e49b%3]) with mapi id 15.20.1771.006; Mon, 1 Apr 2019 22:21:32 +0000
From: "Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com>
To: Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>, Linda Dunbar <linda.dunbar@huawei.com>
CC: Roman Danyliw <rdd@cert.org>, idr wg <idr@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, Gabriel López Millán <gabilm@um.es>, Yoav Nir <ynir.ietf@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, Rafa Marin Lopez <rafa@um.es>, Paul Wouters <paul@nohats.ca>
Thread-Topic: [IPsec] 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: AQHU6NcIKJcFgzifZke8IG/CKYX43qYn3nTg
Date: Mon, 01 Apr 2019 22:21:31 +0000
Message-ID: <PR1PR07MB5755052B214EA1243DF2A7EE95550@PR1PR07MB5755.eurprd07.prod.outlook.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B33E27F@sjceml521-mbs.china.huawei.com> <CAB=gXc6aZ2D1K_q3MjVJMEYxEykJO_oxhoSkOEyytOOaa=_ouA@mail.gmail.com>
In-Reply-To: <CAB=gXc6aZ2D1K_q3MjVJMEYxEykJO_oxhoSkOEyytOOaa=_ouA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jun.hu@nokia.com;
x-originating-ip: [4.16.40.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 28544dd0-0834-4d90-ff30-08d6b6f064e8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:PR1PR07MB5002;
x-ms-traffictypediagnostic: PR1PR07MB5002:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <PR1PR07MB50020E16872070AE8D8E0E2495550@PR1PR07MB5002.eurprd07.prod.outlook.com>
x-forefront-prvs: 0994F5E0C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(346002)(39860400002)(366004)(136003)(396003)(199004)(189003)(7696005)(53936002)(966005)(71190400001)(25786009)(71200400001)(102836004)(68736007)(33656002)(2906002)(81156014)(81166006)(86362001)(99286004)(66574012)(236005)(14444005)(606006)(9686003)(54906003)(5070765005)(316002)(4326008)(14454004)(110136005)(6246003)(256004)(478600001)(486006)(6306002)(7416002)(476003)(54896002)(11346002)(7736002)(229853002)(105586002)(6436002)(446003)(5660300002)(106356001)(8676002)(55016002)(76176011)(74316002)(66066001)(790700001)(6116002)(3846002)(52536014)(8936002)(186003)(26005)(53546011)(97736004)(6506007)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5002; H:PR1PR07MB5755.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: NfoLW88Ny92EgFZjIMpnZk+ZXL7oMX3jILrAGysYDP/CNmTTADapjBW0LbCgiSNXKPmYLRCw57F5YLJWfu2V+AP8VCbPkWnf1Z7q2U6GycJfk1+juDkwq2G1TPE0luJYYvMOKTVfcYme86P9QyVwwKz8urYQXhp4FsNZZruCD20COF1H5lSv2Ccdey/1I4WA14/ir4T6ThGghipdEc/4rHcqT4kt1GJqHAnqWVNm+eR5eAg3NhqnGcwXyV4lhi/ujxycmRr7Ecxrdr8//e75gEkZ+xmWM+vX8sY5LCJHBaqsOHqvj99tTwEtFScIumvoFdW1fmCrT07SpC5ESXMccd92a2L1s40xujFByMEQH/YpqIs+u9sfIshHE+hH1e3MPSZiN/yVlo5DANVXxqpdyRGBE/nr8Y+jcUjDQnDiwk8=
Content-Type: multipart/alternative; boundary="_000_PR1PR07MB5755052B214EA1243DF2A7EE95550PR1PR07MB5755eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 28544dd0-0834-4d90-ff30-08d6b6f064e8
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 22:21:31.8789 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5002
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/c6qC1zHae44hEz5S2JFRh_5ca3k>
X-Mailman-Approved-At: Tue, 02 Apr 2019 01:58:01 -0700
Subject: Re: [Idr] [IPsec] 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: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 22:21:40 -0000

Again, Linda, as discussed with you multiple times, my draft is really about extending current draft-ietf-idr-tunnel-encaps<https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/> to cover IPsec tunnel and other encryption tunnel like DTLS in next revsion (based on the feedback I got from Prague);
My draft is not intended to address SDN for IPsec use case and it does not require a central controller, and there are use cases where a central controller is not needed or can’t be used, my draft is intended for those cases;

So I really don’t see any conflict here

From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Fernando Pere?íguez García
Sent: Monday, April 1, 2019 3:05 PM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Roman Danyliw <rdd@cert.org>; idr wg <idr@ietf.org>; stephane.litkowski@orange.com; i2nsf@ietf.org; idr-chairs@ietf.org; Gabriel López Millán <gabilm@um.es>; Yoav Nir <ynir.ietf@gmail.com>; Alvaro Retana <aretana.ietf@gmail.com>; ipsec@ietf.org WG <ipsec@ietf.org>; Benjamin Kaduk <kaduk@mit.edu>; Rafa Marin Lopez <rafa@um.es>; Paul Wouters <paul@nohats.ca>
Subject: Re: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

Hi Linda,

We have revised draft-hujun-idr-bgp-ipsec and, to the best of our understanding, we do not see any conflict with our draft being discussed in I2NSF. The IPsec attributes configured through BGP are only the peer’s tunnel address and local/remote subnet prefixes (that are used for the traffic selectors).  The rest of the IPsec configuration (AH/ESP, cryptographic algorithms, keys, etc.) are obtained via a “color mapping”, which is something not covered by the draft since it assumes routers are somehow pre-provisioned with this information.

Thus, we do not see this draft is also facing the task of formalizing the complete configuration of an IPsec device. We appreciate any clarification in case we are wrong.

Best regards,
Fernando..

El jue., 28 mar. 2019 a las 16:01, Linda Dunbar (<linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com>>) escribió:

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
_______________________________________________
IPsec mailing list
IPsec@ietf.org<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec


--
----------------------------------------------------------------------------------------------------
Fernando Pereñíguez García, PhD
Department of Sciences and Informatics
University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT
C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax: +34 968 189 970
------------------------------------------------------------------------------------------------------