Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt

Joe Touch <touch@ISI.EDU> Tue, 16 February 2010 17:52 UTC

Return-Path: <touch@ISI.EDU>
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 9DF4728C17F; Tue, 16 Feb 2010 09:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 nAbH6B9mRI1t; Tue, 16 Feb 2010 09:52:03 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 67E7A28C100; Tue, 16 Feb 2010 09:52:02 -0800 (PST)
Received: from [75.215.203.205] (205.sub-75-215-203.myvzw.com [75.215.203.205]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1GHpw4i009428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Feb 2010 09:52:01 -0800 (PST)
Message-ID: <4B7ADB3E.2060308@isi.edu>
Date: Tue, 16 Feb 2010 09:51:58 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <a123a5d61002121827y2f2b0256u5859790c06819a92@mail.gmail.com> <4B79A54C.7040107@gont.com.ar><4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar><4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigEDEC4ACB695A9B50B6227374"
X-MailScanner-ID: o1GHpw4i009428
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Phillip Hallam-Baker <hallam@gmail.com>, Fernando Gont <fernando@gont.com.ar>, secdir@ietf.org
Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt
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, 16 Feb 2010 17:52:04 -0000


Anantha Ramaiah (ananth) wrote:
>  
> 
>> -----Original Message-----
>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
>> Behalf Of Joe Touch
>> Sent: Tuesday, February 16, 2010 8:44 AM
>> To: Fernando Gont
>> Cc: tcpm@ietf.org; Phillip Hallam-Baker; secdir@ietf.org
>> Subject: Re: [tcpm] SECDIR REVIEW of 
>> draft-ietf-tcpm-icmp-attacks-10.txt
>>
>>
>>
>> Fernando Gont wrote:
>> ...
>>> Anyway: For the most part I'm wondering if there's any 
>> additional text 
>>> needed to address Phillip's comments. Thoughts? This should be our 
>>> focus at this point in time.
>> There were two separate points raised, IMO:
>>
>> - clarification of the role of this doc's recommendations
>> 	The WG was aware of this issue, and there was
>> 	a lot of effort in creating the existing text that
>> 	already considered this perspective. No change needed.
> 
> I would still think there is some text needed which explains (in a
> sentence or two) the role of this documents recommendations. Atleast
> explain why the target was chosen to be "informational" at this point of
> time. Would help a lot of readers/implementers down the line since this
> question would keep coming. But that's just me, if the consensus is to
> not add anything I am fine too.

The role is basically limited to 'documenting what is deployed', which
is summarized fairly directly in the abstract.

The specific recommendation made towards the end of the intro reiterates
that.

I.e., this is not a new issue, and it's something for which there is
specific text already.

I think it answers the mail on that point.

Joe