Re: [tcpm] [OPSEC] draft-gont-tcp-security

Lars Eggert <lars.eggert@nokia.com> Wed, 15 April 2009 15:13 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDDB3A697A; Wed, 15 Apr 2009 08:13:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 vrCEKjYZpM46; Wed, 15 Apr 2009 08:13:22 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 848423A6944; Wed, 15 Apr 2009 08:13:21 -0700 (PDT)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3FFEDg4046102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2009 18:14:14 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: Todd Glassey <tglassey@earthlink.net>
In-Reply-To: <49E5F36D.7020808@earthlink.net>
Content-Type: multipart/signed; boundary="Apple-Mail-8--491751556"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 15 Apr 2009 18:14:13 +0300
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g ov><49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu> <C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com> <49E5F36D.7020808@earthlink.net>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Wed, 15 Apr 2009 18:14:15 +0300 (EEST)
Cc: "'tcpm@ietf.org'" <tcpm@ietf.org>, "'ietf@ietf.org'" <ietf@ietf.org>, Joe Touch <touch@ISI.EDU>, "Smith, Donald" <Donald.Smith@qwest.com>, 'Joe Abley' <jabley@ca.afilias.info>, "'opsec@ietf.org'" <opsec@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Apr 2009 15:13:23 -0000

Hi,

On 2009-4-15, at 17:47, Todd Glassey wrote:
> Lars Eggert wrote:
>> Nothing would be "tested", the IETF isn't in the business of auditing
>> TCP stacks.
> Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify -
>
> Don't the IETF standards processes "require the development of two or
> more independent implementations of any given protocol specification  
> and
> the associated interoperability testing to document that the suite  
> runs
> as advertised in the specification?"

this is required when moving from Proposed Standard to Draft Standard.  
(Also, what RFC are you quoting in the previous paragraph?) This  
doesn't apply to the document we're discussing here, because:

>> What we're talking about is describing attack vectors, potential
>> countermeasures and the the impact (downsides) those countermeasures
>> might come with. Implementors will need to decide for themselves if
>> and how to apply any of these techniques to their stacks.
> Which would be filed as a Use Case Document as a set lf BCP's for a
> protocol stanadard. This by the way is where the real value of the  
> IETF
> comes in - in also telling people how to and how not to use these  
> protocols.

Yes, it is likely that whatever the outcome is, the document would be  
published as Informational or BCP.

Lars