[secdir] Sec-dir review of draft-ietf-tsvwg-source-quench-04

<kathleen.moriarty@emc.com> Mon, 23 January 2012 15:35 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4199E21F8687; Mon, 23 Jan 2012 07:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.5
X-Spam-Level:
X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwC8vmWe42I5; Mon, 23 Jan 2012 07:35:13 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 441B021F8683; Mon, 23 Jan 2012 07:35:12 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0NFZ4VV009818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 10:35:07 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 23 Jan 2012 10:34:44 -0500
Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0NFYhji028334; Mon, 23 Jan 2012 10:34:43 -0500
Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub35.corp.emc.com ([::1]) with mapi; Mon, 23 Jan 2012 10:34:43 -0500
From: kathleen.moriarty@emc.com
To: draft-ietf-tsvwg-source-quench.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Date: Mon, 23 Jan 2012 10:34:41 -0500
Thread-Topic: Sec-dir review of draft-ietf-tsvwg-source-quench-04
Thread-Index: AczZ5IYpMliT8QTVT+uEN1JM0Ads+Q==
Message-ID: <AE31510960917D478171C79369B660FA0E2BFCC535@MX06A.corp.emc.com>
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
X-EMM-MHVC: 1
Cc: fernando@gont.com.ar
Subject: [secdir] Sec-dir review of draft-ietf-tsvwg-source-quench-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 23 Jan 2012 15:35:14 -0000

Hello,

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.

The document is straightforward and well written.  I just have a couple of nits, but think the document is ready otherwise.

Suggest replacing 'must' with 'should' since the discussion is on interpretation.
Change from:
Receipt of an ICMP Source Quench message must not be interpreted as an attempt to attack the receiver.
To:
Receipt of an ICMP Source Quench message should not be interpreted as an attempt to attack the receiver.


It is already clear from the rest of the draft and this section, that there is no risk by ignoring ICMP source quench messages, which is done by 'virtually all current implementations of TCP'.   Should this say, virtually all current implementations of 'IP' or 'TCP' and 'ICMP'?   The discussion covers source quench being deprecated (RFC1812) by router implementations 20 years ago and now formally deprecates this within TCP.


Thank you,
Kathleen