Joel,
Thank you very much for the call, making me understand where the
confusion is.
Do you think the following revision of the Abstract and the
Introduction can make it clear? Also, we probably should remove the
“Include-Sub-TLV” for now as there are so many issues.
/Abstract///
/This document describes a method for seamlessly interconnecting
geographically separated SD-WAN segments via a Cloud Backbone without
requiring Cloud Gateways (GWs) to decrypt and re-encrypt traffic. By
encapsulating IPsec-encrypted payloads within GENEVE headers (RFC
8926), the approach enables Cloud GWs to forward encrypted traffic
directly between distant Customer Premises Equipment (CPEs). This
reduces processing overhead, improves scalability, and preserves the
confidentiality of enterprise data while ensuring secure and efficient
multi-segment SD-WAN. connectivity//.///
/1. //Introduction///
/Enterprises are increasingly turning to SD-WAN to connect on-premises
CPEs with cloud services, as discussed in detail in [Net2Cloud]. Each
SD-WAN segment typically connects a CPE to its nearest Cloud Gateway
(GW). Some of this traffic terminates at the cloud services and must
be decrypted by the Cloud GW. Other traffic is destined for remote
CPEs located in different geographic regions and only require
forwarding across a Cloud Backbone, without decryption./
/Multi-segment SD-WAN refers to the architecture in which two or more
SD-WAN segments are interconnected via a Cloud Backbone. This model
enables traffic that originates in one SD-WAN segment to reach a
distant CPE through transit Cloud GWs without decryption. It supports
hybrid traffic handling: local cloud-bound traffic is decrypted by the
Cloud GW, while CPE-to-CPE traffic is forwarded securely across the
backbone./
//
//
Linda
*From:*Joel Halpern <jmh.dir...@joelhalpern.com>
*Sent:* Thursday, July 31, 2025 1:51 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com>; rtg-...@ietf.org
*Cc:* draft-ietf-rtgwg-multisegment-sdwan....@ietf.org; rtgwg@ietf.org
*Subject:* Re: draft-ietf-rtgwg-multisegment-sdwan-04 early Rtgdir review
In line, marked <jmh3></jmh3>. Given that I am still confused on
these issues, I suspect even if you end up keeping the behaviors as
they are, better explanation is needed.
Yours,
Joel
On 7/31/2025 4:29 PM, Linda Dunbar wrote:
Joel,
Thank for the reply.
Below are the additional resolutions marked as [Linda3] . Please
let me know if they are acceptable.
Thank you,
Linda
*From:*Joel Halpern <j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>
*Sent:* Wednesday, July 30, 2025 7:38 AM
*To:* Linda Dunbar <linda.dun...@futurewei.com>
<mailto:linda.dun...@futurewei.com>; Joel Halpern
<j...@joelhalpern.com> <mailto:j...@joelhalpern.com>; rtg-...@ietf.org
*Cc:* draft-ietf-rtgwg-multisegment-sdwan....@ietf.org; rtgwg@ietf.org
*Subject:* Re: draft-ietf-rtgwg-multisegment-sdwan-04 early Rtgdir
review
Trimmed to remove agreements. Context retained for remaining
issues. My new notes marked <jmh2></jmh2>
Yours,
Joel
On 7/29/2025 10:25 PM, Linda Dunbar wrote:
Joel,
Apologies for missing this email through the IETF week.
Thank you very much for the additional comments. Please see
below under [Linda 2] for the proposed resolutions. Let us
know if they are acceptable.
Linda
*From:*Joel Halpern <j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>
*Sent:* Thursday, July 17, 2025 6:50 PM
*To:* Linda Dunbar <linda.dun...@futurewei.com>
<mailto:linda.dun...@futurewei.com>; rtg-...@ietf.org
*Cc:* draft-ietf-rtgwg-multisegment-sdwan....@ietf.org;
rtgwg@ietf.org
*Subject:* Re: draft-ietf-rtgwg-multisegment-sdwan-04 early
Rtgdir review
Some of your answers address the raised concerns. However,
some of them indicate I was insufficiently clear, as they do
not address the issue. I will not in line where things are
fine,a nd where I think there is still a problem. I will
delimit my comments with <jmh></jmh> in case of indenting
problems.
Yours,
Joel
On 7/17/2025 9:12 PM, Linda Dunbar wrote:
Joel,
Thank you very much for reviewing the document and the
valuable feedback.
Please see below for the detailed resolutions.
If they are okay with you, we can upload the revision on
Monday.
Linda
-----Original Message-----
From: Joel Halpern via Datatracker <nore...@ietf.org>
<mailto:nore...@ietf.org>
Sent: Thursday, July 17, 2025 10:46 AM
To: rtg-...@ietf.org
Cc: draft-ietf-rtgwg-multisegment-sdwan....@ietf.org;
rtgwg@ietf.org
Subject: draft-ietf-rtgwg-multisegment-sdwan-04 early
Rtgdir review
Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Joel Halpern
Review result: Not Ready
Hello
I have been selected to do a routing directorate “early”
review of this draft.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-multisegment-sdwan%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415554778%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rGQhV01eJsDerr6g1jxCzUIkhF5vlwTPOohcWDo3%2Bg%3D&reserved=0
<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/>
The routing directorate will, on request from the working
group chair, perform an “early” review of a draft before
it is submitted for publication to the IESG. The early
review can be performed at any time during the draft’s
lifetime as a working group document. The purpose of the
early review depends on the stage that the document has
reached.
This draft describes the extensions to Geneve to enable
using it to interconnect multiple SD-WAN segments, with
particular attention to the case when the carried payload
is IPSec protected.
For more information about the Routing Directorate, please see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415582636%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rne%2Fx6T0XCvkiaZPqAx%2F6%2BWGFFOY7%2FXs9tPq%2BmBi5G4%3D&reserved=0
<https://wiki.ietf.org/en/group/rtg/RtgDir>
Document: draft-ietf-rtgwg-multisegment-sdwan-04
Reviewer: Joel Halpern
Review Date: 17-July-2025
Intended Status: Proposed Standard
Summary:
I have some minor concerns about this document that I
think should be resolved before it is submitted to the
IESG. I also have one major concern that was flagged by
I-D nits <jmh2>resolved</jmh2>. And one major concern
where a procedural element does nto sem to work.
...
Section 4.5 on including specific SD-WAN transitsegments
eems an
understandable goal. However, it also seems fraught with
failure
potential. In simple topologies, yes, it works. But
suppose that the
actual path to the destination is SD-WAN segments
A-B-C-D-E. And suppose
the include requirement says "B". When the GENEVE packet
arrives at the
C-D boundary, it says that its path must include B. But
the path to the
destination from there does not include B. How is the C-D
boundary
supposed to know that B has alreay been traversed?
[Linda] Some SD-WAN deployments require specific transit
segments to be included in the end-to-end path for
regulatory, security, or service chaining purposes, rather
than for path optimization. The Include-Transit Sub-TLV,
an optional field, is used to signal such requirements. It
allows explicitly specifying a list of Cloud Availability
Regions or Zones that a packet must traverse when
forwarded through the Cloud Backbone.
<jmh> I apparently did not explain my concern well enough. I
understand why one would want to mandate that a (or several
(specific SD-WAN are traversed. (I could debate the utility,
but operators and customers often want things I wonder
about.) That is not the source of my concern. It is unclear
who is expected to enforce the mandatory traverse case, and
how loops are avoided. Suppose that SD-WAN A is connected to
SDS-WAN B, which is connected to SD-WAN C and D. And D is
connect to SD-WAN B and E, where the egress exists. A Geneve
packet is sent with an include indicating that SD-WAN B must
be traversed. The packet happens to go theorugh SD-WAN A to
SD-WAN B (meeting the traversal requirement), then to SD-WAN
C, and then to the SD-WAN D. However, by the time the packet
arrives at SD-WAN D, there is no indication in the packet that
it went through SD-WAN B. WHich would seem to require D to
send the packet back to SD-WAN B. Which is clearly not what
is desired. How does the gateway to SD-WAN D know that it
si fine to keep forwarding towards the destination (egress
from E) rather than returning the packet to B? I could
understand how it worked if there was also a route record. Or
if the Include was removed once it was satisfied. But the
draft does not call for either of those behaviors. </jmh>
[Linda 2] Your illustration regarding potential loops and the
lack of explicit enforcement mechanisms is entirely valid.
However, as noted in the draft, it is out of scope for the
IETF (and this document) to define how the cloud backbone
enforces client-specified traversal preferences. The
Include-Transit Sub-TLV is intended only to convey the
client's desired intent or preferences. How about adding this
sentence to the section:
“/…, this indication reflects preference only and does not
imply any guarantee of traversal. Enforcement of the include
list is outside the scope of this document and must be
realized, if needed, through mutual agreement and
provider-specific mechanisms./.”
<jmh2>Note that in the end I am not the one you have to satisfy.
But, from where I sit, a behavioral marking that can't be acted
upon without additional protocol behaviors (which ar enot
obviously valid to me) is not a marking we can have in an RFC. It
does not lead to interopeable implementation. </jmh2>
[Linda3] Your points are well taken. That said, there is
precedent for this approach in RFCs 8670, 7752, and 8306, where
protocol elements convey intent or preference, but their
interpretation and enforcement are left to local policy or
controller behavior. In the same spirit, the Include-Transit
Sub-TLV expresses the originator CPE’s intent to prefer certain
transit regions, while how the Cloud Backbone enforces that
preference is intentionally left out of scope for this document..
<jmh3>The problem I have is that I can't figure out how, if the
gateways are forwarding packets simply as IP encapsulated Geneve
packets, they can conform to the intent. There is an assumption about
how the gateways do their job, and how they are controlled, that is
unstated. This seems to leave a high probability of inconssitent
implementation. As far as I can tell, to comply with the policy, the
gateway into the included domain would have to modify the geneve
packet to remvoe the intent. Which, as I understand it, is against
the RFCs.
</jmh3>
Minor Issues:
...
In section 5, in describing the Ingress GW processing, the
text is written
as if the outer IP destination address will always become
the egress
gateway. As I understand it, if the path goes through
multiple SD-WAN, the
outer IP address at each stage is that of the next
gateway? Could the text
be rewritten to make that clear. Also, doesn't this
imply there is a
"transit gateway" case as well as ingress and egress?
[Linda] The GENEVE header remains during transit across
the Cloud Backbone and is removed by the egress Cloud
Gateway before the packet is forwarded to the destination
CPE. The packet is forwarded natively on the final SD-WAN
segment (egress GW to destination CPE) without GENEVE
encapsulation.
<jmh>I am still missing something. It may be that I am
misunderstanding the interaction between mutli-segment SD-WAN
and GENEVE. Suppose that we have GW1 - SDWAN A - GW 2 - SDWAN
B - GW-3. When the packet arrives at GW-1 with the
multi-segment SD-WAN option, GW1 decides (subject to the
constraints of the options in the packet) that the packet
should go to GW2 in orderr to get to GW3. As I understand it,
GW1 will replace the outer IP destination (which was GW-1 upon
arrival) with the IP address of GW2. But the text says that
it will replace the destination address with the egress IP
address (GW-3, or maybe something beyond that.) </jmh>
<jmh2>I do not see a response to this issue</jmh2>
[Linda3] Sorry for missing this one. The ingress GW determines
the appropriate egress Cloud GW based on its internal logic or
policy, or via the Egress GW Sub-TLV included in the
Multi-Segment Metadata.
The destination address in the outer IP header of the GENEVE
packet should be determined by the Cloud Backbone. This
address is intended to reach the egress Cloud GW identified by
the Egress GW Sub-TLV (if present), or the optimal egress GW
selected based on the destination CPE address.
Changed the text to the following:
<jmh3>We are in amulti-segment SD-WAN. GWI is the ingress, GWE is the
Egress. and the selected path is through GW2 and GW3. If GWI changes
the outer IP address to be the address of GWE, then how does it direct
the packet to GW2, and thence to GW3? This may be related to the
above issue of an assumed unspecified behavior at SD-WAN gateways.
</jmh3>
I do not know if this is a major concern, a minor concern,
or merely a
confused reviewer. There is a description in section 9 of
an attack to
steal data service (conceptually, an understandable
problem.) However, I
am unable to figure out what set of access to what set of
places the
attacker must have, nor how adding authentication to the
CPE / GW exchange
would actually help prevent this attack. In part this is
because the
attack appears underspecified, and in part this is because
the remediation
appears underspecified.
[Linda] does it help to add this sentence to the
introduction?
/In this document, “multi-segment SD-WAN” refers
specifically to deployments with two SD-WAN edge segments:
one from the originating CPE to the ingress Cloud Gateway,
and one from the egress Cloud Gateway to the destination
CPE. There may be additional SD-WAN segments or forwarding
domains between the ingress and egress Cloud Gateways
across the Cloud Backbone, but their internal behavior is
out of scope for this specification./
<jmh>Nope, sorry. That does not tell me what the security
threat is that leads to wanting authentication. It also does
not tell me how the authentication is actually to be done. (I
naive reading is that you are inventing an authentication
extension, with insufficient specificity, to some unspecified
protocol between the CPE and the first SD-WAN gateway.)
</jmh>
[Linda2] Section 9 describes the consequence (data theft) but
does not clearly articulate the security threat or the
authentication model. To clarify:
1. The threat is that a malicious or misconfigured CPE could
inject SD-WAN metadata intended for another tenant,
attempting to use or redirect traffic through paths it is
not authorized for.
2. Authentication is needed to verify the origin and
legitimacy of the SD-WAN metadata, ensuring it is
associated with an authorized endpoint.
<jmh2>At the very least, this needs to be better explained in the
draft. I think the issue is larger. Adding security to the
CPE-SDWAN connection seems to be largely irrelevant if that CPE is
compromised. Additionally, if the SDWAN gateway accepts traffic
from arbitrary devices, taht would seem to be an unerlying SDWAN
problem, not a multi-segment security issue.</jmh2>
[Linda3] do you think the following text for Bullet c) under
Section 9.1 can reflect those two key points?
(c) Potential stealing of Cloud Backbone bandwidth:
A threat actor, such as a malicious or misconfigured C-PE,
could inject SD-WAN metadata intended for another tenant,
attempting to redirect traffic through Cloud Backbone paths it
is not authorized to use. For example, a legitimate Cloud
subscriber pays for Cloud Backbone transport between CPE-A and
CPE-B. An attacker, who controls two locations (Node-A and
Node-B), might construct a packet with CPE-A’s address as the
source and include CPE-B in the SD-WAN Endpoint Sub-TLV. The
packet, when sent to the ingress Cloud GW, would appear to be
a legitimate flow between CPE-A and CPE-B. After exiting the
egress Cloud GW, the attacker could rewrite the outer
addresses to resume communication between Node-A and Node-B,
effectively tunneling traffic via the Cloud Backbone without
authorization or payment.
To prevent such misuse, it is necessary to authenticate and
verify the origin and legitimacy of the SD-WAN metadata to
ensure it is associated with an authorized and registered CPE
endpoint. This validation protects against both spoofing and
cross-tenant policy violations. While it is not necessary for
Cloud GWs to decrypt or re-encrypt payloads, they must enforce
metadata integrity using authentication mechanisms such as
those defined in [RFC2403] and [RFC2404]. These mechanisms
rely on cryptographic hashing algorithms (e.g., SHA2
224/256/384/512) as part of a Hashed Message Authentication
Code (HMAC) to validate packet authenticity.
<jmh3>This sseems to be an underlying SD-WAN security problem, not a
multi-segment problem. It seems like the same attack could be done in
a single-segment SD-WAN? If that is true, and if the existing SD-WAN
RFCs have this problem, then I would think noting in the remediation
that this applies more broadly would seem to help. If I am wrong
about the applicability, some indication of why it is only a problem
in multi-segment would be desirable.
</jmh3>
<jmh>Thanks.</jmh>
