Re: [bess] [Idr] Issue 1: IPSEC related drafts

"Hu, Jun (Nokia - US/Mountain View)" <> Tue, 11 June 2019 11:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BD3412014F; Tue, 11 Jun 2019 04:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ruEeJQ_5wfLD; Tue, 11 Jun 2019 04:03:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E4D4120153; Tue, 11 Jun 2019 04:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xD9h+v5GV7kK8005DmreW+1Vt5ghkowGE/irx6Nyu6g=; b=nvOt5XTKqrvZnZ9pOuvg4NdMIuoilE2s1HuaFsNRI7QU3Opjuh05Rbq743s9S30Tnev5q2ixjeXqHcptmS0J5M4jj1ONZQmWf4bN1WcQbXPkJYAo5HPBIOVDBXGBp1mA3NKTy3tUNcEqQBio9RgFE6o/Nrw2HxxW+3wTd9UJmFg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.10; Tue, 11 Jun 2019 11:03:20 +0000
Received: from ([fe80::a902:6360:1ae0:bc88]) by ([fe80::a902:6360:1ae0:bc88%3]) with mapi id 15.20.1987.010; Tue, 11 Jun 2019 11:03:20 +0000
From: "Hu, Jun (Nokia - US/Mountain View)" <>
To: Linda Dunbar <>, Susan Hares <>, "" <>, "" <>, Yoav Nir <>, Paul Wouters <>
Thread-Topic: [Idr] Issue 1: IPSEC related drafts
Thread-Index: AdUfwKJr7eRm3WKaT1+xQCz89Eo0dwAD2uZAABy2LuA=
Date: Tue, 11 Jun 2019 11:03:20 +0000
Message-ID: <>
References: <01a001d51fc0$b02c41d0$1084c570$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 391fee58-a4e4-499f-9d49-08d6ee5c6a3f
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:AM5PR0701MB2689;
x-ms-traffictypediagnostic: AM5PR0701MB2689:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(346002)(39860400002)(376002)(189003)(199004)(76176011)(7696005)(73956011)(486006)(76116006)(53936002)(110136005)(6306002)(66946007)(316002)(446003)(66556008)(64756008)(66446008)(66476007)(54896002)(68736007)(9686003)(236005)(6436002)(6116002)(790700001)(55016002)(476003)(3846002)(99286004)(11346002)(478600001)(25786009)(14454004)(52536014)(66574012)(53546011)(2501003)(2906002)(2201001)(606006)(86362001)(102836004)(26005)(66066001)(6506007)(5660300002)(229853002)(6246003)(74316002)(14444005)(256004)(186003)(8936002)(7736002)(8676002)(81156014)(81166006)(71200400001)(71190400001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2689;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Rl0Va+cLVAaA2GqRs0w6QIHTZ75u7k+BEySITnW6AJVilaX3um3WNi6GNSSiOFW61kTg/oMnoJczxsah7ajcZWn5BY7z2LfSUuNt8GMuBY7qi9DKmugaSnmabzY4g4yoCExJ+q48cSsi4SlPBaCqCdtk1QBGXWJkpMItgxEdMnaVPhs9JzDHngRp93VUB0GmdRhG+nMUYYbjn8O55URR9w+CFfjo46ZSHAE8MqwSxH9nmMGMY/vEjWYhQSrDWRT7CgZrZ2KfZMzeVCiNETtnD21uv0XPOyI0kHeh4MmruQaTQp7UZa85zlsu1UP/6D9sTYqRrC0l6N5mozHBI588foGIjyqhQuYgE5RCelAUxIHF41lTC3J4mlszJSoFXKhsZVpwQ9ni4NKv9LzoRsUVW4nZN1Ou/OTv1YLGIH47nsQ=
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB235391CF7F5DD5688DCE22A895ED0AM5PR0701MB2353_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 391fee58-a4e4-499f-9d49-08d6ee5c6a3f
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 11:03:20.5660 (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: AM5PR0701MB2689
Archived-At: <>
Subject: Re: [bess] [Idr] Issue 1: IPSEC related drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jun 2019 11:03:29 -0000

As author of draft-hujun-idr-bgp-ipsec-00.txt, I have following comments:

  *   My draft is about extending draft-ietf-idr-tunnel-encaps to cover IPsec tunnels, which is a very generic use case, just like other BGP operations, it could be peer-to-peer or could come from a controller (e.g. program via RR),  we shouldn't have a mechanism that only support controller, again, not every network is  SDN.
  *   IPsec traffic selector could very well be decided locally, not necessary from a single administrator, e.g. router A owns subnet-1, it could decide that a specific IPsec configuration need to be used to reach subnet-1,  or even require different IPsec config for different remote subnet
  *   I won't be able to attend IETF105 on site, but will join remotely

From: BESS <> On Behalf Of Linda Dunbar
Sent: Monday, June 10, 2019 2:26 PM
To: Susan Hares <>;;; Yoav Nir <>; Paul Wouters <>
Subject: Re: [bess] [Idr] Issue 1: IPSEC related drafts

Many thanks to Sue for putting those drafts together.. Very good summary. Adding Yoav to the discussion.

draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 is going through WGLC now.  draft-ietf-i2nsf-sdn-ipsec-flow-protection specifies a way for nodes to receive IPsec policies from Controller(s), whereas draft-hujun-idr-bgp-ipsec-00 specifies a way for  nodes to receive policies from peers that establish tunnels with the nodes.
For most of IPsec VPNs, Traffic Selection policies are coming from administrators, not from peers.

I put some questions to the IDR mailing list on how to address conflicts if the Traffic Selection policies coming from Administrators are different  from Peers (

In addition,  even if the peers can establish tunnels to a specific node, how to validate if those peers are authorized to send IPsec policies to the nodes? This is opening a big security mess.
IMHO, it is much cleaner for a node only to accept IPsec policies from authorized controller(s), instead of peers that need to establish tunnels to the node

We can discuss more in IETF105.


From: Idr <<>> On Behalf Of Susan Hares
Sent: Monday, June 10, 2019 2:14 PM
Subject: [Idr] Issue 1: IPSEC related drafts


At IETF 104, we consider BGP VPNs supporting asking for TLVS in draft-ietf-idr-tunnel-encaps.    After hearing all the discussion, the BESS, IDR and I2RS WG chairs discussed what to do with the following

Drafts considered:

  *   draft-sajassi-bess-secure-evpn-01.txt,
  *   draft-hujun-idr-bgp-ipsec-00.txt,
  *   draft-dunbar-idr-sdwan-port-safi-01.txt
relating drafts/ Supporting drafts:

  *   draft-carrell-ipsecme-controller-ike-00.txt
  *   draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.txt
  *   draft-ietf-idr-tunnel-encaps-12.txt
Basic topologies:
                       Ipsec tunnels
     [rtrA] -------------------- [rtrB]
         |     \                           /      |
         |       \ -- RR1 -------/     | ipsec tunnels
         |    / -----| |------\         |
     [rtrC]------------------- [rtrD]

The decision is that

  *   TLVs mechanisms for new TLVS related draft-ietf-idr-tunnel-encaps should be moved to drafts with just the mechanisms.
     *   All three mechanisms could be included in the TLVs or portions.
     *   The use case and the SA mechanisms can stay in BESS or IDR (depending on what is appropriate).
  *   The RTG Chairs are not experts on Security associations, so that we will try to schedule a unique session at IETF 105 where security experts can help the RTG chairs (BESS, IDR) review the Security association mechanisms.
     *   We'd love to have the second co-chair of I2NSF (Yoav NIR) and someone from IPSECME.
     *   We'll invite IPSEC experts.
     *   We encourage the authors of the 3 drafts to attend this session in IETF 105 and present their security-association mechanisms.
  *   The NLRI/SAFI in draft-dunbar-idr-sdwan-port-safi is unique and can be requested as IDR or ISE draft.
This email has two request:

  *   WG or authors please send any questions to Susan Hares,
  *   The IDR WG is encouraged to discuss requirements or needs in preparation for the TLV selection, and
  *   Please help me secure 2 IPSEC experts to attend this session.

Susan Hares