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

Linda Dunbar <> Mon, 10 June 2019 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 316DB120108; Mon, 10 Jun 2019 14:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 18OpCyJS5WxM; Mon, 10 Jun 2019 14:26:26 -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 6F8C1120089; Mon, 10 Jun 2019 14:26:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Uix9ZxgOOy8zHpm3iKBwvxL5ivI1qr5mcTsTABcQYCc=; b=sMOrdu3d387zxlPS9vZizC59jR4aIifiNlBkBOcTLUs0F7XVI03UVI5PifVuBZMgZjLszwc4WuSx48r1VqIxux+YMPAeIqET5Y3LuWS8uMxwQsRfou4cbX6I8SIDi5hczxQfF0St4qHv/QIEiODQl/3h1wZuKg5nenie1rlZ03M=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.9; Mon, 10 Jun 2019 21:26:24 +0000
Received: from ([fe80::b5e8:95cb:5d8e:9397]) by ([fe80::b5e8:95cb:5d8e:9397%7]) with mapi id 15.20.1987.010; Mon, 10 Jun 2019 21:26:24 +0000
From: Linda Dunbar <>
To: Susan Hares <>, "" <>, "" <>, Yoav Nir <>, Paul Wouters <>
Thread-Topic: [Idr] Issue 1: IPSEC related drafts
Thread-Index: AdUfwKJr7eRm3WKaT1+xQCz89Eo0dwAD2uZA
Date: Mon, 10 Jun 2019 21:26:24 +0000
Message-ID: <>
References: <01a001d51fc0$b02c41d0$1084c570$>
In-Reply-To: <01a001d51fc0$b02c41d0$1084c570$>
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: 65d902d1-4caf-4fe8-375e-08d6edea4a78
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR13MB3360;
x-ms-traffictypediagnostic: MN2PR13MB3360:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0064B3273C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(376002)(39850400004)(396003)(189003)(199004)(53546011)(86362001)(52536014)(2501003)(110136005)(256004)(7736002)(74316002)(316002)(76116006)(8936002)(2201001)(66946007)(6246003)(14444005)(6506007)(229853002)(6306002)(54896002)(9686003)(55016002)(71200400001)(73956011)(486006)(236005)(446003)(71190400001)(8676002)(476003)(11346002)(81166006)(81156014)(14454004)(102836004)(68736007)(508600001)(186003)(6116002)(790700001)(3846002)(606006)(25786009)(26005)(33656002)(7696005)(99286004)(64756008)(66446008)(6436002)(66556008)(53936002)(66476007)(76176011)(5660300002)(66066001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB3360;; 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: R4nCHNSZNc7RrNqo7vUezocSAQiVcisV/nRMZgLML2z3ZugsX65UWi3yskNxcMDY/dJXvr/SzYxcwbcTwdz9BTxhbsA2pkKIm1qgQwl5NKiBxN0unmkExhJs288g9ac6SsY+c5xVhhVsy3zCPR8/scI7Dp5SCBFfzQpdcNxkDiEG8jSdpzXt2PZXP1BekYv87fuJlIbjPPPwzqmwW9OoleStzX015o+sxvR6uviUv//jjtCjsw5M4mdyndKaZGn/oJn2TgQmUYxY3OGFo/TsElWbwQ/w+7eDASiXVpHFUrxX7D4sqaLYi15v5ftj1NET7t8kNINqFu5xvknTgHzkDKmrsdEuWkZExSRUJujeYTN6qMpXK0n9diLGBprmhcw+77G13qaQ9/ycx3Vg2Thmj2ton4NoCXAZRfSyNgVBmsE=
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3582C79ACE494B5E3EF572B5A9130MN2PR13MB3582namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 65d902d1-4caf-4fe8-375e-08d6edea4a78
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2019 21:26:24.5217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3360
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: Mon, 10 Jun 2019 21:26:29 -0000

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