Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Gabriele Galimberti
Review result: Ready
Hello,
I have been selected as the Operational Directorate reviewer for this draft.
The draft is well written, clear and easy to read. It just requires some
cosmetic changes and very small explanations.
I appreciate the examples to explain how the TLV are used and combined
to implement the proposed solution.
Below are the few comments marked as [gmg]
4.2. SD-WAN Tunnel Endpoint Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SD-WAN Endpoint| length | Reserved | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SD-WAN Dst Addr Family | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| SD-WAN end point Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 SD-WAN Endpoint Sub-TLV
- SD-WAN Endpoint (8 bits): Identifies the SD-WAN Tunnel
Endpoint Sub-TLV with a Type value of 1.
- Length (8 bits): Specifies the total length of the value
field in 4-byte units.
- TTL (Time to Live): This field is set by the originating
CPE to indicate the maximum number of logical transit
nodes or regions, those that are visible to the CPEs,
that a packet is permitted to traverse across the Cloud
Backbone. Only transit nodes or regions that are
externally visible (i.e., known to or tracked by the
CPEs) MUST decrement the TTL by one. Internal cloud
forwarding elements that are opaque to the CPEs MUST NOT
modify the TTL. If the TTL reaches zero, the packet MUST
be dropped, and an alert MAY be generated. This
mechanism allows enterprises to constrain the path scope
of their packets, enforce traversal policies, and detect
anomalies (e.g., excessive transit hops).
[gmg] It would be nice to have also the "SD-WAN Dst Addr Family" description
4.3. SD-WAN Tunnel Originator Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SDWAN Origin | length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SD-WAN Org Addr Family | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| SD-WAN Tunnel Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 SD-WAN Tunnel Originator Sub-TLV
- SDWAN Origin (8 bits): Identifies the SDWAN Tunnel
Originator Sub-TLV with a Type value of 2.
- Length (8 bits): Specifies the total length of the value
field in 4-byte units, excluding the first 4 bytes,
which include the SD-WAN Origin (1 byte), Length (1
byte), and Reserved (2 bytes) fields.
- Reserved (16 bits): Reserved for future. Must set to 0.
Ignored by recipients.
[gmg] It would be nice to have also the "SD-WAN Org Addr Family" description
4.4. Egress GW Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SDWAN EgressGW | length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress GW Addr Family | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| Egress GW Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 SD-WAN Egress GW Sub-TLV
- SDWAN EgressGW (8 bits): Identifies the Egress GW Sub-
TLV with a Type value of 3.
- Length (8 bits): Specifies the total length of the value
field in 4-byte units, excluding the first 4 bytes,
which include the SD-WAN Origin Sub-TLV Type (1 byte),
Length (1 byte), and Reserved (2 bytes) fields.
- Reserved (16 bits): Reserved for future. Must set to 0.
Ignored by recipients.
[gmg] It would be nice to have also the "Egress GW Addr Family" description
Multiple region entries MAY be specified in a single Sub-TLV.
Each region is identified by a variable length UTF-8 encoded
name or numeric ID, preceded by a length field. This Sub-TLV
expresses explicit exclusions and supports both soft and hard
enforcement.
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 (=5) | length |E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Len | UTF-8 encoding of Region Name or ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[gmg] having an empty row between the text end the TLV would improve
the readability, the above is just an example, please, fix also
the other parts in the draft.
7.2. Control Plane between CPEs and Cloud GWs
There are typically eBGP sessions between a CPE and a Cloud
GW for exchanging routing information related to services
that terminate within the cloud. This allows the CPE to learn
routes to cloud-hosted resources and enables the Cloud GW to
learn routes to the CPE's on-premises networks. This control-
plane relationship is separate from the CPE-to-CPE encrypted
traffic that transits the Cloud Backbone, which remains end-
to-end encrypted and is not decrypted at the Cloud GWs.
When the connection between a CPE and a Cloud GW traverses a
public or otherwise untrusted network, an IPsec tunnel may
also be established to secure that traffic. In such cases,
IKEv2 is used to exchange the necessary IPsec security
parameters.
[gmg] it is not clear what traffic ("to secure that traffic")
is referred here: the CPE to CPE traffic or the eBGP traffic ?
Can You please clarify ?
9. Security Considerations
9.1. Threat Analysis
The GENEVE header used for steering is not encrypted, making
it susceptible to man-in-the-middle (MitM) attacks between
CPEs and Cloud GWs.
Key risks include:
a) Eavesdropping: Attackers can learn branch and Cloud GW
locations, though payload remains protected by IPsec.
b) Header Manipulation: Altered Sub-TLVs may cause misrouting
or packet drops.
c) Bandwidth Theft: A malicious or misconfigured CPE could
spoof SD-WAN metadata to use Cloud Backbone resources
without authorization.
Mitigation requires authenticating and validating SD-WAN
metadata to ensure it originates from authorized CPEs.
[gmg] please re-format the above text accordingly
10. Manageability Considerations
In multi-segment SD-WAN deployments where the Cloud GW and
CPEs belong to different administrative domains,
manageability must address the challenges of secure,
interoperable, and policy-compliant operation across
organizational boundaries. Key considerations include:
- Cross-Domain Authentication and Authorization:
Ensure that CPEs connecting to the Cloud GW are
authenticated using mutually agreed methods, and that
authorization policies are enforced to prevent
unauthorized use of Cloud Backbone resources.
- Metadata Validation and Policy Enforcement:
Cloud GWs must validate SD-WAN metadata (e.g., GENEVE
Sub-TLVs) against the registered information for each
CPE. This prevents spoofing, misrouting, and cross-
tenant traffic leakage.
- Operational Coordination and Fault Handling:
Define inter-organization procedures for troubleshooting
and incident response. This should include point-of-
contact directories, escalation processes, and shared
logging formats for event correlation.
- Change Management and Configuration Synchronization:
Coordinate configuration changes-such as policy updates,
region restrictions, or authentication parameters-so
that both the Cloud GW and CPEs apply them consistently,
avoiding mismatches that disrupt traffic.
- Policy Automation Using I2NSF Principles ([RFC8192]):
Where feasible, leverage I2NSF concepts to automate
policy configuration, exchange, and enforcement between
domains, reducing manual coordination and improving
operational consistency.
[gmg] any reference document can help to elaborate/define the above
considerations ?
A.1 Single Hop Cloud GW
Assuming that all CPEs are under one administrative control
(e.g., iBGP).
Using Figure 1 as an example:
- There is a bidirectional IPsec tunnel between CPE1 and
Cloud GW; with IPsec SA1 for the traffic from the CPE1
to the Cloud-GW; and IPsec SA2 for the traffic from
the Cloud-GW to the CPE1.
- There is a bidirectional IPsec tunnel between CPE2 and
Cloud GW; with IPsec SA3 for the traffic from the CPE2
to the Cloud-GW; and IPsec SA4 for the traffic from
the Cloud-GW to the CPE2.
- All the CPEs are under one iBGP administrative domain,
with a Route Reflector (RR) as their controller. The
CPEs notify their peers of their corresponding Cloud
GW addresses (which is out of the scope of this
document).
When 192.0.2.0/26 and 192.0.2.64/26 need to communicate
with each other, CPE1 and CPE2 establish a bidirectional
IPsec Tunnel, with SA5 for the traffic from CPE1 to CPE2
and SA6 for the traffic from CPE2 to CPE1. Assume the IPsec
ESP Tunnel Mode is used. A packet from 192.0.2.1 to
192.0.2.65 has the following outer header:
[gmg] shouldn't be 192.0.2.64 instead of 192.0.2.65 and
192.0.2.0 instead of 192.0.2.1 ?
Same also in the Fig. 10
A.2 Multi-hop Transit GWs
Traffic to/from geographic apart CPEs can cross multiple
Cloud DCs via Cloud backbone.
The on-premises CPEs are under one administrative control
(e.g., iBGP).
Using Figure 2 as an example:
- There is a bidirectional IPsec tunnel between CPE1 and
the Cloud GW1; with IPsec SA1 for the traffic from the
CPE1 to the Cloud-GW1; and IPsec SA2 for the traffic
from the Cloud-GW1 to the CPE1.
- There is a bidirectional IPsec tunnel between CPE10
and the Cloud GW2; with IPsec SA3 for the traffic from
the CPE10 to the Cloud-GW2; and IPsec SA4 for the
traffic from the Cloud-GW2 to the CPE10.
- All the CPEs are under one iBGP administrative domain,
with a Route Reflector (RR) as their controller. CPEs
notify their peers of their corresponding Cloud GW
addresses.
When 192.0.2.0/26 and 192.0.2.128/25 need to communicate
with each other, CPE1 and CPE10 establish a bidirectional
IPsec Tunnel, with SA5 for the traffic from CPE1 to CPE10
and SA6 for the traffic from CPE10 to CPE1. Assume the
IPsec ESP Tunnel Mode is used, a packet from 192.0.2.1 to
192.0.2.129 has the following outer header:
[gmg] same comment as above regarding the IP addresses.
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
