[secdir] Review of draft-ietf-ipsecme-traffic-visibility-11
Sean Turner <turners@ieca.com> Tue, 08 December 2009 23:54 UTC
Return-Path: <turners@ieca.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA98B3A694E for <secdir@core3.amsl.com>; Tue, 8 Dec 2009 15:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
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 D9UHvVMq6zf9 for <secdir@core3.amsl.com>; Tue, 8 Dec 2009 15:54:37 -0800 (PST)
Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by core3.amsl.com (Postfix) with SMTP id 604813A6915 for <secdir@ietf.org>; Tue, 8 Dec 2009 15:54:20 -0800 (PST)
Received: (qmail 72457 invoked from network); 8 Dec 2009 23:54:07 -0000
Received: from pool-96-241-2-70.washdc.east.verizon.net (turners@96.241.2.70 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 08 Dec 2009 15:54:07 -0800 PST
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: 2cNCgI0VM1kIbABlt8mQeFzOzBQmc05ZQzw0Z4ZvPcplrejkD57JvpYHjT6jRLR7zikbdEfFK1W.bkTTec3E8xwIdv4CagAh0pH9i6jCX6rik7cw8NdzkLJEqlKJ2q8K76kyhp93TITnI09p7grih0GXPpoAttTS0msp5ZovAttEfihb9EX6LF1leuY9WBAmoO8L6a5smYmRUqV89vZKfdKtEXutDEK7w5pzwo2GIsm8s.AWcfRXtKzZC1GGnHzJxGYUTdWLZJhIiXJpxzXRR.xJoXwWPgLdtyDft8Tk_T.DwK2IMdRObh0_YU9E4.h4OJmXMWzTy0kARw5ohM.MT5GIyxqoiX4.vjsvgp1SySz6EOqjPC5wIICpO.d8O4.45agqaHvpgI.YUHTteQc2TVzDL9bUzWzanu29.vuK7tzc
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4B1EE71E.1040704@ieca.com>
Date: Tue, 08 Dec 2009 18:54:06 -0500
From: Sean Turner <turners@ieca.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: secdir <secdir@ietf.org>, draft-ietf-ipsecme-traffic-visibility.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] Review of draft-ietf-ipsecme-traffic-visibility-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2009 23:54:38 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document Abstract: This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303], and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP and if not, (2) inspect the IPsec packets for network monitoring and access control functions. I don't have any comments on the technical contents of the ID. But, I do have a comment w.r.t. the approach.* It seems to me that what you're looking for is an indication early on that the coming packets are encrypted or not. Don't we already have that with the 50/51 value in the protocol header (IPv4, IPv6, or Extension) immediately preceding the ESP/AH header. Why don't we use that as the indication, prohibit those NULL encryption algorithms, and then we're done? We don't have to worry about implementing this protocol, the heuristics algorithm in the other I-D, and we don't have to complicate the adoption of ESP/AH? spt * The only rationale I saw was in the 3rd paragraph of the introduction that says AH doesn't work in NAT environments. Is that really the entire reason? I thought we were trying to kill NATS?
- [secdir] Review of draft-ietf-ipsecme-traffic-vis… Sean Turner
- Re: [secdir] Review of draft-ietf-ipsecme-traffic… Gabriel Montenegro
- Re: [secdir] Review of draft-ietf-ipsecme-traffic… Bhatia, Manav (Manav)