Oh sigh!! What is it about IPsec that makes people go down this same path every time:
1) Someone proposes an utterly simple and useful piece of functionality (in this case, some way to indicate where the encapsulated data begins in the case where ESP is carrying unencrypted data. 2) The proposal is a little more complex than we might have hoped because we have to deal with forward migration (in this case, we can't add a new field to the ESP header - it was not extensible in this way - so we have to invent some new alternate header or a wrapper for the existing one). 3) Hoards of people propose minor improvements in the form of extensibility "infection sites" where future stuff can be added in a way that (if we're lucky) won't cause as much migration pain in the future if some similar extension is needed in the future. (In this case, we might want more information than the offset to the beginning of the plaintext data. Let's add a variable length header extension whose content is specified later. Oh, and the decision to put the "next protocol" field at the end of the ESP format instead of the front in order to maintain someone's idea of alignment turns out to be trouble, so let's put a copy at the front. Oh, and some of those fields we might want to specify someday might be security sensitive so let's change the integrity check to cover them. Oh, and we might want those extra fields we might want to specify someday to be added even for encrypted packets, so let's make the functionality that got this whole ball rolling optional!) 4) The resulting protocol is complex and misunderstood, and as a result it is incorrectly implemented by enough high profile vendors that any future extensibility based on the unused options will break them and in practice have to be done in some new and more horrible way. We're on step 3, debating whether to push on with something ugly or spend another year trying to make the thing simpler. Can anyone think of an example of where taking another year to make things simpler actually worked? And for those who think simplifying this will only slow it down by a few weeks, post the prediction to the list and I'll forward this note to you in a year and ask how things are going. Responding to Yaron's questions: [Yaron:] - 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? [CWK: ] If and only if it causes the process to complete faster. If we're going to have the option to add new options later, it makes sense to be able to integrity protect them. But it might make this a little harder to implement for some vendors. Neither of these arguments is important; I'd vote for whatever makes the debate end sooner. [Yaron: ] - 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. But arguably, it positions WESP as an alternative to ESP. Do you support this design decision? [CWK: ] If and only if it causes the process to complete faster. If we're going to have the option to add new options later, it makes sense to be able to apply those options to encrypted flows. But it makes the check in a middle-box for whether there is plaintext data in the packet more complex and implementations more complex (neither by very much). Neither of these arguments is important; I'd vote for whatever makes the debate end sooner. [CWK:] Unfortunately, I don't know what will make the debate end sooner. If history is any guide, neither decision will and we're just doomed. [CWK:] PROVE ME WRONG!! PLEASE!! --Charlie _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
