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: a) there are stacks of protocols used for tunnels b) it can be useful to protect just those added protocol layers (which for UDP would include the trailing options).
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. 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. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Oct 28, 2024, at 4:39 PM, Linda Dunbar <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
