Skip to main content

Early Review of draft-ietf-rtgwg-multisegment-sdwan-05
review-ietf-rtgwg-multisegment-sdwan-05-secdir-early-geater-2025-08-08-00

Request Review of draft-ietf-rtgwg-multisegment-sdwan-04
Requested revision 04 (document currently at 11)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2025-08-08
Requested 2025-07-15
Requested by Yingzhen Qu
Authors Kausik Majumdar , Linda Dunbar , Venkit Kasiviswanathan , Ashok Ramchandra , Aseem Choudhary
I-D last updated 2026-04-24 (Latest revision 2025-11-19)
Completed reviews Secdir Early review of -05 by Jon Geater (diff)
Rtgdir Early review of -04 by Joel M. Halpern (diff)
Opsdir Early review of -07 by Gabriele Galimberti (diff)
Comments
Early review to help prepare for the WGLC. Since Geneve encapsulation extension is proposed, please consider experts with Geneve/tunneling experience.
Assignment Reviewer Jon Geater
State Completed
Request Early review on draft-ietf-rtgwg-multisegment-sdwan by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/JMbKzgt0bVS0zKYD2y3Vz9Kz6dc
Reviewed revision 05 (document currently at 11)
Result Has issues
Completed 2025-08-08
review-ietf-rtgwg-multisegment-sdwan-05-secdir-early-geater-2025-08-08-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 Has Issues. Potentially small issues if
they are addressed by other fundamental parts of SD-WAN security, but
worth discussing.

The Security Concerns section is generally well written and I am
persuaded that most issues faced in the presence of this new
technology are issues that existed already. No problem there.

However the majority of effort in the Security Considerations focuses
on one specific threat: manipulation of the new header contents to
mis-steer packets (potentially for gain). The solution proposed is to
HMAC the contents. I have 2 problems with this solution:
 - HMAC is a symmetric cipher, which requires all participants to have
   a copy of the same secret. And while the examples shown are very
   simple, isn't is very plausible that there might be many more than
   2 steps in a path? So how will management and security of these
   secrets be facilitated practically? And how will identification of
   the presumably several secrets be done? Especially if crossing
   domains of control as the wider network is traversed. Seems highly
   unwieldy to me.
 - If this is a real problem, then what happens to people using SD-WAN
   who *don't* set these parameters at all, expecting not to use it?
   By the logic of the initial attack scenario isn't it possible for
   that same attacker to simply find traffic that isn't using this
   capability and insert completely new headers for fun and profit?

Jon