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

[Linda Dunbar <[e-mail]>]

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 <[e-mail]>
Sent: Monday, October 2, 2023 9:19 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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."