IETF Last Call Review of draft-ietf-rtgwg-multisegment-sdwan-13
review-ietf-rtgwg-multisegment-sdwan-13-secdir-lc-eastlake-2026-07-02-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with Issues.

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.

Security Issues
---------------

Section 9: It seems to me that there is too much actual core specification
in this Security Considerations Section and that some of the mechanism
specification it provides should be moved elsewhere in the draft.

Section 9.2:

- To be interoperable, I think there MUST be at least one mandatory to
implement hash function, such as SHA-256, for the HMAC.

- 1st paragraph:
 - - 2nd sentence: Says the HMAC "is appended to the packet", but in this
case it is included in a header field. If you want to be general you could
say "accompanies the data to be authenticated".
 - - Why does the HMAC only cover the GENEVE Header? This enables cut and
paste attacks where a good GENEVE Header with HMAC can be applied to a
different payload. Say there are two flows from CPE1 to CPE2. By swapping
authenticated GENEVE headers, you could cause a payload from one flow to
appear to validly be in another flow. HMAC is relatively efficient but if
it is considered too much computation to include the entire payload, you
could just include the ICV in the HMAC.

- 2nd paragraph:
 - - I do not understand how the salt would be configured or why it might
need to be different. Suggest deleting "unless otherwise configured,"
 - - Recommend included a reference to [RFC0020] for "ASCII".
 - - This paragraph talks about not needing an IKEv2 exchange to set up
IPSEC between each pair of CPEs but the method of computing keying material
based on the two CPE<->GW IPSEC associations is only talked about as
providing the HMAC secret key. This seems inconsistent. I guess "the key
distribution" is talking about the distribution of algorithm identifiers
and keys for the CPE<->CPE IPSec?

- 3rd paragraph: this is somewhat of a judgement call but I would be
suspicious of HMACs less than 12 bytes; however, given that use of
AH/ESP-NULL is provided as an alternative, this is probably not much of a
problem.

Page 23, 24: It says:
       "Computed over the entire GENEVE header, including the
        Multi-Segment SD-WAN Option Class and all included Sub-
        TLVs, excluding only the HMAC-Auth-Val Sub-TLV (that is,
        neither the Type, Length, Reserved, nor HMAC Value
        fields of the HMAC-Auth-Val Sub-TLV are included in the
        calculation)"
For interoperability, it is essential that the exact bits being hashed be
specified with complete precision. Does this mean that it is calculated
over the GENEVE Header Before the HMAC-Auth-Val Sub-TLV has been added and
before the GENEVE Header length has been adjusted for it? Does this mean
that it is calculated over the GENEVE Header after that Sub-TLV is added
and the length adjusted but that in calculating the HMAC the bytes in the
listed fields are just ignored and not input to the hash function? Someone
used to other protocols which are calculated with some fields zeroed might
even implement this as computing the HMAC over the header after this
Sub-TLV is added but with the not "included" fields set to zero although I
think this is less likely than the first two interpretations.

Question
---------

Appendix A.1:
- This talks of CPE1 and CPE2 establishing a bidirectional IPsec tunnel. Is
this via IKEv2 messages sent through the GW? Are the algorithms and keys
all pushed down by a controller?

Minor Issues
------------

Section 4.5: The name of these regions is confusing. It should be "Allowed
Regions" or "Permitted Regions" or the like. "Restricted Regions" sounds
like regions that the traffic is restricted from. That is, until I read the
more detailed text, I first thought "Restricted Regions" meant "Prohibited
Regions". (The name "Exclude Transit" in Section 4.6 is OK.) Thinking about
this, to minimize wording changed, you might label the Section 4.5 things
as "Restricted To Regions" or "Transit Restricted To Regions" which would
be clear enough,

Can both the Section 4.5 and 4.6 sub-TLVs appear in the same message? If
not, I assume the message should be discarded if they do but Section 5 does
not say that. If they can both appear, what does that mean? I assume a
Section 4.5 sub-TLV implies that all other regions are prohibited and a
Section 4.6 implies that all other regions are allowed. What would it mean
for regions listed in neither sub-TLV if both were present? What would it
mean for one or more regions to be listed in both if both were present?

The very first listed step in packet processing in Section 5 talks of
"preconfigured authentication method". Can you give an example or a
reference to an RFC talking about some of these? Or are you just talking
about the HMAC, in which case I think the draft should say so?

Section 6 talks about checking that the packet complies with policy by
ensuring "mandatory transit nodes are included and excluded nodes are
avoided". This talks about "nodes" while Sections 4.5 and 4.6 talk about
"regions". This seems inconsistent.

There are several occurrences of "Must set to 0." which I think should be
"MUST set to 0." In general, capitalization of RFC 2119 key words should be
checked.

Nits
----

Introduction, Page 4: suggest
"Cloud Backbone stitching SD-WAN segments" ->
"Cloud Backbone stitching together SD-WAN segments"
There are additional cases where I think the draft would read better by
adding "together" after "stitching".

Perhaps in Section 4.1 in the list of fields below Figure 3, to be
absolutely clear, it should specify the value of C rather than just saying
"set". So it would be something like

- C-bit: value 0b1 to ensure that a receiving node drops
   the packet if it does not recognize the option, as per
   [RFC8926]

Section 4.2: refers to the "Address Family Numbers" registry. For absolute
clarity, suggest adding "IANA" and adding the URL for the registry in the
references and adding a reference here. So it would become "IANA Address
Family Numbers [IANA-AFN]" or the like.

Section 9.1, last sentence: "Mitigation above risks" -> "Mitigation of the
above risks"

Appendix A.1:
- The packet diagram in Figure 10 is just described as "A packet from
192.0.2.1 to 192.0.2.65". But I think some of the initial fields listed for
this packet change along the way. At least the outer IP Header would
change. At a minimum, seems like the text should say "A packet from
192.0.2.1 to 192.0.2.65 as initially transmitted by CPE1"

Appendix A.2:
- I'm not sure why, in the IP addresses of CPE1 and CPE10, one is a /26 and
the other is a /25. It's not wrong but it just seems a little odd. Suggest
they both be /25.
- Comparing Figure 10 and Figure 11, they are very similar but there are
some odd differences. Figure 10 shows "Optional other SD-WAN Sub-TLVs" but
Figure 11 does not even though I think they could both have, for example,
the Exclude Transit Sub-TLV. In the same box as that, they both have
"validated by GW" but it has unbalanced parenthesis in Figure 11. Figure 10
says the ICV is generated by CPE1 but this is missing from Figure 11.
- As with A.1, it should indicate that this is a diagram of the packet as
initially transmitted by CPE1.

Appendix B:
- From this appendix, maybe the "Edge" box in Figure 1 has to do with the
VPN?
- It is good that Figures 12 and 13 in this section show the change in the
headers. It is not so good that these two figures use somewhat different
formatting from Figures 10 and 11; in particular, the horizontal divisions
by minus signs or equal signs don't seem consistent between the two pairs
of figures.
- Since Appendix A covers both "single hop" and "multiple hop" cases and
Appendix B covers only "single hop", the reader is likely to wonder about
the VPN multi-hop case. I think this could be answered with one or two
sentences.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com