Re: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

"Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com> Thu, 09 April 2020 17:26 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 AFBBE3A0CB0 for <idr@ietfa.amsl.com>; Thu, 9 Apr 2020 10:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level:
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 9aYyl9h9i6jb for <idr@ietfa.amsl.com>; Thu, 9 Apr 2020 10:26:20 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20722.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8a::722]) (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 0F8EF3A0CB6 for <idr@ietf.org>; Thu, 9 Apr 2020 10:26:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LE6rXSAKOG1UybUM3R/fnGP+xec3LOblFiH9rXq869xwkKxx0zPi5iQ2rT6xFlpNB4JSHC4drpZjRVQV25WDABe2vcqfXP+mxv6eiZDFb5nYtL69ol/wVomkgLqbHYQcLTFHU2VgIEJNT5IkQaGVPBHgEIt0M7b8oc7P+ID5TZInQY9v30+p7H+4v5q1Xqlr59ciGw71hJydfj0d0NCLJua8eEUqjDUxHV97qkKWWp+SxDqfPVoxLMQ5H/xsCP972VouIJnL0vp2vNKbhhPTODZikhRPhymksXsnR85Tls4S3Y4g4qH6lk7s43br65lubQ4spqqiwzYEhtAjURn9FA==
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=0MbUqMXLT01YFZQ08irfK4lud4BfdHrG0axah8bh9H4=; b=gY0cukpDvXqhRhoVcHgf4jn+xb/RgYqy8Bphush1f2yNpmj/19qJAijr3IXXiIU9D8B6Abb/4ZSTNlUsCpt4Ko75vWhDIUUq3nk/hjzuGzpsXiBpcp5omFXLGxa+fkbV7iBoOmreboamoRiaPZIpR00elh+GAnBsHt7Q1Og5yL7tIgsuubK+EcHP50W33fGgedOsl0dSnKSBF/JCFQ72XymeI77cX9ck1mayFB/J6GFsiLSsgLWt9vhjKaceXtb7vH2hf/c1QeK7ECZlvbIoAvsNyHrX8Zg7ZinwOLTRRkq2mVtlWN89sxztdjnMCxq29q+5+edf+LcSXgicz6Hj8Q==
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=0MbUqMXLT01YFZQ08irfK4lud4BfdHrG0axah8bh9H4=; b=rQ9VxJfFaGjlnfR5uPtq+ABDJcoVE+iTPDUkV4I7AJMKX8ejm3F9HhzQTDK6OBY9M+asRnAAfzWMDCGN6QaXY5Pn4f2B+L/aW0dcctCfGMyskjefQxbdNjDuVch8gl2CgNAWzWml8dac5c8gGfoeYHNu83IIjl611pv5kP+UbkE=
Received: from BY5PR08MB6312.namprd08.prod.outlook.com (2603:10b6:a03:1f0::19) by BY5PR08MB6375.namprd08.prod.outlook.com (2603:10b6:a03:1e7::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Thu, 9 Apr 2020 17:26:17 +0000
Received: from BY5PR08MB6312.namprd08.prod.outlook.com ([fe80::a078:d4f7:d478:a679]) by BY5PR08MB6312.namprd08.prod.outlook.com ([fe80::a078:d4f7:d478:a679%7]) with mapi id 15.20.2878.021; Thu, 9 Apr 2020 17:26:17 +0000
From: "Hu, Jun (Nokia - US/Mountain View)" <jun.hu@nokia.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, Susan Hares <shares@ndzh.com>, 'IDR List' <idr@ietf.org>
Thread-Topic: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020
Thread-Index: AdYJ88Fzwt+5o6y3SbatjJfErRQpEwEDTVmwACNf6YAAADZZwA==
Date: Thu, 9 Apr 2020 17:26:17 +0000
Message-ID: <BY5PR08MB6312EA69C769DD993CFC88B695C10@BY5PR08MB6312.namprd08.prod.outlook.com>
References: <MWHPR1301MB2096467F12809CB1041B467E85C70@MWHPR1301MB2096.namprd13.prod.outlook.com> <BY5PR08MB6312D69C2994387B0F31109B95C10@BY5PR08MB6312.namprd08.prod.outlook.com> <MWHPR1301MB20968DD059BB7F59D6FFD31D85C10@MWHPR1301MB2096.namprd13.prod.outlook.com>
In-Reply-To: <MWHPR1301MB20968DD059BB7F59D6FFD31D85C10@MWHPR1301MB2096.namprd13.prod.outlook.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: [135.245.20.15]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1c5b16fd-1f73-4eac-0be7-08d7dcab1cd5
x-ms-traffictypediagnostic: BY5PR08MB6375:
x-microsoft-antispam-prvs: <BY5PR08MB6375FF73076CAD9D123E148D95C10@BY5PR08MB6375.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0368E78B5B
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR08MB6312.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(136003)(346002)(376002)(366004)(396003)(39860400002)(66446008)(7696005)(76116006)(66556008)(81156014)(53546011)(52536014)(5660300002)(26005)(66946007)(81166007)(8936002)(64756008)(71200400001)(6506007)(66476007)(8676002)(9686003)(33656002)(86362001)(966005)(478600001)(316002)(110136005)(66574012)(2906002)(55016002)(186003); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3GXuQ6Jm0OV5lJakam6ykpM55XFnGkhD65Gf3Xi7AETxl+qygYYP4xpXfuNoDuurV8Es4w5/a/XXNmNB+2B4FzFsoQD3LXG4CvRzaISvYBYKutRF75ObYhvXiE5P+J44c4hBknChpLzp+I6+y2SaWwgunm+dGozJXp2ugR2iPUrkQyBlGV5eKscviklm/rFgVDq2LnGHLRfXbD4Us/m2IQe8L3nWrF7lo/8wfjAM5gz0kKSORFv6F98tiAN6xvnoq5alcafkOcA/5RJj6gdpcBC/Yd/RjrAizD4a1dXVWjLiWTabgJdm/2IVLxLYC9aWGwoMewtBXNxIAQ0agm4cB7btfnr2c2NQ9Aq5oIKiHFCPaf8oFzJtDoI2SyszSgYX1yNcCdHeU6wVPJ9//OnY9TYe3DQNQ2c3i8Gw/bDkdHqGaO84lfbIJVvMq6nnHhcNrQnmlK1z4K3tyc/Y2SVh2Mfv8fF1Q+6IPIz4AzesRq2Vg/hPIfRqjJWlaEfxG7fwO0hKTmE8z0uPsusKKqHwUg==
x-ms-exchange-antispam-messagedata: wPjCWSI9KE/jsrVUZYuIf+Y+E0IgfeNtONdRmB7e9rkvitmI6RG3pV68gJoKdxK/pYczV9GZpzeuRZ7gsYXb4v7sBBoBLr5RYi7hWrTtzpc0b0sj7zB2Z30hTVDegMuk/SjILJ9Pkb7mbjdrrPEzeQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR08MB6312EA69C769DD993CFC88B695C10BY5PR08MB6312namp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c5b16fd-1f73-4eac-0be7-08d7dcab1cd5
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 17:26:17.6421 (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: NuRuOYoVaAiEhz2qG49r184mhthNRpQqW3gwWLnn7O1X+4KLHH5CqUW67pkBorCZLOi1+dG3xDXcTePY0pJJDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR08MB6375
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kve0BU1nai_f62IUqY8nG7n7_bg>
Subject: Re: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020
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: Thu, 09 Apr 2020 17:26:24 -0000

Pls see my comments in line

From: Linda Dunbar <linda.dunbar@futurewei.com>
Sent: Thursday, April 9, 2020 9:47 AM
To: Hu, Jun (Nokia - US/Mountain View) <jun.hu@nokia.com>om>; Susan Hares <shares@ndzh.com>om>; 'IDR List' <idr@ietf.org>
Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

Jun,

your Section 2.3 IPsec Configuration Tag Sub-TLV has  Certificate trust-anchor: CA-1 and Certificate trust-anchor: CA-2

Why need two Trust Anchors (CA-1 & CA-2)?
[Hu Jun] this is just an example to show IPsec configuration tag could be mapped to different configs; for example, lets say you have two subnets belongs to two type of services, each has different trust-anchor;
What are expected actions for a node receiving this information?  If the receiver has different trust anchor, should the receiver do more validation?

[Hu Jun] the IPsec configuration tag represents a set of IPsec configuration for receiver to use for creating the IPsec tunnel; for example router B received a BGP update for subnet S, which contains an IPsec config tag value T1, and T1 is mapping to a set of IPsec config include trust-anchor CA-1,  B then need to use a certificate issued by CA-1 as its credential for IPsec tunnel authentication
What are the expected actions for receiver upon receiving the  local/remote Traffic selector protocol, local/remote Traffic selector port range?
[Hu Jun] same as above, these are all required Ipse config that receiver need to use for creating IPsec tunnel to reach the subnet S

For your example, what if the subnet S behind A only needs to be encrypted to B, but not to C because A<->C has VPN connected. What should C do with the received IPsec UPDATE? For a network with hundreds of nodes, what do they do with the received UPDATE?

a simple case, where there are 3 routers: A , B and C, A has subnet S behind it that require IPsec protection, if B or C need to forward a packet to S, it must be over an IPsec tunnel;
[Hu Jun] if IPsec only need between A and B, then assume subnet behind B is S2, then in the ipsec tunnel TLV of tunnel-encap attr of BGP update for S, A could include a Remote Prefix sub-TLV as S2, this means this Ipsec tunnel requirement is only required between subnet S <-> S2;

Thank you,

Linda Dunbar

From: Hu, Jun (Nokia - US/Mountain View) <jun.hu@nokia.com<mailto:jun.hu@nokia.com>>
Sent: Wednesday, April 8, 2020 7:13 PM
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>; Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; 'IDR List' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: RE: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

Sorry for replying late, Pls see my answer in line

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Linda Dunbar
Sent: Friday, April 3, 2020 1:24 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; 'IDR List' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: [Idr] Question about draft-hujun-idr-bgp-ipsec-02 ( was RE: 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

Jun,

Need a few clarify questions for your draft.


  1.  Does  draft-hujun-idr-bgp-ipsec-02 assume that IKEv2 still running between IPsec peers?
[Hu Jun] yes


  1.  Does receiving the IPsec BGP UPDATE triggers a node to start the  IKEv2 with the speaker without any configuration from the administer? If Node B can only establish IPsec IKEv2 with another node C, does it matter if the Node B receives or not receives the BGP update from the C?
[Hu Jun] it is up to the implementation, there are two options:

           *   create the tunnel upon receiving BGP update
           *   create tunnel only when router need to forward a packet to a destination that need to be reached via IPsec tunnel
either way works

  1.  How does the BGP UPDATE ease the IPsec configuration? Does  it ease the configuration on the BGP UPDATE speaker? Or does it ease the configuration of the receiver?
[Hu Jun] think of a simple case, where there are 3 routers: A , B and C, A has subnet S behind it that require IPsec protection, if B or C need to forward a packet to S, it must be over an IPsec tunnel; so traditionally, you would configure two tunnels on A: A->B and A->C, then you would also need to configure a tunnel B->A on B and a tunnel C->A on C, so in total, there are 4x tunnel configuration on 3 routers; but now with my draft, you just need to configure A to advertise a BGP update for S which include ipsec config, there is no per-tunnel configuration on A, B or C.

  1.  How to differentiate  Public Routing Instances?
If the payload packet within the IPsec tunnel are simple IP forwarding, is there still "Private Routing Instances"?
[Hu Jun] the concept of public and private routing instance is to separate trust network from un-trusted network; Typically, for security reason, you want to separate trusted network from un-trusted network by using different routing instance,  for example, internet is un-trusted network, while an enterprise intranet is trusted network, they are different routing instance;  then an payload packet from the intranet is encapsulated into an IPsec tunnel, the result ESP tunnel packet is forwarded via internet.
But public routing instance could same as private routing instance if you have good reason to do so, there is nothing in protocol level prevent that
On Page 3, the draft states that only "Local Tunnel Endpoint address, Public Routing Instance and CHILD SA traffic selector address range" are advertised by the BGP.
Is the Local Tunnel Endpoint address same as the LOOPBACK address of the node? Or can be a specific Ingress or egress port of the node sending out the BGP UPDATE?
[Hu Jun] this total up to the operator, both loopback or a physical interface address could be used, but typically a loopback address is prefer for stable reason

Thank you very much.

Linda Dunbar

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: Monday, March 30, 2020 7:07 AM
To: 'IDR List' <idr@ietf.org<mailto:idr@ietf.org>>
Subject: [Idr] 2 Week WG adoption call draft-hujun-idr-bgp-ipsec-02.txt and draft-hujun-idr-bgp-ipsec-transport-mode-00 (3/30 to 4/13/2020

This begins a 2 week WG adoption call for  two drafts BGP provisioned IPSEC infrastructure

1) draft-hujun-idr-bgp-ipsec-02.txt:
BGP Provisioned IPSEC Tunnel Configuration

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C867befd7c8f14a9f2b9708d7dc1ac510%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637219879863935674&sdata=SwzXzkVYOO80URTGX2HtZip%2Fm%2B03GqA1mNcQSuUPwWs%3D&reserved=0>

2) draft-hujun-idr-bgp-ipsec-transport-mode-00.txt:
BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration

https://datatracker.ietf.org/doc/draft-hujun-idr-bgp-ipsec-transport-mode/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hujun-idr-bgp-ipsec-transport-mode%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C867befd7c8f14a9f2b9708d7dc1ac510%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637219879863945672&sdata=KUP1Cd05vEX6ZfJlzbA8gROpgktmvT1WeWS2ifaAA%2Bw%3D&reserved=0>

These drafts were presented at IETF 104 and IETF 105..
At IETF 105, there was a detailed discussion on the security issues.
After IETF 105, the author modified his draft to take care of the
Issues mentioned.

Discussion during the WG Adoption should examine:
1) Has this draft addressed the necessary security issues to
    be adopted as IDR WG draft?

2) Is this useful generic IPSEC functionality for networks?

   The EVPN related to IPSEC continues in BESS.
   This draft is considered here as a general feature.

3) Are there any deployments of this draft?


Stay safe and healthy... Sue