[bess] Éric Vyncke's No Objection on draft-ietf-bess-bgp-sdwan-usage-15: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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".