From: Russ Housley<hous...@vigilsec.com>
To: "Bhatia, Manav"<manav.bha...@alcatel-lucent.com>
Cc: ipsec@ietf.org; i...@ietf.org
Sent: Tue, December 29, 2009 6:32:54 AM
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Manav:
I am unconvinced. If a malicious attacker is willing to alter packets to fool
middleboxes, this ICV does not help the middlebox and it harms the end system.
The middlebox cannot validate the ICV, and the end system does not need the WESP
header information. The end system does not need the pointer data in the WESP
header to process the packet correctly; it already knows the size of the IV and
other values associated with the algorithms in use. Thus, the ICV protection
imposes a requirement that the end system check the WESP information that it
does not need, and then discard the packet if the attacker altered it to the
potential detriment of the middlebox.
Russ
At 09:36 PM 12/28/2009, Bhatia, Manav (Manav) wrote:
Yes, this was discussed in the WG
(http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104) and the idea was this:
We could have some malicious entity that could modify the offsets to ensure
that the intermediaries don't parse a portion of the payload (which could
contain malicious content) or inspect it differently than what it would have
done otherwise. A way to protect against such attacks is to let the end node
validate the WESP header by including this as a part of the ESP ICV. If the
computed ICV does not match, the packet is dropped (usual IPSec processing).
This does not completely eliminate the vulnerability, but it does raise the
bar, because now the malicious routers would have to also position themselves
both before and after the middle boxes in order to have a chance to revert the
packet back to its original form before the end node verifies integrity over the
packet.
We have also discussed this in the Security Considerations section of the
draft.
We did informally speak to HW guys who are interested in implementing WESP,
and they confirmed that increasing the integrity protection of ESP to now cover
the WESP header is trivial.
Cheers, Manav
-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
On Behalf Of Jack Kohn
Sent: Tuesday, December 29, 2009 6.17 AM
To: Stephen Kent
Cc: ipsec@ietf.org; Russ Housley; i...@ietf.org; Dan McDonald
Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility
Are you suggesting that ESP ICV should not cover the WESP fields?
I think, and my memory could be failing me, that this was discussed in
the WG before this got added to the draft.
Jack
On Tue, Dec 29, 2009 at 2:15 AM, Stephen Kent wrote:
Yaron,
I hate to admit it, but I lost track of the details of WESP
as it progressed
through WG discussions and briefings at IETF meetings. When
I read the I-D
in detail, I was very surprised to see that it was no longer a
neatly-layered wrapper, as originally proposed. The fact
that it now calls
for the ESP ICV to be computed in a new fashion means that
it really is
replacing ESP, when used to mark ESP-NULL packets.
From a protocol design perspective, the current version
makes no sense to
me. Why keep the ESP header when ESP processing is now changed in a
significant way. The WESP header cannot be processed
(completely) by
itself, because of the dependence on the ESP ICV. So it
makes little or no
sense to retain the ESP header in this context. I see no
strong backward
compatibility motivation for this format, given that ESP
processing must
change to accommodate WESP (as defined).
The issue of using WESP for marking encrypted traffic is a
separate topic. I
believe the rationale you cited was to enable WESP
extensions, but I may
have missed other arguments put forth for this. Since most
of the WESP
extension proposals discussed so far have proven to be
questionable, I am
not enthusiastic about that rationale. Others have noted
that using WESP
with encrypted traffic is not consistent with the scope of
the WG charter
item that authorized work on WESP. Unless Pasi approves a
WESP extension WG
item as part of re-chartering, I think it is inappropriate
to have a flag to
mark a WESP payload as encrypted.
Steve
