BGP Usage for SD-WAN Overlay Networks
draft-ietf-bess-bgp-sdwan-usage-22

## COMMENT

### What’s a “client route”?

The document talks about "client routes", "client route updates", etc. It never defines the concept. I assume that these are analogous to a CE route in an RFC 4364 VPN, but the casual usage and lack of definition are unhelpful.

### MP-NRLI

There’s no such thing as "MP–NLRI". I guess you mean MP_REACH_NLRI and MP_UNREACH_NLRI. If you want to collectively refer to these as "MP-NLRI" then I think you need to add a definition.

### Anti-DDoS

Section 6.2.2 has

                                                     For all packets
     from the Internet-facing WAN ports, the additional anti-DDoS
     mechanism has to be enabled to prevent potential attacks from
     the Internet-facing ports.
     
What anti-DDoS mechanism is that? None is specified here, nor referenced.

### Figure 7

Figure 7 is mangled to the point of being unreadable.

Thank you to Stephen Farrell for the SECDIR review.

I support the DISCUSS position of John Scudder.

** Section 2.  Editorial. If Section 3.2. defines “Homogeneous Encrypted SD-WAN” and the term isn’t used prior to that. Consider if this needs the definition.

** Section 2.
   SD-WAN IPsec SA: IPsec Security Association between two WAN ports
               of the SD-WAN nodes or between two SD-WAN nodes.

Is it “two SD-WAN nodes” or “two SD-WAN edge nodes”?  If the former, what is an “SD-WAN” node that isn’t an edge node?

** Section 3.1.2.  This sections seems to suggest that various MEF 70.1 behavior needs to be supported.  This suggests that [MEF70.1] needs to be a normative reference.

** Section 3.1.3.  Editorial.
   SD-WAN Traffic Segmentation enables the separation of the traffic
   based on the business and the security needs of different user
   groups and/or application requirements. Each user group and/or
   application may need different isolated topologies and/or policies
   to fulfill the business requirements.

Isn’t a security need also a need of the business?  Otherwise, the second sentence should read “… to fulfill the business and security requirements”.

** Section 3.1.3.  Editorial.
   The traffic from the PoS application follows a tree topology
   (denoted as "----" in the figure below), whereas other traffic can
   follow a multipoint-to-multipoint topology (denoted as "===").

In the figure, where is the PoS application, in one of the “Site #”?  Is there an assumption that traffic “flows up” from the sites to the payment gateway?  Where is the a “---” link from the “====”-connected “multi-point connection for non-payment traffic”?

** Section 3.1.4
     - Upon power-up, the SD-WAN edge can establish the transport
     layer secure connection [BCP195] to its controller, whose URL
     (or IP address) and credential for connection request can be
     preconfigured on the edge device by the manufacture, external
     USB or secure Email given to the installer.

Same feedback as provided on the ballot of the -15 version of this document:
Can the last two configuration options be clarified.

-- per “external USB”. Do you mean a USB _drive_ of some kind that is plugged in and the edge device knows to read what ever is on the drive to configure itself?  Does this mean anyone with physical access to the USB plug can power cycle the machine and can reconfigure it?

--  per “secure email”, does this mean that the installer configures the device based on something typed in?  What’s “secure” about the email?

Neither of these mechanisms seem like "Zero Touch".  They seem like the definition of human-in-the-loop.

** Section 3.1.4.  My understanding of Section 3.1.* was that it was series of requirements to be fulfilled by using BGP with SDWAN.  Per Zero Touch Provisioning, in what way is BGP involved in this provisioning? I’m not sure how this section fits into the scope of the document.

** Section 3.2
   -  A small branch office connecting to its HQ offices via the
   Internet. All traffic to/from this small branch office must be
   encrypted, usually achieved by IPsec Tunnels [RFC6071].

   -  A store in a shopping mall may need to securely connect to its
   applications in one or more Cloud DCs via the Internet. A common
   way of achieving this is to establish IPsec SAs to the Cloud DC
   gateway to carry the sensitive data to/from the store.

What is the technical difference between an “IPsec Tunnel” per the branch office use case and a “IPsec SA” in the store in the mall use case?

** Section 4.3
   In the context of a BGP-
   controlled SD-WAN, BGP UPDATE messages can disseminate IPsec-
   related attribute values for each node

Per the ballot on -15 of this draft, I asked “Please provide a reference to the specification which provides guidance on the BGP TLVs to provision IPsec.  Is that draft-ietf-idr-sdwan-edge-discovery?  This should be a normative reference.”  I still believe additional clarity is required.

** Section 5.2.
   In the figure below, the BGP UPDATE message from C-PE2 to RR can
   have the client routes encoded in the MP-NLRI Path Attribute and
   the IPsec Tunnel associated information encoded in the Tunnel-
   Encapsulation [RFC9012] Attributes.

Per https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml, is that value=25

** [SECURE-EVPN] is referenced a few times in the course of the draft.  Is the WG confident that this expired draft is appropriate to use?

 
** Section 8.
   Adding an Internet-facing WAN port to a C-PE can introduce the
   following security risks:

   1) Potential DDoS attacks from the Internet-facing ports.

   2) Potential risk of malicious traffic being injected via the
   Internet-facing WAN ports.

   3) For the Differential Encrypted SD-WAN deployment model, there
   is a risk of unauthorized traffic injected into the Internet-
   facing WAN ports being leaked to the L2/L3 VPN networks.

   Therefore, the additional anti-DDoS mechanism must be enabled on
   all Internet-facing ports to prevent potential attacks from those
   ports.

I’m having trouble understanding what is considered in-scope for these Security Considerations.  I was under the impression that the focus was the use of BGP as the control plane for SD-WAN communication.  Does it also include the “tunnels”/links configured by the SD-WAN via BGP.

-- If the security properties of tunnels/links configured by the SD-WAN BGP are in scope, then a reminder that links transiting non-Internet links are subject to security properties negotiated in the SLAs of that provided.

Specifically, on -15 of this document, I previously balloted “** Section 8.  The different deployment models also seem to place different levels of trust in the service providers.  Consider mentioning these differences.”

-- Likely because I don’t understand the definition of “Internet-facing ports” in the this context, I don’t see a difference between risk (2) and (3).  (2) seems like a more general version of (3).

-- What is the relationship between “anti-DDoS mechanism” and risk (2) of malicious traffic being injected?  Malicious traffic injection isn’t necessarily a DDoS.

-- I observe that there are no inherited Security Considerations from IPsec or BGP mentioned here.  

Per the ballot on -15 of the document, “This document seems to build on a number of other technologies.  Do their security considerations not apply (e.g., BGP, whatever ZTP technologies is chosen)?”, this feedback still applies.


** Section 10.1  Please provide the appropriate citation for [BCP195]