IETF Logo Mail Archive

Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility

Yaron Sheffer <yaronf@checkpoint.com> Mon, 21 September 2009 12:39 UTC

Return-Path: <yaronf@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC393A67A7 for <ipsec@core3.amsl.com>; Mon, 21 Sep 2009 05:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level:
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jSAm7sIOrtf for <ipsec@core3.amsl.com>; Mon, 21 Sep 2009 05:39:26 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0FF6A3A6765 for <ipsec@ietf.org>; Mon, 21 Sep 2009 05:39:25 -0700 (PDT)
X-CheckPoint: {4AB77355-0-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DCBB329C005; Mon, 21 Sep 2009 15:40:21 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A836329C002; Mon, 21 Sep 2009 15:40:21 +0300 (IDT)
X-CheckPoint: {4AB77352-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n8LCeKSr013262; Mon, 21 Sep 2009 15:40:21 +0300 (IDT)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 21 Sep 2009 15:40:20 +0300
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Tero Kivinen <kivinen@iki.fi>, "Grewal, Ken" <ken.grewal@intel.com>
Date: Mon, 21 Sep 2009 15:40:19 +0300
Thread-Topic: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
Thread-Index: Aco6rJ+rooaEqEx0Q9OT1l/HPaUjqwACB6Bg
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328491@il-ex01.ad.checkpoint.com>
References: <808FD6E27AD4884E94820BC333B2DB773C06B22D72@NOK-EUMSG-01.mgdnok.nokia.com> <C49B4B6450D9AA48AB99694D2EB0A483325793BA@rrsmsx505.amr.corp.intel.com> <19127.24553.76610.294336@fireball.kivinen.iki.fi>
In-Reply-To: <19127.24553.76610.294336@fireball.kivinen.iki.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>
Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 12:39:27 -0000

Hi Tero,

Given that the existing ESP header is integrity-protected, I don't see the downside to adding the same protection for the new header. On the other hand, this would eliminate a whole class of vulnerabilities. We still have a few reserved bits in the WESP header, and you don't want to find out years down the road that they cannot be used because they're not protected in transit.

Thanks,
	Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
> Tero Kivinen
> Sent: Monday, September 21, 2009 14:14
> To: Grewal, Ken
> Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com
> Subject: Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-
> visibility
> 
> Grewal, Ken writes:
> > >- A question: did the WG discuss the pros and cons of integrity
> > >protecting the WESP header? (This does make WESP more complex to
> > >implement, and currently the WESP header does not contain any data
> > >that would benefit from integrity protection in any way.)
> > [Ken] This change was the result of a discussion on threats posed by
> > 'malware', which could modify the WESP headers to obfuscate the
> > payload from inspection by intermediate nodes such as IDS/IPS
> > systems.
> > The issue (ticket #104) was raised and closed some time back after
> > lengthy discussions on the topic.
> > http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104
> 
> As everything in the WESP header is something that can be verified by
> the recipient node why is the integrity protection needed?
> 
> I think it would make implementation WESP much easier if it can be
> done as post processing step after ESP has been applied, in a similar
> way UDP encapsulation can be done to the ESP packet.
> --
> kivinen@iki.fi
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

Email secured by Check Point

Email secured by Check Point

v2.29.0 | Report a Bug | By Email | System Status