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 protected]]
Sent: Tuesday, July 28, 2020 9:45 AM
To: Susan Hares; [email protected]
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 <[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:
<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
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
