[bess] Roman Danyliw's Discuss on draft-ietf-bess-bgp-sdwan-usage-15: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

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.