[bess] Roman Danyliw's Discuss on draft-ietf-bess-bgp-sdwan-usage-20: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(revised position)

** Section 8.
   In SD-WAN deployments where no secure management channel exists
   between the SD-WAN controller and the SD-WAN edges, TLS or IPsec
   can be established to bridge the gap. While beyond the scope of
   this document, conducting a comprehensive analysis is imperative
   to ensure the security of BGP over TLS [BGP-OVER-TLS].

This text would benefit from further specificity.  My feedback below is very
similar to my original DISCUSS position on -15 of this document.

-- Is the “secure management channel” described here the protocol that carries
the BGP?

-- Assuming it is, what is a “secure management channel” that would allow BGP
to travel over the Internet that isn’t protected by IPsec (i.e., why can’t this
text roughly read, “BGP over IPsec MUST be used”).  When and how should the BGP
communication be secured?  Section 3.1.5 does mentioned that the BGP connection
must be secured (i.e., “As the connection between an SD-WAN edge and its RR can
be over an insecured network, an SD-WAN edge must establish a secure connection
to its designated RR upon power-up. The BGP UPDATE messages must be sent over
the secure channel to the RR.”)

-- The imperative, comprehensive analysis of [BGP-OVER-TLS] is not sufficiently
motivated and the reference to an unadopted individual document is confusing. 
I agree with the recommendation of the SECDIR reviewer to drop [BGP-OVER-TLS]. 
Can the basis for including it be explained?

** (Missed this on my original ballot on -15) The need for “additional
anti-DDoS mechanism” is mentioned in the text in Sections 6.2.2, 6.3.2, 8.  Can
the expected mechanisms please be clarified.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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]