Jon,
Thank you for your detailed review and thoughtful feedback on the Security
Considerations section.
See detailed resolutions inserted below.
Best regards,
Linda Dunbar
-----Original Message-----
From: Jon Geater via Datatracker <nore...@ietf.org>
Sent: Friday, August 8, 2025 4:17 AM
To: sec...@ietf.org
Cc: draft-ietf-rtgwg-multisegment-sdwan....@ietf.org; rtgwg@ietf.org
Subject: draft-ietf-rtgwg-multisegment-sdwan-05 early Secdir review
Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Jon Geater
Review result: Has Issues
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.
[Linda] Does adding the following sentence address your concern?
The HMAC authentication described here applies only between the CPEs
and the Cloud Gateway, where a shared key is provisioned by existing SD-WAN
control/security mechanisms (e.g., IKE/IPsec or a centralized controller).
Multi-hop or cross-domain key distribution is not required in this model. For
discussion of lightweight authentication methods that can reduce key management
overhead while protecting header integrity, see
https://datatracker.ietf.org/doc/draft-dunbar-ipsecme-lightweight-authenticate/
- 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?
[Linda] In relatively secure environments where the risk of header manipulation
is low, the authentication mechanism is optional and may be omitted. In such
cases, operators can choose not to set these parameters without compromising
their intended deployment model.
Jon
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
