Hi, Linda, Notes below.
Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Nov 4, 2024, at 2:06 AM, Linda Dunbar <linda.dun...@futurewei.com> wrote: > > Joe, > > Thank you very much for the comments. Please see below the detailed reply: > > Linda > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > <to...@strayalpha.com <mailto:to...@strayalpha.com>> > Sent: Thursday, October 31, 2024 12:31 AM > 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 > > 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: > there are stacks of protocols used for tunnels > [Linda] “Stacks of Protocols”: do you mean layers of encapsulation headers on > the data plane? Yes. > > 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. [JT] The assertion is clear, but evidence is what I suggested would be useful. Many security protocols have hardware acceleration that may not be able to identify and isolate headers (and, for UDP options, trailers). In other cases, per-packet operations may dominate vs. per byte costs. In either case, it would be useful to provide some evidence of this claim. > 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. [JT] OSI protocol layer identifications are relative, not absolute (they always have been; we’ve been aware of this since the late 1990s). When TCP or UDP is used to encapsulate IP, those protocols act as link layers to that IP packet. TCP-AO and UDP AUTH both cover their layer’s endpoint association, which includes the TCP/UDP header/trailer and also the IP pseudoheader. In both cases, parameters are determined outside the protocol. Either could be defined with a parameter indicating the payload would be excluded from the authentication computation, just as TCP-AO-NAT (rfc 6978) does by excluding the source IP address and TCP port. Joe > > 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
