Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visibility

From: gabriel montenegro <[email-masked]>
Date: Tue, 5 Jan 2010 11:32:36 -0800 (PST)

Hi Russ,

I'd like to comment on your assumption below that:

> ...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"

The underlying assumption seems to be that the end nodes do not need to carry out
any consistency checks. This contradicts the operating assumption we've been operating
under, as expressed by Steve Kent last May 12:

http://www.ietf.org/mail-archive/web/ipsec/current/msg04359.html:

If we elect to keep the next header field, to help middle boxes quickly locate header fields of interest to them, then we MUST require the recipient of each message to do a (well-defined) consistency check on the packet, for the reasons I cited in SF. 

and as discussed in San Francisco minutes at:
http://tools.ietf.org/wg/ipsecme/minutes?item=minutes74.html

One may argue whether that consistency check is best served by extending the ICV to include the
WESP header fields (per the current WG consensus as expressed in the existing draft), or whether
that is best done by the end nodes checking the fields explicitly. 

Gabriel

----- Original Message ----
> From: Russ Housley <[email-masked]>
> To: "Bhatia, Manav" <[email-masked]>
> Cc: [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> > > On Behalf Of Jack Kohn
> > > Sent: Tuesday, December 29, 2009 6.17 AM
> > > To: Stephen Kent
> > > Cc: [email-masked]; Russ Housley; [email-masked]; 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
> > > > _______________________________________________
> > > > IPsec mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/ipsec
> > > >
> > > _______________________________________________
> > > IPsec mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> > _______________________________________________
> > IPsec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Russ Housley <[email-masked]>
Date: Tue, 05 Jan 2010 16:21:19 -0500

Gabriel:

My point is that the end system does not need the information in the 
WESP header to properly handle the packet for the supported 
application.  The additional information is being exposed to allow 
middle boxes to make various checks.  The end system can ensure that the 
exposed information was correct so that middle boxes were not spoofed.  
An extended ICV is not necessary to perform this type of check if the 
information is limited to the payload offset and such.  An ICV is only 
needed if WESP carries information that cannot be easily checked by a 
process that knows the crypto algorithms that are in use.  I'm 
challenging the need for such information.

Russ

On 1/5/2010 2:32 PM, gabriel montenegro wrote:
>> From: Russ Housley<[email-masked]>
>> To: "Bhatia, Manav"<[email-masked]>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 6 Jan 2010 09:16:58 +0530

Hi Russ,
 
> challenging the need for such information.

One use case could be when you want to prioritize processing certain ESP-NULL packets (most routing applications for instance mandate the use of ESP-NULL as routing is not concerned with confidentiality) over the other. The HW computes the ICV, determines everything is correct and hands over the packet to the IPSec engine. The IPSec engine, briefly inspects the WESP header (and it knows its correct because it passed the preliminary ICV validation check) and looks at the right offsets and depending upon the kind of packet it is, places it in the appropriate queue. With WESP the HW knows the exact offsets it has to look at to figure out the information it needs and can be done in the fast path. 

OTOH, if we don't include the WESP header in the ICV, then the IPSec engine has to process each packet completely, verify that the WESP header is indeed correct and matches with whats carried inside the packet, before it can do any further processing. This can take up some time, which may be an issue for applications that need faster processing (a protocol like BFD for instance).

I currently don't see applications that may need this kind of expedited processing, but the WESP design should not preclude development of such applications/features.

However, if folks feel very strongly about not including WESP fields in the ICV, then I would take a back seat and grudgingly concede to it ..

Cheers, Manav

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jan 2010 20:07:51 -0800

Kind-of wearing my co-chair hat:

>I currently don't see applications that may need this kind of expedited processing, but the WESP design should not preclude development of such applications/features.

We have heard a number of statements like this. Please note that WESP was designed for one purpose (making ESP-NULL easier to find) and then the WG realized that we could make it extensible. The latter may be nice, but it should not drive our work unless there is a use case that has stronger-than-rough WG consensus. Nothing precludes us from having both WESP and adding an extensibility mechanism later when there are agreed-on needs.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jan 2010 09:39:33 -0500

Gabriel,

>...

My reply to Ken addresses the issue you raise about the need for 
consistency checks.  I don't think there is a misunderstanding here. 
The I-D calls for such checks and I agree that they are the right 
thing to do. What is at issue, in part, is whether the ESP ICV should 
have been extended to cover the WESP header.  My view, and that of 
several other folks, is that it should not have been done, for the 
reasons I cited previously. This aspect of the current I-D could be 
fixed by having WESP have NO ICV, of by having WESP include its own 
ICV, which would call for nested processing by hosts. As I explained 
in my reply to Ken, extending the ESP ICV does not achieve the same 
effect, so this is not an "either or" situation.

On a broader note, as Paul and Russ noted, the IESG gets to decide 
whether a WG-approved I-D will be published as an RFC (modulo appeals 
to the IAB, etc.). The IETF last allows anyone, even members of the 
WG that approved an I-D, to raise questions that the IESG will 
consider as part of the approval process. I've had over 15 years of 
experience as a WG chair (opening for Paul to make a snide comment 
:-)) and I have had WG members raise questions during IETF LC, after 
WG consensus has been achieved. This is how our process works. Also, 
even in the face of WG consensus, an AD may request changes to a 
document. This is not uncommon. when this has happened in the PKIX 
context, the Wg chairs and document authors have discussed the 
requested changes with the AD and we have almost always made the 
changes.  Sometimes this has required another WGLC.

Steve