On Fri, Aug 15, 2025 at 2:03 PM Linda Dunbar <[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/ > <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/ > <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". 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, 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. 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. 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. > 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]>; IPSEC <[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]
