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 <[email protected]> On Behalf Of Linda Dunbar
Sent: Monday, June 10, 2019 2:26 PM
To: Susan Hares <[email protected]>; [email protected]; [email protected]; Yoav Nir 
<[email protected]>; Paul Wouters <[email protected]>
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 
(https://mailarchive.ietf.org/arch/msg/idr/N9cwGW5d5AD15wFaF1ncR7fqLsI).

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.

Linda

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

Greetings:

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

_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to