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]>
*Sent:* Wednesday, July 30, 2025 7:38 AM
*To:* Linda Dunbar <[email protected]>; Joel Halpern
<[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 to [email protected]
