Roman Danyliw has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-15: 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: ---------------------------------------------------------------------- ** Section 3.1.5. The BGP UPDATE messages must be sent over the secure channel (TLS, DTLS, etc.) to the RR. Can this text say a bit more on the expectations of secure transport? My understanding was the IPsec was the common practice if confidentiality was desired. Are there pointers for BGP over DTLS? Over TLS? The closest I was able to find was BGP over QUIC per https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/. ** Section 8. 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)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Stephen Farrell for the SECDIR review. ** Section 1. Editorial. s/Corporate HQ/corporate headquarters/. Expand acronym on first use. ** Section 1. - Some traffic can be forwarded by edge nodes, based on their application identifiers What are “application identifiers”? Is an application in this context "HTTP" or "a particular video streaming service provider"? ** Section 2. NSP usually provides more advanced network services, such as MPLS VPN, private leased lines, or managed Secure WAN connections, often within a private, trusted domain. In contrast, an ISP usually provides plain Internet services over public untrusted domains. There is a distinction between made between NSP vs. ISP. I understand the idea of an NSP providing value added services. What I could use help with is understanding what “plain Internet service over public untrusted domains” means. How does an ISP provide services in a domain other than its own? As far as I can tell, there is no subsequent text which relies on this nuanced definition of NSP vs. ISP. ** Section 3.1.4. ... such as the device series number Should this read as “serial number”? ** Section 3.1.4 - Upon power-up, the SD-WAN edge can establish the transport layer secure connection (such as TLS, DTLS) [BCP195] to its controller, whose URL (or IP address) can be preconfigured on the edge device by manufacture default, external USB or secure Email given to the installer. 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 seems like the definition of human-in-the-loop. ** Section 3.1.4 - The SD-WAN Controller authenticates the ZTP request from the remote SD-WAN edge with its configurations. If only a URL is passed per the previous step, how is authentication of the device realized? ** Section 3.1.5 In this circumstance, the property of the SD-WAN edge node cannot be propagated to other nodes that are not authorized to communicate. ... Therefore, SD-WAN deployment needs to have a central point to distribute the properties of an SD-WAN edge node to its authorized peers. -- I got confused here. What is a property? How do properties propagate (or not)? -- What does the SD-WAN distribute? Is it a configuration or some kind of credential? ** Section 3.2 Homogeneous Encrypted SD-WAN has some properties similar to the commonly deployed IPsec VPN, albeit the IPsec VPN is usually point- to-point among a small number of nodes and with heavy manual configuration for IPsec between nodes. In contrast, an SD-WAN network can have many edge nodes and a central controller to manage the configurations on the edge nodes. There is a contrast being made that I don’t understand. If the SD-WAN can manage the configuration of many edge notes, why can’t it manage IPSec VPNs on many edge nodes. Doesn’t Section 4.3 describe IPsec provisioning? Aren’t IPsec VPNs part of what can secure some of the links over commodity internet links? ** Section 3.3 Also, the connection between C-PEs and their Controller (RR) might be via the untrusted public network. It is necessary to encrypt the communication between RR and C-PEs, by TLS, DTLS, etc. -- Is the use of TLS and DTLS are hard requirement? -- Why do other sections say “secure transport (e.g., TLS, DTLS ...)”? ** Section 3.4. Editorial. Throughout this document, this scenario is also called Internet Offload for Private VPN, or PE-based SD-WAN. My crude search suggest that these scenario names are not used in the rest of the document. ** Section 4.2. Editorial. Policies are needed to govern which underlay paths can carry an application flow, as described by Section 8 of MEF70.1 Something got mangled in the document rendering. What is “MEF70.1”? ** Section 4.3 SD-WAN edge nodes must negotiate the supported IPsec encryption algorithms (AES256, AES192, AES128, etc.), the hash algorithm (SHA2 512, SHA2 384, SHA2256, etc.), and the DH groups to establish IPsec tunnels between them. Recommend removing the different algorithm names. At the level of abstraction of this text, it isn't clear that it is necessary to even call which IPsec parameters need to get negotiated. NEW SD-WAN edge nodes must negotiate various cryptographic parameters to establish IPsec tunnels between them. ** Section 4.3. For a BGP-controlled SD-WAN, BGP UPDATE messages can propagate each node's IPsec-related attribute values for peers to choose the common values supported, traditionally done by IPsec IKEv2 [RFC7296]. 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. ** Section 5.1 For an SD-WAN network with a small number of nodes, the traditional hub and spoke model utilizing Next Hop Resolution Protocol (NHRP) or Dynamic Smart VPN (DSVPN)/Dynamic Multipoint VPN (DMVPN) protocol has been found to work reasonably well. -- Please provide a citation to DSVPN and DMVPN? -- What does “work[s] reasonably well” intended to convey? Does it not “work”? ** 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-Encap [RFC9012] Path Attributes as described in the [SECURE-EVPN]. Where in [SECURE-EVPN] is this relevant guidance? Please provide the relevant section in the text. ** Section 8. 2) Potential risk of illegal traffic being injected via the Internet-facing WAN ports. What is “illegal” traffic? What are the issues of legality? Is this perhaps “malicious traffic” or “traffic prohibited by policy”? ** Section 8. The different deployment models also seem to place different levels of trust in the service providers. Consider mentioning these differences. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
