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

[Susan Hares <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, July 28, 2020 9:45 AM
To: Susan Hares; [e-mail]
Subject: Re: [bess] Why are you specifying two new tunnel types for encapsulation for EVPN?

 

Sue,

 

Please see my responses below marked with AS> 

 

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

 


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 [ <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.

 

 

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? 

 

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.

 

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 

 

   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> ].

 

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. 

 

 

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

 

AS> They are general and not specific to EVPN. 

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

Then, this work belongs in IDR.  

 

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 

 

AS> What is the question wrt this draft?

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

Therefore, this work should take place in IDR.  

 

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?

 

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. 

 

 

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.

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

 

On #d) policy is normal for all IPsec 

 

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. 

Sue2> We are aligned on the policy. 

 

Cheers,

Ali

 

Thank you, Sue