Alvaro, Thanks for the call explaining the main issue.
We can update the Section 2 in the definition of “Controller” to the following: “Controller: Used interchangeably with SD-WAN controller to denote the logical system that manages the SD-WAN overlay network. In the context of BGP-controlled SD-WAN, one function of the SD-WAN controller is to provide BGP-based route propagation, i.e., the Route Reflector (RR) function. This RR function may be collocated with or embedded within the SD-WAN controller but represents only one component of the overall SD-WAN controller.” See below resolution after [Linda3]. Thank you Linda From: Alvaro Retana <[email protected]> Sent: Wednesday, December 10, 2025 2:26 AM To: Linda Dunbar <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: RtgDir Early review of draft-ietf-bess-bgp-sdwan-usage-28 On December 9, 2025 at 10:40:05 PM, Linda Dunbar wrote: ... > > > “SD-WAN further depends on standard BGP security mechanisms, including > > > the use of secure transport (e.g., TLS or IPsec) for BGP sessions and > > > strict RR policy enforcement. Deployments that bypass protected channels > > > risk exposing SD-WAN edge properties or allowing unauthorized nodes to > > > inject or receive routes. Likewise, incorrect RR policies can result in > > > unintended distribution of client routes or tunnel attributes. These > > > risks arise from deployment choices rather than the mechanisms described > > > in this document, and operators must ensure that secure transport and > > > proper RR configuration are consistently applied.” > > > > I see you have more suggestions later on in §8. In general, including this > > text and what you propose in later, you should point at the existing > > security considerations of the protocols you're using. Many of the risks > > that exist are, as you mention, not specific to this document, but ones > > that exist in BGP already -- again, support that claim by referencing the > > existing security considerations in published RFCs. > > > > One big nit about the text above: "SD-WAN further depends on standard BGP > > security mechanisms, including the use of secure transport (e.g., TLS or > > IPsec) for BGP sessions..." The only standard session-level mechanism is > > TCP-AO, which is not used in this case, so that statement opens the door > > to questions about the existing mechanisms... > > [Linda2] How about changing the paragraph to the following? > > “SD-WAN operation relies on the existing security mechanisms defined for BGP > and IPsec. In particular, protection of BGP sessions may use the TCP > Authentication Option (TCP-AO) as specified in RFC 5925, and the security > considerations of BGP, TCP-AO, and IPsec apply directly. Many of the risks > described here—including route injection, session disruption, or unintended > route distribution—are therefore inherent to those protocols rather than > specific to this SD-WAN usage. Operators must follow the existing security > guidance in the referenced RFCs and ensure correct RR policy configuration > and session protection” Don't talk about TCP-AO; you don't mention it anywhere else in the document. While it is ok to use it when using TLS/IPSec, you don't need to add more just because it exists, and the combined use is also not specific to this document. [Linda3] The primary operational difference between SD-WAN deployments and traditional BGP-based VPNs is that SD-WAN edge nodes often include Internet-facing WAN ports, which introduce additional security, filtering, and policy requirements not present in classic MPLS-based VPN deployments. For Section 8 second paragraph, how about changing to the following (removing the TCP-AO, etc): “SD-WAN operation relies on the existing security mechanisms and security considerations defined for BGP and IPsec, which therefore apply directly to the control and tunnel planes described in this document. The primary operational difference between SD-WAN deployments and traditional BGP-based VPNs is that SD-WAN edge nodes often include Internet-facing WAN ports, which introduce additional security, filtering, and policy-enforcement requirements not present in classic MPLS-based VPN environments. These untrusted interfaces increase exposure to spoofed traffic, denial-of-service attacks, and unintended route learning if misconfigured. As a result, operators must apply strict validation of control-plane information received from Internet-facing ports, ensure correct RR policy configuration, and provide appropriate protection for both control-plane and data-plane exchanges, consistent with the security guidance in the referenced RFCs.” Beyond mentioning the "referenced RFCs", be explicit in this section which ones they are. Note, for example, that rfc4271 is not referenced, but the text does mention "the security considerations of BGP". The vulnerabilities are documented in rfc4272...
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
