Re: [Idr] Review of draft-hujun-idr-bgp-ipsec-00
"Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com> Fri, 26 July 2019 02:04 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 8622312024D; Thu, 25 Jul 2019 19:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 gWnHBu5l8y4q; Thu, 25 Jul 2019 19:04:03 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10096.outbound.protection.outlook.com [40.107.1.96]) (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 8D859120223; Thu, 25 Jul 2019 19:04:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mbvAsilpr6vsHigK8Ficz6tqT7scTXFkPgFoRc+WRq8tmKEexPvVs+PxJXvskpN3Mmv/TIQ0IpGr+9AUiR7MiWLX5i8jvNQ70yoZg5mZF5k043/hs6E3r0GoO1qIaEiQ9gtvwOyrHtzc7aUfVLhEafMssMWyz6ATZmdpLdUoS7TinrWEHhcFZDz2afNfLcsg5aK4FUqUnXCC3KYgz5S8/ZSw4K9vWnhLYWb5WVzhH6RyMlauborLloG6fTzEaQYu3a8pWEpymj8TmtfPHJyKpxc8K2p0Y3oAb0DwMxzMgOE0DR1R/IsQV+RpRsV9AmTlps8EtMlqG8bOPq9up8MvCw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O/wCypnW9JTLuUeTnFl1J7iy87FM2haeY1zbL+o50UY=; b=g27ikLGfM/SGvRUVwEzFv53QcZk5gkwg4ATdvlwsi24stb8T7M+NeEjIBTCs3I/go4rs25NaRE+0CH5F7ut17G8DB/tx7fPPn20DLCsXoE5ijhxgSkmf7g5CHYl5fjK9Lt88V6aSzAVBgf59G/IIUxHC9pY3qeyuBVY6vwP6128p6n6V79GMKHeUVXImSXSLcqn3FYlLuM58R60pcxF2frtQ0Woq3ky9+YuZhu7uXJQCxp2z6bxuNLtYboq34HTf4JvVDLfbmEqBAMPO4De4+UmAAiGZqucFiXvDpoTcAzZbk9rt7ZGbSpVHSn8N/1vssdHxwzw6WprqjyLIyYLSww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=nokia.com;dmarc=pass action=none header.from=nokia.com;dkim=pass header.d=nokia.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O/wCypnW9JTLuUeTnFl1J7iy87FM2haeY1zbL+o50UY=; b=SKcH0e96e39kZkaQxrYdEeZKhyMM5ePPaIXvjnvyHWISOyHjyzMTPxzCJEfnZGbMcHDO6g0/qkMYeJO8vEDA4EM/ip6KOYv3O+68R5ZubefoNoWfdjHmrXx7iAESUjXEVrvqn/ykCAHniuQLq9Sy3qmXJ8OIfvmGL69BFes/QrI=
Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com (10.169.150.18) by AM5PR0701MB2625.eurprd07.prod.outlook.com (10.173.92.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Fri, 26 Jul 2019 02:03:59 +0000
Received: from AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::b4b9:a6bd:67a4:95ae]) by AM5PR0701MB2353.eurprd07.prod.outlook.com ([fe80::b4b9:a6bd:67a4:95ae%12]) with mapi id 15.20.2115.005; Fri, 26 Jul 2019 02:03:59 +0000
From: "Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com>
To: Paul Wouters <paul@nohats.ca>, "idr@ietf.org" <idr@ietf.org>
CC: "ipsec@ietf.org WG" <ipsec@ietf.org>
Thread-Topic: [Idr] Review of draft-hujun-idr-bgp-ipsec-00
Thread-Index: AQHVQjYIalbt7l4FGEij89onmXSJIqbcAJ4A
Date: Fri, 26 Jul 2019 02:03:59 +0000
Message-ID: <AM5PR0701MB23534B7DFFD52707F68D896795C00@AM5PR0701MB2353.eurprd07.prod.outlook.com>
References: <alpine.LRH.2.21.1907241129270.29226@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1907241129270.29226@bofh.nohats.ca>
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: [2601:646:8500:5f0:dd04:fb6c:3016:ed3c]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 899da0ee-db08-4965-2b46-08d7116d8625
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM5PR0701MB2625;
x-ms-traffictypediagnostic: AM5PR0701MB2625:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM5PR0701MB262514F7F3DD7A9C3D3ABDE095C00@AM5PR0701MB2625.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01106E96F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(39860400002)(366004)(396003)(136003)(346002)(13464003)(199004)(51914003)(189003)(11346002)(5660300002)(25786009)(478600001)(8676002)(966005)(476003)(53936002)(305945005)(46003)(52536014)(186003)(6306002)(14454004)(7736002)(2501003)(55016002)(9686003)(446003)(68736007)(6246003)(71190400001)(102836004)(229853002)(76176011)(6506007)(6436002)(86362001)(4326008)(74316002)(7696005)(66476007)(66574012)(14444005)(66446008)(66556008)(76116006)(256004)(99286004)(66946007)(33656002)(64756008)(71200400001)(8936002)(19627235002)(2906002)(81156014)(316002)(110136005)(53546011)(81166006)(6116002)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2625; H:AM5PR0701MB2353.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: mGoumThFBA2yULLGnZ037c+Xzab122mIbGLAwCO9/dHUpXxf/fAcYFkzDGRJeGtjnhsLXh69k3eC55O3iUZL2fUWjz70xqsuWrOXH4GL7RcIvQtiCjpNJBdanSUKdSLCixpknvyAW7+Ltr0QUggao8FiQQhJw88jFqjHBL76rythSaMfj5C1jycu1qfZgWyy9wG0BJLQVu7IPdqgy+IzXI8bUsKyjTFsIXpJ+/daXh6Gy7+450tueEb/iJi3ADwFiOA6jmmO85tDJ09u7x26OR5YBKxoAewkBPJyC8DnJNLM36xUQeEXgd9ekPYaA4B8iBqFNWAhltu0w09mMYFpvMr/SfDDYkoiw+T1MN0lW3EEsB23yNy+nIqS1YP6OGGQr4ENcKfUBYpFmRhjEKVyLWfFKePkRkyrOM8If/2yv0k=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 899da0ee-db08-4965-2b46-08d7116d8625
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2019 02:03:59.5125 (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-CrossTenant-userprincipalname: jun.hu@nokia.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2625
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4ZP0a7wMvXbjOyhlA3ozsFyE7tQ>
Subject: Re: [Idr] Review of draft-hujun-idr-bgp-ipsec-00
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: Fri, 26 Jul 2019 02:04:06 -0000
Thanks for the thorough review, My comments in line as [Hu Jun] -----Original Message----- From: Idr <idr-bounces@ietf.org> On Behalf Of Paul Wouters Sent: Wednesday, July 24, 2019 8:39 AM To: idr@ietf.org Cc: ipsec@ietf.org WG <ipsec@ietf.org> Subject: [Idr] Review of draft-hujun-idr-bgp-ipsec-00 Hi, Note that I am an IPsec person and not a routing expert. The document's idea looks fine to me. It is using BGP messages to provision IKEv2 so that IPsec tunnels can be setup to protect packets as best as possible. That's great :) And unlike most proposals the IPsec WG sees, this document does not try to replace IKEv2 with its own smarter Key Exchange protocol, so that's a double plus :) [Hu Jun] indeed, IKEv2 is a field proven mature/secure protocol, there is really no need to re-invent a new way for key exchanging Thanks for reaching out to the ipsec WG, we really appreciate the chance to read drafts that use IPsec to give advise. Below are some of my comments and questions I have: - Configuring large number of tunnels is error prone and not scalable * Only true to some extend * See AutoVPN, DMVPM, NHRP+IKE * Still, this provisioning system seems to fit your eco system. It's as simple as it can be and does not seem to introduce any new complexity or risks. [Hu Jun] All kinds of tunnel mechanism are used in large IP network where BGP is heavily used, that's why ietf-idr-tunnel-encaps introduce a unified mechanism for BGP to signal different type of tunnel config; my draft is just extension of it to support IPsec tunnel; and I intentionally keep the changes to BGP small and no change to IPsec, for easier adaption; - What is "color"? [Hu Jun] "color" is a general term used in routing to represent a set of rules or match criteria; for example color "red" means set-1 of rules, "yellow" means a set-2 of rules; in my draft, color sub-TLV is used to signal a set of IPsec config that are not explicitly signaled by other BGP sub-TLVs (like local/remote traffic selector prefix, public routing instance) ; Following is an example: Color "red" maps to following IPsec config: - certificate auth - trust anchor CA-1 - ike-transform: sha256/aes-gcm-256/DH-Grp 15 - IKE_SA lifetime: 1 day - esp-transform: sha256/aes-gcm-256/Pfs-Grp 15 - CHILD_SA lifetime: 2 hours - ESN: yes - ... etc Color "yellow" maps to following IPsec config: - certificate auth - trust anchor CA-2 - ike-transform: sha128/aes-gcm-128/DH-Grp 15 - IKE_SA lifetime: 1 day - esp-transform: sha128/aes-gcm-128/Pfs-Grp 15 - CHILD_SA lifetime: 2 hours - ESN: No - ... etc - Section 3, step 4: When a router need to forward a packet along a path is determined by a BGP UPDATE which has a tunnel encapsulation attribute that contains one or more IPsec TLV, and router decides use IPsec based on local policy, Required vs Optional IPsec issue. If only one end has "required" and the other end has "optional" then unencrypted packets will be dropped. Seeing IPsec tunnel TLV should probably mean it is mandatory to setup a tunnel? [Hu Jun] A router could include multiple different tunnel type TLV in a BGP update, which means there could be multiple tunnel type options for a given route; and a receiver of such route might chose one of them based on local policy; this behavior is specified in section 5 of draft-ietf-idr-tunnel-encaps It can be done as "optional" but then the IPsec/kernel mechanisms cannot trigger an IKE/IPsec negotiation and this protocol needs to be responsible for not just configuring IKEv2/IPsec but also for bringing up the tunnels when needed. [Hu Jun] yes, if the system decides to use IPsec tunnel to reach a route (based on local policy), it needs to first to check if there is already an existing CHILD_SA it could use, if not, system needs to use IKEv2 to create one - Section 3, step 6: - signaling IPsec configuration Call it IPsec provisioning ? [Hu Jun] I don't have strong opinion on this, provision is also fine to me; - Examples are using less prefered and slower algorithms * Change AES-CBC-256 with SHA-384. to AES-GCM-256 or CHACHA20_POLY1305 * Change NULL-SHA256 to NULL-AES-GMAC [Hu Jun] ok, I will make the change - 1/128 and 2/128 ? For 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), these NLRI has embedded label, which cause the payload packet can't be encapsulated in ESP packet, I don't understand why 1/128 or 2/128 are special ? [Hu Jun] because these routes include a MPLS label, so by default, a router are supposed to add a MPLS label to the payload packet; but IPsec (ESP) only supports IP packet as payload, so label can't be included during ESP encryption/encapsulation; that's why a value 2 of Embedded Label Handling Sub-TLV is used to signal ignoring the MPLS label during ESP processing Open questions: - If the IKEv2 protocol fails, what happens with packets? Release in clear or drop? Is this something the BGP should configure/provision ? If not, it should state which of the two is expected [Hu Jun] This depends if there is any other tunnels (signaled via other tunnel encap TLV in BGP update) could be used; if there is, then use another one based on local policy; if not, then drop the packet as no route available - If a router R1 and R2 have an ipsec tunnel for some traffic, and R1 crashes/reboots, how do things recover? R2 will send packets and might not know something is wrong, unless it is configured for liveness. What happens when R1 comes back up? If all BGP routes are taken away via another mechanism, then I guess R2 would simply delete its tunnel. [Hu Jun] there need to some keepalive mechanism to detect if tunnel is up or not; this is not specific to IPsec, all stateful tunnel need such mechanism; for IPsec, DPD is one option; another faster option would be running BFD over IPsec tunnel; after R2 detects tunnel is down, it has following options: 1. if there is another type of tunnel could use (as described as above), then use that tunnel 2. try re-create the tunnel for a few times, if still can't create the tunnel, use other tunnel if available Such case is also described in section 5 of draft-ietf-idr-tunnel-encaps - Performance: if routes are large (eg 0/128) then very few tunnels would cover lots of routes. In general, having more parallel smaller CHILD SA's outperforms a single or two CHILD SA's by far. This could introduce performance issues. [Hu Jun] agree, and user could freely choose between a few CHILD_SA or many CHILD_SA based on traffic selector sub-TLV BGP signals - Some IPsec options not mentioned could prevent a tunnel from being setup, such as whether to use Extended Sequence Numbers (ESN), or Perfect Forward Secrecry (PFS). Some of these could be locked down in the document (PFS=yes) but things like ESN really depend on the bandwidth of the tunnel. [Hu Jun] as mentioned above, all IPsec config that is not explicit signaled by a sub-TLV, is indirectly signal by color - Maybe some advise on replay-window size would be good. Larger is better but takes more memory. Matters mostly for highspeed links. [Hu Jun] this sound more like a general IPsec optimization suggestion; kind orthogonal to the draft Paul _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] Review of draft-hujun-idr-bgp-ipsec-00 Paul Wouters
- Re: [Idr] Review of draft-hujun-idr-bgp-ipsec-00 Hu, Jun (Nokia - US/Mountain View)