Michael, Thank you very much for the questions and the comments. Answers to your questions are inserted below:
Linda -----Original Message----- From: Michael Richardson <[email protected]> Sent: Monday, September 8, 2025 7:19 AM To: Linda Dunbar <[email protected]>; IPSEC <[email protected]> Cc: Paul Wouters <[email protected]>; Deb Cooley <[email protected]> Subject: Re: [IPsec] Re: Follow-up on adoption options for draft-dunbar-ipsecme-lightweight-authenticatee Linda Dunbar <[email protected]> wrote: > I believe I’ve addressed the questions you raised in our earlier email > exchanges, but please let me know if I’ve missed anything. > Could you share your recommendation on the best path forward? Should we > consider AD sponsorship, pursue adoption in IPsecme, or take another > route? 1. Running Code. [Linda] HMAC is already widely deployed in IPsec and other protocols; our approach simply applies the same existing HMAC functionality more selectively, so it is a subset of what current implementations already support. 2. As for rough consensus: Depends upon who is going to implement. It seems that you need Azure, Google, AWS to implement in order to deploy. [Linda] The mechanism is not tied to any specific cloud provider; it relies on standard HMAC functions already supported in existing implementations, so deployment is not dependent on Azure, Google, or AWS. The overall HMAC approach is described in https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/ , co-authored by Google and Oracle Cloud, while the current draft focuses on the key management details that require review and endorsement from IPsec WG experts. For this reason, we are seeking either Security AD sponsorship or adoption in the IPsecme WG. I imagined firewall interactions with IPsec back in 1996. https://datatracker.ietf.org/doc/draft-richardson-ipsec-traversal/ It was endhost-to-endhost AH inside security "hop"-by-hop ESP. The problem is getting the transient trust to the intermediate hop, and that is what I've asked about since you presented in Brisbane. I heard that it wasn't a problem, because SDN would orchestrate, but that's a single AS solution. {In hindsight, the MTU issue would have killed us, had we managed to implement it. IP-TFS ought to solve that problem now, though} [Linda] The additional 4-byte HMAC value proposed in the document should not be considered a significant concern. Compared with the SRv6 header and the multiple layers of IPv6 addresses it can carry, the overhead of 4 bytes is negligible. MTU considerations are exactly why the draft specifies truncating HMAC from the standard 32 bytes (HMAC-SHA-256) down to 4 bytes. Because this deviation from the usual HMAC length raises important security questions, the draft requires review and endorsement from the Security Area—either through AD sponsorship or adoption in the IPsecme WG. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
