Hi IPsecME WG, I’d like to ask for the Working Group’s consideration of WG adoption or suggestions for other paths forward for the following draft: https://datatracker.ietf.org/doc/draft-dunbar-ipsecme-lightweight-authenticate/ This draft defines a lightweight authentication mechanism for encapsulation headers (e.g., GENEVE, UDP Options, or SRH) to protect steering and metadata fields without reprocessing the entire payload. After several rounds of technical exchange with Security AD Paul Wouters, I have uploaded a revised version that addresses his earlier concerns and clarifies the intended use and key derivation model. Key Revisions:
* Clear separation of key usage: The HMAC key is now explicitly derived using HKDF from existing IPsec SA material with a unique label (“GENEVE-HMAC”) to ensure cryptographic separation — avoiding any re-use of ESP keys. * Detailed packet flow illustration: Added a time-sequenced diagram showing how CPEs, Cloud GWs, and the Cloud Backbone interact under established IPsec SAs. * Clarified rationale vs. AH: Added text explaining why the full Authentication Header (AH) [RFC 4302] is unsuitable for multi-segment or cloud environments where address or header fields may change (e.g., NAT, re-encapsulation). * Scope clarification: The method authenticates only encapsulation headers, not payloads, to reduce processing overhead in multi-hop or service-chained deployments. The goal remains to provide a practical, interoperable method for authenticating encapsulation headers in cloud or SD-WAN environments where IPsec already secures the payload. I would greatly appreciate the WG’s feedback on whether this approach: 1. Fits within IPsecME’s scope for WG adoption, or 2. Should be progressed through another path (e.g., an individual submission or coordination with Routing Area WGs). Thank you for your time and consideration. Best regards, Linda
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
