Paul, Thank you very much for the quick response. Please see below of the response. If there is still confusion, can we have a zoom chat?
Linda From: Paul Wouters <[email protected]> Sent: Friday, August 15, 2025 2:20 PM To: Linda Dunbar <[email protected]> Cc: ipsecme-chairs <[email protected]>; IPSEC <[email protected]>; Deb Cooley <[email protected]> Subject: Re: Follow-up on adoption options for draft-dunbar-ipsecme-lightweight-authenticatee On Fri, Aug 15, 2025 at 2:03 PM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Dear IPsecme Chairs, I’m writing to follow up on my note after IETF 122 regarding adoption of https://datatracker.ietf.org/doc/draft-dunbar-ipsecme-lightweight-authenticate/ . This draft was also presented at the AllDispatch session at IETF 121, where it was recommended that IPsecme is the proper venue for the discussion. The mechanism described in the draft is a key dependency of https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/ , which is progressing in RTGWG but lacks the IPsec/crypto expertise needed for proper review. Without IPsecme involvement, it is difficult to demonstrate that the proposed approach has undergone the appropriate expert scrutiny, even though it is being referenced and deployed in a routing context. I read the draft again, and I still don't really understand it. It seems to be CPE to Cloud GW but the connection between these is "the internet". [Linda] Correct. For example, an enterprise has multiple locations, say Seattle, Boston, or Singapore. Seattle-CPE establishes an IPsec tunnel with Boston-CPE. Instead of best effort forwarding of the IPsec encrypted packets from Seattle-CPE to Boston-CPE via internet, the IPsec encrypted packets from Seattle-CPE is encapsulated with GENEVE header (with Destination address set to the Seattle Cloud GW) to force the packet to the Seattle Cloud GW, which in turn can transport the IPsec encrypted packets to the Boston Cloud GW via Cloud Backbone. The Boston Cloud GW then strip the outer GENEVE header and forward the original IPsec encrypted packets to the Boston-CPE. This document is about authentication methods to protect the GENEVE header (which is not encrypted) between the CPE and its closest Cloud GW. I don't see how a routing path can (or should) be enforced in such scenarios . If it is not, and the path is within the Administrative Domain, [Linda] It is not about routing path. then I don't really understand the attack model. This seems to be very similar to NASR and other path validation proposals that have not seen consensus on being a solvable problem. I don't see any relationship to IPsec other than that the inner content of the GENEVE packet happens to be an ESP packet? But that seems orthogonal to the problem and solution space. It could also have been a TLS packet for example. [Linda] the Attack model is about tempering the GENEVE header with the metadata for desired forwarding behavior, for example, Excluding specific states, or regions. Additionally, the reasons for not using AH/ESP on the outer layer seems weak. We have IPTFS RFC 9347 that should resolve any MTU issues encountered. [Linda] since the payload is already encrypted, the document suggests 4 bytes HMAC value to avoid MTU issue. Last, the authentication key is all defined to be "provisioned", which makes this not a protocol one simply turns on. And another protocol is needed to distribute and rotate these keys, and now to deal with streams using the just rotated auth key, that is currently unspecified. [Linda] It is for deployment where there is shared key between the CPE and Cloud GW for other traffic (i.e. the services that needs to be terminated within the cloud) Could you advise on the most appropriate path forward to ensure expert review by the IPsec community? For example: * Proceed with IPsecme WG adoption (preferred), or I don't see this being a great for IPsec. It is not using AH, but its own (GENEVE?) encapsulation and tweaking some HMAC bits into it) * Pursue AD-sponsored publication in the Security Area with reviewers from IPsecme, or Speaking only for myself, I will not AD sponsor this document. Paul Thank you very much. Linda Dunbar From: Linda Dunbar Sent: Tuesday, July 8, 2025 11:28 AM To: ipsecme-chairs <[email protected]<mailto:[email protected]>>; IPSEC <[email protected]<mailto:[email protected]>> Subject: Request for IPsecme WG Adoption of draft-dunbar-ipsecme-lightweight-authenticate Dear IPsecme WG Chairs, Thank you again for the opportunity to present draft-dunbar-ipsecme-lightweight-authenticate<https://datatracker.ietf.org/doc/draft-dunbar-ipsecme-lightweight-authenticate/> at IETF 122. I understand that the current scope of the IPsecme WG may not formally cover the specific optimization proposed in this draft. However, I would like to respectfully request that the IPsecme WG consider adopting it as a WG document. The motivation behind this request is that the mechanism described in the draft is essential to draft-ietf-rtgwg-multisegment-sdwan<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/>, which is actively progressing within the RTGWG. That said, the RTGWG lacks the cryptographic and IPsec expertise required to evaluate the proposed lightweight authentication solution. IPsecme, on the other hand, is the natural home for the review and validation of IPsec header extensions and authentication mechanisms. Without adoption by IPsecme WG, it is difficult to demonstrate that the proposed approach has undergone appropriate expert scrutiny, even if it is being referenced and deployed in a routing context. Could you please advise on how best to proceed? I would appreciate your guidance on whether this can be adopted or if there is another path forward to ensure appropriate review by the IPsecme community. Warm regards, Linda Dunbar
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
