Here is the link to the revision:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/
Linda
*From:*Linda Dunbar
*Sent:* Monday, August 11, 2025 2:23 PM
*To:* 'Joel Halpern' <[email protected]>; Joel Halpern
<[email protected]>
*Cc:* rtgwg <[email protected]>; Adrian Farrel <[email protected]>;
'Jon Geater' <[email protected]>
*Subject:* RE: [rtgwg] Re: draft-ietf-rtgwg-multisegment-sdwan-04
early Rtgdir review
Joel,
The revision has been uploaded.
Also included the resolution to SecDir Jon Greater’s comments.
Please let us know if the document is ready.
Thank you very much,
Linda
*From:*Joel Halpern <[email protected]>
*Sent:* Thursday, August 7, 2025 3:58 PM
*To:* Linda Dunbar <[email protected]>; Joel Halpern
<[email protected]>
*Cc:* rtgwg <[email protected]>; Adrian Farrel <[email protected]>
*Subject:* Re: [rtgwg] Re: draft-ietf-rtgwg-multisegment-sdwan-04
early Rtgdir review
Two small points:
1) The region identification has to be the UTF-8 name of the region.
If the cloud provier uses numbers, then use the UTF-8 encoding of
whatever representation they use for those numbers. Do not try to
allow a numeric value. It will just complicate processing for no
benefit.\
2) Once you have this done, make sure the description of the Exclude
Region TLV content use the same encoding.
Yours,
Joel
On 8/7/2025 6:51 PM, Linda Dunbar wrote:
Joel,
Thank you very much for attending the zoom call with Google’s
Ashok and Oracle’s Kausik to clarify the detailed requirements for
Include – Regions for Cloud Backbone Transit. The More accurate
name should be Restricted Region List.
Here is the revised section for the Restricted Region. If it is
Okay with you, we will add it back to -06:
Linda
--------------------------------
4.5 Restricted Regions Sub-TLV
Some enterprises may require that traffic across the Cloud
Backbone is strictly confined to a specific set of regions. This
Sub-TLV allows the ingress SD-WAN CPE to express such restrictions
as part of the encapsulation metadata.
Traffic MUST be discarded if the Ingress Gateway, the Egress
Gateway, or any transit node belongs to a region not listed in
this Sub-TLV.
This restriction is commonly used to enforce regulatory, security,
or latency-based geographic constraints, where data must remain
confined to specified regions.
Format of the Restricted Regions Sub-TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (=4) | Length | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Len | Region ID or UTF-8 encoding of Region Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Len | Region ID or UTF-8 encoding of Region Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.Type(8 bits): Assigned value identifying the Restricted Regions
Sub-TLV. Suggested value: 4.
2.Length (8 bits): Total length of the Value field (everything
after the Type and Length fields), in octets.
3.Reserved (16 bits): Reserved for future use. MUST be set to zero
and ignored on receipt.
4.Region Len (8 bits per region entry): Length of the region
identifier or UTF-8 name, in octets.
5.Region ID or UTF-8 encoding of the Region Name: Variable-length
region identifier. Can be a numeric Region ID or a UTF-8-encoded
string (e.g., "us-west", "eu-central").
Multiple regions MAY be present, each starting with its own Region
Len field.
Processing notes:
6.Receiving Cloud Gateway MUST check whether it and all
intermediate transit regions are included in the listed regions.
7.If any component of the path falls outside the listed regions,
the packet MUST be discarded.
8.Region interpretation is based on prior agreement between the
enterprise and the Cloud Backbone provider (e.g., standard region
names, operator-specific definitions, or standardized Region IDs).
Note:
It is beyond the scope of this document to specify how the Cloud
Backbone enforces this restriction. Mechanisms for identifying
region boundaries, enforcing region-based constraints, and
generating alerts or alarm notifications when traffic violates
region restrictions are subject to implementation decisions and
based on prior agreement between the Cloud Backbone provider and
the enterprise.
*From:*Linda Dunbar
*Sent:* Monday, August 4, 2025 1:02 PM
*To:* Joel Halpern <[email protected]> <mailto:[email protected]>
*Subject:* RE: [rtgwg] Re: draft-ietf-rtgwg-multisegment-sdwan-04
early Rtgdir review
Joel,
Thank you!
How about this revision?
(^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
( Cloud Backbone )
(+-----+ +----+ +-----+)
+ ---(|CEdge|==| GW1==================== GW2 |)
Direct | (+-----+ +/--\+ +--|--+)
Connect | (^^^^^^^^/^^^^\^^^^^^^^^^^^^^^^^^^^^|^^^)
{-+---} / \ |
{ VPN } / \ +-----+
{-+---} / IPsec Tunnel |CPE10|
+-------+--/--------+ \ +-----+
| / | \ 192.0.2.128/25
++/--+ | +--\-+ 198.51.100.128/25
|CPE1| +--+CPE2|
+----+ +----+
Client Route: 192.0.2.0/26 192.0.2.64/26
198.51.100.0/26 198.51.100.64/26
Figure 2 Multi-Segment SD-WAN Stitching via Cloud Backbone
Linda
*From:*Joel Halpern <[email protected]>
*Sent:* Sunday, August 3, 2025 7:08 AM
*To:* Linda Dunbar <[email protected]>
*Subject:* Re: [rtgwg] Re: draft-ietf-rtgwg-multisegment-sdwan-04
early Rtgdir review
Just for your consideration.
As an example of additional tuning, I think figure 2 could be
significantly clarified. If I understand you properly, the cloud
is actually the connection between GW1 and GW2. So put GW on the
left hand side of the cloud, make the cloud a little larger, and
put GW2 on the right hand side of the cloud.
Yours,
Joel
On 8/1/2025 6:42 PM, Linda Dunbar wrote:
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 <[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, July 31, 2025 1:51 PM
*To:* Linda Dunbar <[email protected]>
<mailto:[email protected]>; [email protected]
*Cc:* [email protected];
[email protected]
*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 <[email protected]>
<mailto:[email protected]>
*Sent:* Wednesday, July 30, 2025 7:38 AM
*To:* Linda Dunbar <[email protected]>
<mailto:[email protected]>; Joel Halpern
<[email protected]> <mailto:[email protected]>;
[email protected]
*Cc:* [email protected];
[email protected]
*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 <[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, July 17, 2025 6:50 PM
*To:* Linda Dunbar <[email protected]>
<mailto:[email protected]>; [email protected]
*Cc:*
[email protected];
[email protected]
*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
<[email protected]> <mailto:[email protected]>
Sent: Thursday, July 17, 2025 10:46 AM
To: [email protected]
Cc:
[email protected];
[email protected]
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>
_______________________________________________
rtgwg mailing list [email protected]
To unsubscribe send an email [email protected]
