Joe, Thank you very much for the comments. Please see below the detailed reply:
Linda From: to...@strayalpha.com <to...@strayalpha.com> Sent: Thursday, October 31, 2024 12:31 AM To: Linda Dunbar <linda.dun...@futurewei.com> Cc: Tero Kivinen <kivi...@iki.fi>; Yoav Nir <ynir.i...@gmail.com>; ipsec@ietf.org Subject: Re: [IPsec] Need 10 minutes slot at the IPsecme session Hi, Linda (et al.), I’m not sure I get the whole thing, but (help me if I'm wrong), it seems like the point of this is: 1. there are stacks of protocols used for tunnels [Linda] “Stacks of Protocols”: do you mean layers of encapsulation headers on the data plane? Yes. 1. it can be useful to protect just those added protocol layers (which for UDP would include the trailing options). [Linda] Correct. The document targets the protection of encapsulation headers rather than the entire packet payload. If so, it might be useful to make that more clear. It may also be useful to provide some info as to why protecting just these added layers is a win; a lot of times, the per-packet operations can be as significant as the per-byte operations, and removing some of the bytes - even the majority - might not be a big win. It’d be useful to provide evidence if so. [Linda] the payload is already encrypted. By focusing only on the encapsulation headers, the authentication process is lighter, requiring fewer computational resources. This is particularly advantageous in high-speed networks or resource-constrained environments. It does seem unclear as to what layer this operates, though. If it’s IP, it seems inappropriate to expect it to parse down into the transport metadata. I would instead expect it the other way around - e.g., a variant of TCP-AO or UDP AUTH option that would cover the IP pseudoheader and transport headers, but not the transport payload. That could easily be defined as an endpoint-coordinated variant of either of those protocols, which don’t have in-band key/parameter negotiation for authentication anyway. [Linda] This is not a transport-layer solution like TCP-AO or UDP AUTH, which would typically cover both the transport header and payload. Instead, it complements these by providing lightweight authentication of the encapsulation headers used in overlay or tunnel scenarios. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com<http://www.strayalpha.com/> On Oct 28, 2024, at 4:39 PM, Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> wrote: Joe, The primary scenario for the proposed authentication method is from draft-ietf-rtgwg-multi-segment-sdwan where an additional header (GENEVE Encapsulation [RFC8926]) is added to the encrypted payload to steer packets through underlay networks. In these scenarios, the underlay network edge nodes do not decrypt and re-encrypt the payloads. The header information is used for optimizing packet forwarding in underlay networks and, therefore, resides outside the IPsec ESP header. It was pointed out that UDP option header can also use this proposed approach. We would like more feedback from the IPsecme community. Thanks, Linda From: Joe Touch <to...@strayalpha.com<mailto:to...@strayalpha.com>> Sent: Monday, October 28, 2024 1:26 PM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Cc: Tero Kivinen <kivi...@iki.fi<mailto:kivi...@iki.fi>>; Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>>; ipsec@ietf.org<mailto:ipsec@ietf.org> Subject: Re: [IPsec] Need 10 minutes slot at the IPsecme session Do you mean UDP? On Oct 28, 2024, at 1:20 PM, Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> wrote: IPsecme Chairs, We would like a 10minutes slot at the IPsecme session in IETF 121 to discuss this draft: https://datatracker.ietf.org/doc/draft-dunbar-secdispatch-ligthtweight-authenticate/ This document describes lightweight authentication methods to prevent malicious actors tampering with the IP encapsulation headers or metadata carried by the UPD Option Header. We revised the draft to address comments and suggestion during the offline discussion at IETF120. Would like to get more feedback from the IPsecme group of the revision. Thank you. Linda _______________________________________________ IPsec mailing list -- ipsec@ietf.org<mailto:ipsec@ietf.org> To unsubscribe send an email to ipsec-le...@ietf.org<mailto:ipsec-le...@ietf.org>
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
