[Idr] SECURE-EVPN's IPsec SA Inheritance can be improved by the mechanism described by draft-dunbar-idr-sdwan-edge-discovery. Would you consider?

[Linda Dunbar <[e-mail]>]

Ali,  et al:

Your draft-sajassi-bess-secure-evpn-03 (the Section 4.1 Inheritance of Security Policies)  has very stringent mapping  for the SA Inheritance  or “Recursive resolution” :
“In the event, there are no security TLVs associated with an EVPN route, there is a strict order in the manner security associations are inherited for such a route.  … If such [IPsec ] TLVs are missing with the associated route, then one checks to see if the subnets the IPs
are associated with has security TLVs with the EVPN IMET route. If they are present, those associations are used in securing the
traffic. In the absence of them, the peer security associations are used.”

Here are some issues with this stringent mapping:


  *   There could be multiple IPsec Security Associations between two Peers, as shown in the figure below, where the Purple SA terminate at the peer nodes, the  Blue & Red SAs terminate at the  WAN ports, and there could be more SAs that are terminated at the client specific routes.  A user might have the policy to allow its Client route 10.1.1.x to be carried by either MPLS Path or the RED  IPsec SA.


[cid:image003.png@01D66F3C.C5D28F40]



https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/ [BGP-Edge-Discovery] proposes client routes UPDATEs only include the IPsec SA identifiers (ID) to reference the IPsec SA attributes being advertised by separate Underlay Property BGP UPDATE messages.



By referencing IPsec SA ID, instead of the detailed IPsec attributes Sub-TLVs, not only it makes the client routes UPDATE more compact (just an additional  4 bytes ID field), it also enables more flexible SA Inheritance, allowing client routes to be inherited by specific IPsec SA IDs. If a client route can be carried  by more than one IPsec SAs or mixed IPsec & MPLS path, simply include multiple IPSec IDs, as shown in the following figure:





[cid:image004.png@01D66F3C.C5D28F40]





The [BGP-Edge-Discovery] differs from your [SECURE-EVPN] in how the information is included in the client routes. Your [Secure-EVPN] attaches all the IPsec SA information to the actual client routes, whereas the [BGP-Edge-Discovery] only includes the IPsec SA IDs for the client routes.

The IPsec SA IDs used by [BGP-Edge-Discovery] is pointing to the IPsec SA Information which are advertised separately.



[BGP-Edge-DISCOVERY] proposes underlay tunnel topology information and IPsec SA attributes are  advertised  in a separate BGP UPDATE with  NLRI having an SAFI=74 (SDWAN SAFI) and a Tunnel Encapsulation attribute with tunnel type being SDWAN-Underlay.



We think that reference IPsec SA ID is more efficient for SECURE-EVPN. Sincerely hope you consider our proposed approach.



Thank you

Linda Dunbar


From: Ali Sajassi (sajassi) <[e-mail]>
Sent: Monday, July 27, 2020 10:17 PM
To: Susan Hares <[e-mail]>; 'Hu, Jun (Nokia - US/Mountain View)' <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; 'Alvaro Retana' <[e-mail]>; [e-mail]; Ayan Banerjee (ayabaner) <[e-mail]>
Subject: Re: Drafts related to IPSec Tunnels - My follow upon IETF 105 - is an Analysis draft

Hi Sue,

We are planning in progressing secure-evpn draft.

Regarding scale issues, there is an assumption in your draft that is not accurate and we discussed it in idr & rtgwg mailing lists June of last year. More specifically the assumption of sending tunnel attribute with client routes. Unless you need to setup a separate IPsec tunnel per client route, you SHOULD NOT send the tunnel attribute with the client routes. Instead, one of the inheritance schemes should be used for client routes. As I discussed in the idr/rtgwg mailing list in June/2019, there are three ways to do such inheritance and they are:

  1.  Recursive resolution
  2.  Coloring
  3.  Hierarchical

The first two are described in tunnel-encap and the last one is described in secure-evpn. If it helps, I can add a section to secure-evpn to describe all three of them in one place.

Regards,
Ali

From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 14, 2020 at 5:40 PM
To: "'Hu, Jun (Nokia - US/Mountain View)'" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, 'Alvaro Retana' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Drafts related to IPSec Tunnels - My follow upon IETF 105 - is an Analysis draft
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, July 14, 2020 at 5:40 PM

Greetings:

I’m looking to pick up on our work from IETF 105
on drafts that suggest new Sub-TLVs for the
BGP tunnel encapsulation attribute.

If you are interested in continuing your work and getting approval
for your Sub-TLVs to be added to the list of approved Sub-TLVs
for the BGP tunnel encapsulation attribute,
please let me know.

The BGP tunnel encapsulation draft is now at -16.txt
after receiving Alvaro’s AD review.   We’re about to go
through a final round of  discussion on the IDR list, and I’d like to
make sure your proposed new Sub-TLVs fit with
draft-ietf-idr-tunnel-encaps-16.

If you do not wish to continue your work,
I want to thank you again for your hard work at IETF 105.
I felt each of the proposed solutions brought new valuable
concepts to passing tunnels in formation for IPsec in
BGP.

Cheerily, Sue


Details on the help I need
================================
After reviewing all the drafts at IETF 105 and seeing subsequent
changes to drafts to address security issues, I have
the impression that each draft had a targeted use case
and a particular profile for security, privacy, being managed in a network,
and scaling.   I’ve written up my impressions in
an analysis draft using use cases, and I’ve uploaded a part
of this draft for public viewing.

Before I upload the remainder of the analysis,  I would like
to chat with each author group and/or all authors together.
I want to make sure my analysis is correct.

The remaining part of the analysis looks at BGP Update scaling
for UPDATE sizes for two scenarios.
Scenario 1 is a small RR cluster (5 client routers)).
Scenario 2 is a huge RR cluster (10K client routers).

As far as I can tell, all 3 proposals can handle the
small RR cluster scenario.

The huge RR cluster scenario look far into the future to 5G/6G world
that might use this technology.   With 64K BGP messages
and 10G links for RR clusters, the huge RR cluster
is “doable” today on massive machines that do not forward traffic.

If being a co-author helps you work on this analysis draft,
please let me know.