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>
*Sent:* Thursday, July 17, 2025 6:50 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
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>
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>
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:
* 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.
* 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>
*
<jmh>Thanks.</jmh>
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
