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
