Roman, John Scudder suggested getting your opinion on the changes to be made on draft-ietf-bess-bgp-sdwan-usage-19 about BGP over TCP over TLS.
One key SD-WAN scenario involves expanding the existing VPN network by incorporating additional paths from other networks. In this context, the operator can efficiently utilize their primary management channel, initially designed for VPN control for the BGP to control the SD-WAN. Therefore, there is no strict requirement for BGP over TLS. We plan to remove the mention of BGP over TLS since the draft on BGP over TLS: https://datatracker.ietf.org/doc/draft-wirtgen-bgp-tls/ is not a WG draft yet. We can add the following statement to the Security Considerations: 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] . What do you think? Thank you, Linda _____________________________________________ From: Linda Dunbar Sent: Wednesday, October 4, 2023 12:41 PM To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; matthew.bo...@nokia.com Subject: RE: Roman Danyliw's Discuss on draft-ietf-bess-bgp-sdwan-usage-15: (with DISCUSS and COMMENT) Roman, Thank you very much for the comments and review. Please see the following resolutions to your "Discuss Points" inserted below in BLUE and see if they have addressed your Discussion Points. We will upload Revision 16 to include all the fixes for the issues you have pointed out. Revision 16 also fixes the Boilerplate issue. Linda -----Original Message----- From: Roman Danyliw via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> Sent: Monday, October 2, 2023 9:19 PM To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-bess-bgp-sdwan-us...@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>; matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com> Subject: Roman Danyliw's Discuss on draft-ietf-bess-bgp-sdwan-usage-15: (with DISCUSS and COMMENT) 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ce0f19f33def14d3a436e08dbc3b724c2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638318963621420332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1AqEfT2PETU0DkzNffW46zWGOLKcjuzAS6BFwnfs4oI%3D&reserved=0 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ce0f19f33def14d3a436e08dbc3b724c2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638318963621420332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q4E0YTYBppSon8OP%2FOv8LoIkNlGVJDD9Oh2yxRE67lg%3D&reserved=0 ---------------------------------------------------------------------- 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-retana-idr-bgp-quic%2F&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Ce0f19f33def14d3a436e08dbc3b724c2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638318963621420332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q89zUs37p1neo%2BazZNrPE2i9tdOOXGxpt4mXjHCbg3U%3D&reserved=0. ** 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. [Linda] Fixed in version 16. ** 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"? [Linda] Do you think adding the following statement to this bullet can address your concern? "An "application identifier" in this document refers to one or multiple fields of the IP header of the packets. Using IPv6 [RFC2460] packets as an example, the application identifier can be the Flow Label, the source address, a specific extension header field, or a combination of multiple IP header fields." ** 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. [Linda] You are correct. In the past, Network Service Providers prided themselves on selling backbone connectivity to other organizations. Nowadays, all NSPs also call themselves ISPs. Therefore, I removed the term ISP from the document. ** Section 3.1.4. ... such as the device series number Should this read as "serial number"? [Linda] Yes. Changed in v-16. ** 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. [Linda] You are correct again. The "Zero Touch" means that it is not necessary to dispatch a network engineer to the field to configure the remote device". As stated at the beginning of the paragraph: "SD-WAN zero-touch provisioning (ZTP) allows devices to be configured and provisioned centrally." However, to make it clearer, I add the following note: ""Zero Touch Provisioning (ZTP)" means it no longer needs to dispatch a network engineer to the field to configure the remote devices." ** 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? [Linda] the pre-configuration on the device, external USP or secure Email contains the credential for the remote device to make the connection request. Added a subphrase to the bullet. "- 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) and credential for connection request can be preconfigured on the edge device by the manufacture, external USB or secure Email given to the installer." ** 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? [Linda] As this draft has been discussed in Routing Area, it was assumed that "distribution of edge property" is about distributing the network properties among the SD-WAN edges, such as its WAN port IP addresses, its attached client routes information, . Added the following sentences to the beginning of the paragraph: " For an SD-WAN Edge to establish an IPsec tunnel to another one and announce the attached client routes to each other, both edges need to know each other's network properties, such as the IP addresses of the WAN ports, the edges' loopback address, the attached client routes, the supported encryption methods, etc. " ** 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? [Linda] The intent is to emphasize that the traditional IPsec VPN is usually point-to-point among several nodes without an SD-WAN central controller. This draft demonstrates using BGP to scale the distribution of peer properties for IPsec VPN among many edge nodes. Changed the text to the following: "Homogeneous Encrypted SD-WAN has some properties similar to the commonly deployed IPsec VPN, albeit the traditional IPsec VPN is usually point-to-point among a small number of nodes without an SD-WAN central controller. In contrast, an SD-WAN network can have many edge nodes and a central controller to manage the configurations on the edge nodes". ** 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? [Linda] No, however, TLS/DTLS is lighter weight than creating an IPsec tunnel between C-PEs and their controller (RR) -- Why do other sections say "secure transport (e.g., TLS, DTLS ...)"? [Linda] Secure Transport is the right words. Change the text to the following: "It is necessary to establish secure Transport (e.g., TLS, DTLS) for communication between RR and C-PEs." ** 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. [Linda] Those terms are created by MEF70.1 (MEF SD-WAN Service Attributes and Service Framework). I added the reference. ** 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"? [Linda] MEF70.1 (SD-WAN Service Attributes and Service Framework.) is the specification standardized by MEF . https://www.mef.net/resources/mef-70-1-sd-wan-service-attributes-and-service-framework/ ** 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. [Linda] thank you for the suggestion. Changed. ** 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. [Linda] No, this draft is only to show using the BGP update messages. It doesn't depend on the new TLVs specified by draft-ietf-idr-sdwan-edge-discovery. ** 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? [Linda] Both DSVPN and DMVPN are vendor specific approaches. I was told it is not appropriate to have them in the document during the Area Directors review. This one sentence was missed during the last revision. Thank you very much for pointing out. I have changed the text to the following: "For an SD-WAN network with a few nodes, the traditional hub and spoke model utilizing Next Hop Resolution Protocol (NHRP) or having a hub node (or controller) managing the edge nodes, including local & public addresses and tunnel identifiers mapping, has worked reasonably well." -- What does "work[s] reasonably well" intended to convey? Does it not "work"? [Linda] meaning, the amount of configuration is manageable. ** 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. [Linda] The intent is to say that "More examples are described in the [SECURE-EVPN]." ** 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"? [Linda] You are correct. Changed to your suggested words: ** Section 8. The different deployment models also seem to place different levels of trust in the service providers. Consider mentioning these differences. [Linda] You are correct. Added a third security risk: "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."
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
