Éric Vyncke has entered the following ballot position for draft-ietf-bess-bgp-sdwan-usage-15: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bess-bgp-sdwan-usage-15 Thank you for the work put into this document. It could be useful but, honestly, I find it ***weak*** on several points (see below) and more accurate language will be welcome rather than hand waving. I strongly suggest that the authors/WG have a second pass on the document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Matthew Bocci for the shepherd's detailed write-up including the WG consensus ***and*** the justification of the intended status. Please note that Bernie Volz is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/reviewrequest/18155/ I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Mixing IPsec SA and IPsec-protected tunnels I am afraid that the text often mixes "IPsec SA" and "IPsec-protected tunnels" (the latter could be VXLAN/GRE/IPinIP tunnels). ## Absence of QUIC Suggest to also add QUIC as a secure channel in addition to TLS. ## Abstract Unsure about the usefulness of the last paragraph. Isn't "SW-WAN overlay" an pleonasm ? I.e., are there SD-WAN without an overlay ? ## Section 1 `based on their application identifiers instead of destination IP addresses` what are those "application identifiers" ? ## Section 2 Should "PE-based VPN" be defined on its own ? `plain Internet services` what are those services ? I guess mainly "IP packet forwarding", but this should be qualified. Please explain what "ZTP" is. ## Section 3.1.1 Which part of the inner header is relevant to `the IPsec tunnel's inner encapsulation header can have the SD-WAN VPN Identifier to distinguish the packets belonging to different SD-WAN VPNs.` ? ## Section 3.1.2 What are `L3VPN service requirements` ? Please expand "HR" as it is not part of https://www.rfc-editor.org/materials/abbrev.expansion.txt ## Section 3.1.5 Even of a SD-WAN edge does not receive a BGP UPDATE for a specific prefix, a manual static route could still forward traffic to this prefix. Should this security issue be mentioned ? ## Section 3.2 Please add a reference to "NVo3". "Homogeneous" also seems to indicate that all IPsec SAs use the same security parameters (crypto alg, key length, ...). Is it mandatory for this document ? If not, then suggest to use "ubiquitous encrypted SD-WAN". ## Section 3.3 Unsure whether I agree with `it is more desirable for traffic over a private VPN to be forwarded without encryption.`. ## Section 5.1 The first paragraph mentions DMVPN/DSVPN that appears to be marketing terms from some vendors. Are those terms required ? ## Sections 5.2, 5.3, ... Rather than using legacy IPv4 addresses, IPv6 examples would be more suitable in 2023. ## Section 5.4 If 192.0.2.9/30 is assumed to be a prefix, then it is *NOT* as it is part of 192.0.2.8/30. ## Section 6 does it belong to a BGP document ? I fail to see how the whole section 6 is part of a BGP document. It is nice to read but what is the link with BGP ? ## Section 6.1.1 `six one-directional IPsec SAs must be established:` but then only 3 are show, suggest to either do not list the bidirectional arrows or use unidirectional arrows. ## Section 6.1.2 What is "inner encapsulation key" in `Different client traffic can be differentiated by a unique value in the inner encapsulation key or ID field` ? Why are loopback addresses used here ? I would have assumed that for a public edge CPE, it would be the address of the public interface. Neither IPv6 nor IPv4 headers have a header field "Protocol-code". Please use the right term. The use of 'protected' for IPsec tunnel is ambiguous (at first read, I read it as *very secure/confidential*) in `C-PE Node-based IPsec tunnel is inherently protected`. E.g., in section 6.2 'protected' is used with a different semantic. Is it really Figure 2 from pages before ? I would expect that VXLAN/GRE encapsulation would cope better with multicast traffic. Would RFC 3740 and 6407 be useful for mcast traffic ? ## Section 6.2 (and other places) The usual term is 'clear text' rather than 'native'. ## Section 6.2.2 Please describe or add a reference for `additional anti-DDoS mechanism`. Figure 8 probably misses a link between A3 and PE. ## Section 6.3 Unsure whether the NAT part is useful, again what has this to do with BGP ? And/or how can a BGP session traverse a NAT ? What is `Scenario #2` ? ## Section 8 I would have expected some security consideration about the centralization of security in the RR. ## Section 11 It is inconsistent with the authors' list in the header. # NITS ## Section 1 s/IP Packets/IP packets/ A couple of places where "Tunnel" should rather be "tunnel". _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
