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

[Linda Dunbar <[e-mail]>]

Roman,

Thank you very much for the comments.
See below detailed relies.

Linda

-----Original Message-----
From: Roman Danyliw via Datatracker <[e-mail]>
Sent: Tuesday, February 27, 2024 6:22 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-20: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-20: 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%7C02%7Clinda.dunbar%40futurewei.com%7Ce8527547058247aaec8108dc37f354c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446765456124442%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QRe2wKoTRN8JBvVHfGx3KAkwrE5KDR9zg4%2Fe%2FxWgbuQ%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%7C02%7Clinda.dunbar%40futurewei.com%7Ce8527547058247aaec8108dc37f354c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446765456133760%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6fxUOP0ZqD%2F9phgTAfft4eIiRJHLDWRYPNEI%2FvpUsro%3D&reserved=0



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(revised position)

** Section 8.
   In SD-WAN deployments where no secure management channel exists
   between the SD-WAN controller and the SD-WAN edges, TLS or IPsec
   can be established to bridge the gap. While beyond the scope of
   this document, conducting a comprehensive analysis is imperative
   to ensure the security of BGP over TLS [BGP-OVER-TLS].

This text would benefit from further specificity.  My feedback below is very
similar to my original DISCUSS position on -15 of this document.

-- Is the "secure management channel" described here the protocol that carries
the BGP?

[Linda] Yes. In Scenario #3 (Section 3.4 of the document), the Secure Management Channel is the VPN provider's secure private path for managing the service provider-managed VPN.


-- Assuming it is, what is a "secure management channel" that would allow BGP
to travel over the Internet that isn't protected by IPsec (i.e., why can't this
text roughly read, "BGP over IPsec MUST be used").  When and how should the BGP
communication be secured?  Section 3.1.5 does mentioned that the BGP connection
must be secured (i.e., "As the connection between an SD-WAN edge and its RR can
be over an insecured network, an SD-WAN edge must establish a secure connection
to its designated RR upon power-up. The BGP UPDATE messages must be sent over
the secure channel to the RR.")

[Linda] The provider VPN management channel is NOT over Internet. They are VPN provider's secure private paths.

-- The imperative, comprehensive analysis of [BGP-OVER-TLS] is not sufficiently
motivated and the reference to an unadopted individual document is confusing.
I agree with the recommendation of the SECDIR reviewer to drop [BGP-OVER-TLS].
Can the basis for including it be explained?

[Linda] There are deployments of using BGP over TLS. See the email archive: https://mailarchive.ietf.org/arch/msg/bess/exfTl1QnJ5kq-bjEteJJFRuq3os/.
TLS has been widely deployed to carry sensitive data. There is no reason that BGP messages over TLS can have any security issue.



** (Missed this on my original ballot on -15) The need for "additional
anti-DDoS mechanism" is mentioned in the text in Sections 6.2.2, 6.3.2, 8.  Can
the expected mechanisms please be clarified.

[Linda]  As mentioned in the reply to John Scudder comment:
anti-DDoS is a commonly used tool for any interface facing ports. It is out of the scope of this document to describe the details.  Is adding the following sentence helpful?
        "The anti-DDoS mechanism comprises numerous components, and their detailed discussion is beyond the scope of this document."

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Stephen Farrell for the SECDIR review.

I support the DISCUSS position of John Scudder.

** Section 2.  Editorial. If Section 3.2. defines "Homogeneous Encrypted
SD-WAN" and the term isn't used prior to that. Consider if this needs the
definition.

[Linda] Homogeneous Encrypted SD-WAN is in the Terminology section. The more detailed description is  in Section 3.2.



** Section 2.
   SD-WAN IPsec SA: IPsec Security Association between two WAN ports
               of the SD-WAN nodes or between two SD-WAN nodes.

Is it "two SD-WAN nodes" or "two SD-WAN edge nodes"?  If the former, what is an
"SD-WAN" node that isn't an edge node?

[Linda] Same.  Change to "SD-WAN edge nodes.

** Section 3.1.2.  This sections seems to suggest that various MEF 70.1
behavior needs to be supported.  This suggests that [MEF70.1] needs to be a
normative reference.
[Linda] A procedure question: Can IETF use MEF70.1 as normative reference?

** Section 3.1.3.  Editorial.
   SD-WAN Traffic Segmentation enables the separation of the traffic
   based on the business and the security needs of different user
   groups and/or application requirements. Each user group and/or
   application may need different isolated topologies and/or policies
   to fulfill the business requirements.

Isn't a security need also a need of the business?  Otherwise, the second
sentence should read "... to fulfill the business and security requirements".
[Linda] Added.

** Section 3.1.3.  Editorial.
   The traffic from the PoS application follows a tree topology
   (denoted as "----" in the figure below), whereas other traffic can
   follow a multipoint-to-multipoint topology (denoted as "===").

In the figure, where is the PoS application, in one of the "Site #"?
[Linda] PoS application is in every site.
 Is there
an assumption that traffic "flows up" from the sites to the payment gateway?
Where is the a "---" link from the "===="-connected "multi-point connection for
non-payment traffic"?
[Linda] This is a use case showing an SD-WAN topology for PoS application in every site to go to the Payment Gateway. "Up" is only for illustration purpose.
"====" is a multi-point-multi-point connection among  all sites.  "----" is a hub-spoke connection between Payment Gateway to each Site.


** Section 3.1.4
     - Upon power-up, the SD-WAN edge can establish the transport
     layer secure connection [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.

Same feedback as provided on the ballot of the -15 version of this document:
Can the last two configuration options be clarified.
[Linda]  Do you think it is necessary to add the detailed steps  for using USB or email approach? We can add the following if you don't think it is too much:

      "The external USB method involves providing the installer with a pre-configured USB flash drive containing the necessary configuration files and settings for the SD-WAN device. The secure Email approach entails sending a secure email containing the configuration details for the SD-WAN device. "

-- 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?
[Linda] Yes, USB Flash Drive.

Neither of these mechanisms seem like "Zero Touch".  They seem like the
definition of human-in-the-loop.
[Linda] Agree. That is what the SD-WAN industry call it.  Intent of  this document is to make it clear. The first sentence of the section says " SD-WAN Zero-Touch Provisioning (ZTP) allows devices to be configured and provisioned centrally without the need to dispatch a network engineer to the field to configure the remote devices."

** Section 3.1.4.  My understanding of Section 3.1.* was that it was series of
requirements to be fulfilled by using BGP with SDWAN.  Per Zero Touch
Provisioning, in what way is BGP involved in this provisioning? I'm not sure
how this section fits into the scope of the document.

[Linda] 3.1.4 is to explain the  SD-WAN requirement. This document is to describe how BGP can make it even better.

** Section 3.2
   -  A small branch office connecting to its HQ offices via the
   Internet. All traffic to/from this small branch office must be
   encrypted, usually achieved by IPsec Tunnels [RFC6071].

   -  A store in a shopping mall may need to securely connect to its
   applications in one or more Cloud DCs via the Internet. A common
   way of achieving this is to establish IPsec SAs to the Cloud DC
   gateway to carry the sensitive data to/from the store.

What is the technical difference between an "IPsec Tunnel" per the branch
office use case and a "IPsec SA" in the store in the mall use case?

[Linda] IPsec SA is to achieve the IPsec tunnel.

** Section 4.3
   In the context of a BGP-
   controlled SD-WAN, BGP UPDATE messages can disseminate IPsec-
   related attribute values for each node

Per the ballot on -15 of this draft, I asked "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."  I still believe additional clarity is required.

[Linda] draft-ietf-bess-bgp-sdwan-usage is supposed to describe the SD-WAN scenario, requirements, and justifications for BGP to control the SD-WAN. The draft-ietf-idr-sdwan-edge-discovery is for actual protocol extension.

** 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-
   Encapsulation [RFC9012] Attributes.

Per
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ce8527547058247aaec8108dc37f354c1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446765456145140%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VbnyQtFICWuyoQEOkQ9QXq%2B90AmOOxY49q8ZkHW8aa4%3D&reserved=0,
is that value=25

** [SECURE-EVPN] is referenced a few times in the course of the draft.  Is the
WG confident that this expired draft is appropriate to use?
[Linda] we took the sub-TLVs from the [SECURE-EVPN] document as the SECURE-EVPN is not progressing. The writing is to acknowledge that we took the definitions from there. We can remove the reference.


** Section 8.
   Adding an Internet-facing WAN port to a C-PE can introduce the
   following security risks:

   1) Potential DDoS attacks from the Internet-facing ports.

   2) Potential risk of malicious traffic being injected via the
   Internet-facing WAN ports.

   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.

   Therefore, the additional anti-DDoS mechanism must be enabled on
   all Internet-facing ports to prevent potential attacks from those
   ports.

I'm having trouble understanding what is considered in-scope for these Security
Considerations.  I was under the impression that the focus was the use of BGP
as the control plane for SD-WAN communication.  Does it also include the
"tunnels"/links configured by the SD-WAN via BGP.

[Linda] The  In-Scope Security Consideration includes the three bullets documented, because by default the PE's ports don't have those features enabled.

-- If the security properties of tunnels/links configured by the SD-WAN BGP are
in scope, then a reminder that links transiting non-Internet links are subject
to security properties negotiated in the SLAs of that provided.
[Linda] The "non-internet links" are provider managed VPN links/paths. They are considered as secure as the VPN (e.g., MPLS networks, SRv6 networks, etc.) provided by the service providers.


Specifically, on -15 of this document, I previously balloted "** Section 8.
The different deployment models also seem to place different levels of trust in
the service providers.  Consider mentioning these differences."

-- Likely because I don't understand the definition of "Internet-facing ports"
in the this context, I don't see a difference between risk (2) and (3).  (2)
seems like a more general version of (3).

[Linda] the document is describing the SD-WAN expanded from the conventional VPN. In VPN, the WAN ports are facing VPN provider managed paths/trunks.

-- What is the relationship between "anti-DDoS mechanism" and risk (2) of
malicious traffic being injected?  Malicious traffic injection isn't
necessarily a DDoS.
[Linda] You are correct. Most people think so.

-- I observe that there are no inherited Security Considerations from IPsec or
BGP mentioned here.

Per the ballot on -15 of the document, "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)?", this feedback still applies.
[Linda]  Do you want us to add: the USB flash drive could be mistaken by unauthorized personal?  Isn't it obvious? Something like:
      "With the external USB method, it is imperative to ensure the physical security of the USB flash drive, as its loss or unauthorized access could compromise critical network information. Similarly, the secure Email approach demands robust email security measures to prevent interception or unauthorized access during transmission. Employing encryption and authentication mechanisms for the secure email ensures that the configuration details remain confidential, mitigating the risk of unauthorized parties gaining access to sensitive information".

** Section 10.1  Please provide the appropriate citation for [BCP195]

[BCP195]                Consists of RFC8996 and RFC9325