Sue,

Please see my responses below marked with AS>

From: BESS <[email protected]> on behalf of Susan Hares <[email protected]>
Date: Tuesday, July 28, 2020 at 5:43 AM
To: "[email protected]" <[email protected]>
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.

[see section 5.1 of your draft]

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

AS> They are general and not specific to EVPN.

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?

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.

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.

Cheers,
Ali

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

Reply via email to