[speaking as individual] On Wed, Nov 23, 2022 at 9:32 AM Daniel Migault <[email protected]> wrote:
> I agree but in my opinion the draft has some scalability limitation and to > be useful needs to be combined with something else > That is not true. Perhaps for your use case, but not other people's use cases, such as highspeed (eg 10gbs+) DC interconnects with devices with multiple CPUs. It is very much "useful" without "something else" as we presented in the past with our benchmarks. - at least this is my understanding. Maybe I am biased as the use case it > may address is not the one we have. Do not get me wrong, I think the work > has been useful and should be documented. But I think that the alternative > that limits the number of SA is very attractive, especially for our > hardware implementations with a limited number of SA. > That is a very different use case. I agree that the advantage of the draft is that it is a very ow > hanging fruit but on the other hand - at least as I see it - > -ponchon-ipsecme-anti-replay-subspaces provides a complete solution to the > scalability concern we have. > See my previous posting to the list. There might be IPR issues to address first before a solution like that draft can be adopted to the WG. Regardless, it is a different solution that does change the security properties and the Child SA properties. I believe this work does fall under the "ESP update" work, independently of this draft, that requires no update to ESP. I agree ESP-v4 should be considered natively, but I would like > -ponchon-ipsecme-anti-replay-subspaces to be implemented with the current > ESP mostly so we do not wait ESP-v4 to have it. Actually at Ericsson we > would like to implement the standard version of > -ponchon-ipsecme-anti-replay-subspaces in a reasonable delay -- i.e. next > year. > Provided the IPR issues are resolved, the WG surely can look at this. Although as has been pointed out, if anti-reply is your only issue, then perhaps the easiest thing to deploy right now would be ESP without replay protection enabled? And trust that the application layer (TCP, QUIC, UDP applications) handle out-of-order or duplicate packets themselves. To clarify my position I am not opposed to the adoption of the draft. My > position is that it gets published as soon as possible as an experiment > that paves the way for a more complete solution. In other words, I think we > should not have the document being discussed for years in the WG. > That is generally true for every document in every WG :) I think people in the WG have shown that there is some urgently to addressing ESP performance issues. But the WG is all of us, so all of us need to keep the speed going on this. I think it would be good to get a problem statement doc out as Steffen indicated, so that we know all the issues we want to address in ESP. Paul
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
