At 6:24 PM +0000 12/7/09, Brian Swander wrote:
0 - option data does not change en-route. This option is
included in the WESP ICV computation.
We'll be using this flag, so this option will always be integrity protected.
integrity protected for checking by the end system, but not
verifiable by the intermediate system.
I'm not sure what you mean by effecting key distribution.
what I meant was that the intermediate system cannot verify the WESP data.
In the integrity only case, the intermediaries can still see into
the packet. In the fully encrypted ESP case, only the WESP
extension will be visible, and the intermediaries will have to trust
the end systems to do the correct marking.
And the end system will have to check another set of data, which may
be complex. A while ago I noted a vulnerability in a prior version of
WESP. Specifically, the (ultimate) recipient of the WESP packet has
to verify that the Next Header and the HdrLen fields are consistent
with the encapsulated content that it is processing. Othwewise, an
attacker could change these fields to make the packet acceptable to
an intermediate system but be different from what the recipient
processes.
This proposed extension would require that the recipient MUST also
verify that the data being made available to intermediaries for
packet inspection is consistent with the data being delivered as
IPsec output. At the current level of specification, this additional
processing is arbitrary. If I were a hardware IPsec vendor I would
worry about the possible implications of this sort of facility.
Steve
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
