Steve, The either-or on using an ICV or explicitly checking the WESP header on the recipient was based on the assumption that the threat does not come from the sender and only from some other malicious entity after the packet has been sent. This was the reason for simplifying the header check by using the ICV, instead of explicitly checking every field.
If the sender is malicious, then an encrypted (covert) channel is all that is needed to bypass any intermediate checking and furthermore, any explicit checking of each WESP field on the recipient does not help, as the payload can contain whatever is intended by the malicious sender! We did debate this a number of times and extending the integrity appears as early as May of last year in version 3 of the draft (at version 12 now), so it should not have been a surprise at last call. In either case, as Gabriel indicates in a separate email, if it makes sense to go back to not integrity protecting the WESP header, I am fine with that. This was the original position and aligns with your other email on WESP acting as a wrapper to ESP, and should also address other comments indicating that the name Wrapped ESP is a misnomer! Thanks, - Ken >-----Original Message----- >From: Stephen Kent [mailto:k...@bbn.com] >Sent: Wednesday, January 06, 2010 6:28 AM >To: Grewal, Ken >Cc: Yaron Sheffer; ipsec@ietf.org >Subject: Re: [IPsec] Traffic visibility - consensus call > >At 11:14 AM -0700 1/5/10, Grewal, Ken wrote: >>Yes to both, based on arguments already discussed numerous times in >>the WG via presentations, 12 iterations of the draft and multiple WG >>last calls + AD reviews! >> >>The main motivation for extending the ICV was to counter some of the >>issues originally raised by Steve Kent - malicious entities >>modifying portions of the WESP header to bypass legitimate parsing >>of the packet by Trusted Intermediary (TI) devices such as >>IDS/IPS/etc. This can be addressed by the recipient explicitly >>validating the WESP header before accepting the packet or implicitly >>by including the WESP header as part of the ICV check. > >My recollection is that I identified a vulnerability that arose >because of the potential for a mismatch between what a TI checked and >what the receiver acted upon, irrespective of how that mismatch >arose. I think I suggested that this vulnerability might be remedied >by requiring the receiver to verify that the WESP header info was >consistent with what the receiver was acting upon, as part of WESP >processing. The current I-D calls for this check to be performed by >the recipient. Above you state that: > >"This can be addressed by the recipient explicitly validating the >WESP header before accepting the packet or implicitly by including >the WESP header as part of the ICV check." > >I disagree with the "or" in this sentence, for two reasons. First, >the I-D calls for the receiver to perform the consistency check, so >it's not an "or." Second, >it would not suffice to perform JUST the ICV check you described, >since that would not address the possibility that the sender created >the misleading WESP header. > >>The motivation for allowing WESP to be used for encrypted data was >>brought up as a consistency argument and also allows for future >>extensibility in a uniform manner. I agree that this was not part of >>the original charter, as shown in the earlier revisions of the WESP >>drafts. > >It appears that we agree that it was out of scope (although others do >not), and that the principle motivation cited was to allow for >extensions. The phrase :in a uniform manner" is, I believe, shorthand >for extensions that apply to encrypted traffic, right? > >>BUT, this was discussed numerous times within the WG (including an >>open ticket on scope) and it was agreed that this would be a useful >>bit to include in the flags, hence introduced in the latter >>revisions of the draft. > >I have already admitted that I lost track of this aspect of the >discussion, among all of the ticket items that the WG has processed. >(BTW, I congratulate Paul and Yaron for doing a very good job of >managing such a large number of issues in a detailed fashion. The >fact that I, and maybe a few other folks, lost track of the details >on one of the many items being worked is not a reflection on the >management style that have employed.) > >When I re-read the I-D during IETF last call, I was surprised to >learn that ESP processing had been changed, so cause the ICV to >cover non-ESP fields. This seems to be unnecessary and it is a bad >design, in my opinion. > >>Note that this does not mandate using WESP for encrypted traffic, >>but allows it as optional and can be dictated as part of the session >>setup based on local policy. Another benefit may be that in running >>mixed mode environments (encrypted + ESP_NULL traffic), it allows >>for an explicit distinction from the packet that certain traffic is >>encrypted and other traffic is not. Otherwise, one would use ESP and >>WESP in these mixed mode environments and to be absolutely sure if >>ESP traffic is encrypted or not, would need to fall back to >>heuristics, which somewhat defeats the object of having this spec. > >If local policy can be used to dictate whether WESP is or is not used >for encrypted traffic, then that policy also can dictate that ESP is >used only for encrypted traffic. Even in an environment where some >but not all hosts support WESP, I don't see the need for this flag. A >host that is WESP capable need not use WESP for encrypted traffic; it >can use ESP. if so, then ITs see three classes of traffic: > - encrypted using ESP > - integrity-protected using WESP > - integrity-protected using ESP > >The third class of traffic poses a problem for the ITs, but adding >the encrypted flag to WESP does not seem to address that problem. > >Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
