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 <k...@bbn.com> 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
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
