Subject: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

From: "Susan Hares" <[email-masked]>
Date: Tue, 28 Jul 2020 08:42:51 -0400

Ali: 

>From draft-sajassi-bess-secure-evpn: 

 <https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-6> 6
BGP Encoding

    This document defines two new Tunnel Types along with its associated
   sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP
<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-EN
CAP> ]. These
   tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as
   described in section 4
<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-4> .
The following sub-TLVs apply to both tunnel
   types unless stated otherwise.

1.  Why are you specifying 2 new tunnel types?  What makes these special? 

What in the use of the tunnel encapsulation draft 

does not support for the inner and outer tunnel requires 

you to specify a ESP-Transport and  ESP-in-UDP-Transport? 

[see section 5.1 of your draft] 

2.  What IPSEC security information is unique to the EVPN solution that is
not general? 

Section 4 of  draft-sajassi-bess-secure-evpn-03.txt 

describes the IPSEC DIM and security policies on in the following case:

a) you need to send IPSEC information - via RR mesh 

b) you have policies that you want to use  the
[draft-carrell-ipsecme-controller-ike-00.txt]

c) you want on demand re-keying 

d) "policy" - undefined

on #a) there are multiple BGP IPsec proposal using the RR mesh 

on #b) can you tell me what is unique about
[draft-carrell-ipsecme-controller-ike-00.txt] 

on #c) isn't on-demand re-keying a desire to prevent DDOS that is a good
feature for all IPsec? 

On #d) policy is normal for all IPsec 

Thank you, Sue

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 28 Jul 2020 13:44:42 +0000

Sue,

Please see my responses below marked with AS>

From: BESS <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Tuesday, July 28, 2020 at 5:43 AM
To: "[email-masked]" <[email-masked]>
Subject: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

Ali:
From draft-sajassi-bess-secure-evpn:
6<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-6> BGP Encoding

   sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-ENCAP>]. These

   described in section 4<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-4>. The following sub-TLVs apply to both tunnel

AS> We need to differentiate between underlay tunnel and overlay encap. For example, in PMSI tunnel attribute, tunnel type can be PIM-SM or PIM-SSM; whereas, overlay encap can be VxLAN, NVGRE, GENVE, etc. So, similarly here, the underlay tunnel can be ESP-Transport or ESP-in-UDP-Transport and the overlay can be any of the overlay encap. If you think the existing tunnel-encap can address both underlay and overlay, please indicate how.

2.  What IPSEC security information is unique to the EVPN solution that is not general?

AS> They are general and not specific to EVPN.

a) you need to send IPSEC information – via RR mesh
b) you have policies that you want to use  the [draft-carrell-ipsecme-controller-ike-00.txt]
c) you want on demand re-keying
d) “policy” – undefined
on #a) there are multiple BGP IPsec proposal using the RR mesh

AS> What is the question wrt this draft?

on #b) can you tell me what is unique about [draft-carrell-ipsecme-controller-ike-00.txt]

AS> Again what is the specific question wrt this draft? What section/line of this draft is not clear?

on #c) isn’t on-demand re-keying a desire to prevent DDOS that is a good feature for all IPsec?

AS> Yes, re-keying is a requirement.

AS> You can have min. set with no SA policy, you can have a single SA policy, or you can have a SA policy list.

Cheers,
Ali

Thank you, Sue

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 28 Jul 2020 11:11:14 -0400

Ali: 

Three major high points from the discussion: 

1) tunnel-encap and RFC6512 lack a clearly defined interoperability statement 

    If you are using RFC6512 PMSI tunnel attribute and Tunnel-encap attribute, this issue needs to be sorted out. 

2)  If your draft depends on draft-carrell-ipsecme-controller-ike-00.txt, 

     then the review at IETF 105 by security experts had concerns which have not been resolved. 

    (Also draft-carrell-ipsecme-controller-ike-01.txt has expired and there is not a replacement.) 

If your draft depends on general features of rekeying, nonces, security association databases, and security policy data bases, then I suggest revising the draft to point to existing features.  

3) [IDR-Shepherd-hat on]  A general solution for IPsec security association passing is wise 

All of this points toward the creation of a general IPSEC functionality in BGP rather than EVPN specific work.    If it is true, then we ought to create one solution in IDR for the 3 scenarios. 

See my comments as Sue2>.  I use the following abbreviations 

tunnel-encaps -  draft-ietf-idr-tunnel-encaps-17.txt 

sajassi-s-evpn – draft-sajasssi-bess-secure-evpn-03.txt 

RFC6514 – PMSI Tunnel Attribute (PMSI) 

Cheerily, Sue 

From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Tuesday, July 28, 2020 9:45 AM
To: Susan Hares; [email-masked]
Subject: Re: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

Sue,

>From draft-sajassi-bess-secure-evpn: 

 <https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-6> 6 BGP Encoding

    This document defines two new Tunnel Types along with its associated
   sub-TLVs for The Tunnel Encapsulation Attribute [ <https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-ENCAP> TUNNEL-ENCAP]. These
   tunnel types correspond to ESP-Transport and ESP-in-UDP-Transport as
   described in  <https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-4> section 4. The following sub-TLVs apply to both tunnel
   types unless stated otherwise.

What in the use of the tunnel encapsulation draft does not support for the inner and outer tunnel requires you to specify a ESP-Transport and  ESP-in-UDP-Transport? 

Sue2> One of my main concerns is the interoperability between tunnel-encaps and extensions to RFC6514. 

tunnel-encaps  provides both outer encapsulation [see section 3.3] and inner encapsulation [see section 3.2].  The only overlay thing in sajassi-s-evpn which tunnel-encaps  which cannot be supported is GENVE.   

Reviewers of tunnel-encaps have requested why GENVE was not included.  IDR requires 2 implementation of the code.  If sajassi-s-evpn has an implementation with GENVE, then tunnel-encaps should include it in the base tunnel-encaps draft.

I do not see a PIM-SM or PIM-SSM tunnel type in the following IANA table: 

 <https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types> https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types’

I suspect you were meaning the tunnel type in PMSI tunnel attribute from RFC6514.  

Sajassi-s-evpn states in Section 6 

   sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP <https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-ENCAP> ].

Is sajassi-s-evpn defining the tunnel types from tunnel-encaps or PMSI Tunnel types?

Your IANA section does not specify a definition from: 

P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types, but  an extended community.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn

And in section 6. 1

   When such encapsulation is used,

   for BGP signaling, the Tunnel Type of Tunnel Encapsulation TLV is set

   to ESP-Transport and the Tunnel Type of Encapsulation Extended

   Community is set to NVO encapsulation type (e.g., VxLAN, GENEVE, GPE,

   etc.). This implies that the customer packets are first encapsulated

   using NVO encapsulation type and then it is further encapsulated &

   encrypted using ESP-Transport mode.

Which attribute are you setting the tunnel encapsulation type in?  tunnel-encaps or PMSI tunnel attribute?

What NVO encapsulation types are you specifying? 

What we lack is a clear definition of the interoperability between tunnel-encaps and RFC6514 in your draft.  If you have another draft you are relying on to provide this interoperability between 2 BGP attributes, please let me know. 

Sue2> Then we should have one draft that passes this information that works for all BGP cases. 

Then, this work belongs in IDR.  

d) “policy” – undefined

Sue2> You answered the question above – nothing is special to sajassi-s-evpn due to IPsec

Therefore, this work should take place in IDR.  

Sue2> What are the key features of [draft-carrell-ipsecme-controller-ike-00.txt] that sajassi-s-evpn depends on? 

I was trying to be polite – so let me be blunt.  This draft has expired and it is not in the discussions for IPSECME.  

The Security folks had concerns about [draft-carrell-ipsecme-controller-ike-00.txt] asked you at 105.

They asked why you are not using existing IPsec distribution techniques. 

The I2NSF WG has WG draft on SDN based IPsec Flow Protection (draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt)

and RFC8329 comments on interface to security functions.   IMHO it does not seem to align with this 2 drafts, but I am not a security expert. 

You are specifying another draft which the security folks had serious concerns regarding and is not a WG Draft.  It seems to specify the keying, the nonce mechanisms, the security policy data base, the security associations, and policy distribution.  The draft reports to have looked at I2NSF and network controllers, but the IETF 105 review questioned both. 

So .. If your draft depends on draft-carrell-ipsecme-controller-ike-00.txt – I have grave concerns. 

What are the key elements you need from draft-carrell-ipsecme-controller-ike-00.txt?

Can these be provided from existing IPSEC mechanisms. 

Sue2> Good, then inserting this in BGP should be an IDR function. 

Sue2> We are aligned on the policy. 

Cheers,

Ali

Thank you, Sue

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 31 Jul 2020 02:42:42 +0000

Sue,

From: Susan Hares <[email-masked]>
Date: Tuesday, July 28, 2020 at 8:11 AM
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

Ali:

AS>  Secure-evpn draft doesn’t use RFC6512 PMSI tunnel attribute. It only uses Tunnel-encap. I was just providing an example wrt underlay tunnel type vs. overlay encap.

AS> Secure-evpn relies on rekeying from draft-carrell-ipsecme-controller-ike-00.txt. If there is a better proposal for rekeying, then I am all ears. We’ll take care of the expired status of that draft shortly.

AS> secure-evpn draft does reference to carrell controller-ike draft regarding those features (e.g., section 4.4 for rekeying, section, 4.5 for ipsec databases).

AS> That’s what is described here – i.e., a general solution that applies to EVPN and other type of VPNs because it uses an attribute that can be passed with any NLRI.

AS> As I said before, the solution applies to EVPN as well as other VPN types. That’s why I have a section that explain how other VPN solution can be beneficiary of the same solution. BTW, because we are talking about signaling for BGP Enable Services, this draft and any other related drafts in this area belong to BESS. Of course, IDR will be involved as always.

Cheers,
Ali

Cheerily, Sue

Sue,

Ali:

AS>> No interop is needed as explained above.

I do not see a PIM-SM or PIM-SSM tunnel type in the following IANA table:
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types’

   This document defines two new Tunnel Types along with its associated
   sub-TLVs for The Tunnel Encapsulation Attribute [TUNNEL-ENCAP<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#ref-TUNNEL-ENCAP>].

And in section 6. 1

Cheers,
Ali

Thank you, Sue