Yaron, On Tue, Jan 5, 2010 at 3:57 AM, Yaron Sheffer <yar...@checkpoint.com> wrote: > Hi, > > We have had a few "discusses" during the IESG review of the WESP draft. To > help resolve them, we would like to reopen the following two questions to WG > discussion. Well reasoned answers are certainly appreciated. But plain "yes" > or "no" would also be useful in judging the group's consensus. > > - The current draft > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11) defines > the ESP trailer's ICV calculation to include > the WESP header. This has been > done to counter certain attacks, but it means that WESP is no longer a simple > wrapper around > ESP - ESP itself is modified. Do you support this design > decision?
I had brought this up on the mailing list some time back that WESP now is not a mere "wrapper" over the ESP and is almost like a new protocol, which it anyways was designed to be. I dont see an issue with that. I dont hold a very strong opinion on whether we should include the WESP protocol header inside the ESP calculation or not and am also fine with the end nodes just doing a sanity check to ensure that things look alright when they receive the WESP protocol packets. > > - The current draft allows WESP to be applied to encrypted ESP flows, in > addition to the originally specified ESP-null. This was intended so that > encrypted flows can benefit from the future extensibility offered by WESP. And i strongly agree with this. It would be severely limiting to see WESP being only used for ESP-NULL cases. I see absolutely no harm in using WESP for encrypted traffic too. I agree with others on the list that by having WESP do encryption we provide the middle boxes with an easy/deterministic way to discriminate between integrity protected and encrypted packets, which is what we were chartered to do. I am not a big fan of flow based devices as these get really too hot to handle in scaled up networks and heuristics seems like a juvenile attempt at solving the problem. There have been various mails in the past about the issues in that scheme and i dont intend to rehash them here, so i'll this here. > But arguably, it positions WESP as an alternative to ESP. > It does not. ESP still has its own place and i dont see how having WESP ship ESP encrypted packets makes it a substitute of ESP. WESP will be required in the environments wherever we require deep inspection while ESP will continue where its not. > Do you support this design decision? Yes, i do. Jack > > Thanks, > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
