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

["Ali Sajassi (sajassi)" <[e-mail]>]

Sue,


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

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.

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.


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

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.

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.

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

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

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.

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.

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

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:
6<https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-03#section-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-ENCAP>]. 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?

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.

AS>> No interop is needed as explained above.

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’

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