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] _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
