[secdir] draft-livingood-woundy-p4p-experiences-10
"Scott G. Kelly" <scott@hyperthought.com> Tue, 30 June 2009 12:35 UTC
Return-Path: <secdir-bounces@mit.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 116113A6E55 for <secdir@core3.amsl.com>; Tue, 30 Jun 2009 05:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 OOCgbNU61nzt for <secdir@core3.amsl.com>; Tue, 30 Jun 2009 05:35:48 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 24F3E3A6C8E for <secdir@ietf.org>; Tue, 30 Jun 2009 05:35:47 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5UCZrRe011207 for <secdir@ietf.org>; Tue, 30 Jun 2009 08:35:53 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5UCZoHH011173 for <secdir@PCH.mit.edu>; Tue, 30 Jun 2009 08:35:50 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5UCZf7c014712 for <secdir@mit.edu>; Tue, 30 Jun 2009 08:35:41 -0400 (EDT)
Received: from smtp152.iad.emailsrvr.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id A0C4016575BC for <secdir@mit.edu>; Tue, 30 Jun 2009 08:35:36 -0400 (EDT)
Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by mit.edu with ESMTP id MzC2vmUECGmtXBrz (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for <secdir@mit.edu>; Tue, 30 Jun 2009 08:35:36 -0400 (EDT)
Received: from relay15.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 0E4D71B4092; Tue, 30 Jun 2009 08:35:36 -0400 (EDT)
Received: by relay15.relay.iad.mlsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id F16C41B4114; Tue, 30 Jun 2009 08:35:34 -0400 (EDT)
Message-ID: <4A4A0695.4000105@hyperthought.com>
Date: Tue, 30 Jun 2009 05:35:33 -0700
From: "Scott G. Kelly" <scott@hyperthought.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: secdir@mit.edu, iesg@ietf.org
X-Enigmail-Version: 0.95.7
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Cc: chris_griffiths@cable.comcast.com, richard_woundy@cable.comcast.com, yry@cs.yale.edu, alto-chairs@tools.ietf.org, laird@pando.com, jason_livingood@cable.comcast.com
Subject: [secdir] draft-livingood-woundy-p4p-experiences-10
X-BeenThere: secdir@ietf.org
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, 30 Jun 2009 12:35:49 -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. This is in informational document describing a technical trial of a proposed approach to peer-to-peer traffic flow improvement. Here's the security considerations section: "7. Security Considerations There are no security considerations in this document. NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO PUBLICATION." The current instructions to RFC authors are at http://www.rfc-editor.org/rfc-editor/instructions2authors.txt This document says "All RFCs must contain a section that discusses the security considerations relevant to the specification in the RFC; see [Secur03] for more information.", so the RFC editor is probably not going to remove this section. RFC 3552 (referenced as Secur03 above) gives further guidance. I believe that the mechanism proposed/described by the document certainly has security considerations, and any developers/deployers of such a protocol should do a thorough analysis as a fundamental element of the effort. However, since this document is an informational presentation of a study that was undertaken, it is probably most appropriate to simply state how security considerations were addressed. If security was entirely ignored (the network was assumed to be benign, messages between clients and trackers were sent in the clear with no authentication), it is probably important to explicitly say so. If security mechanisms were employed, then I think that a discussion of what threats were perceived and addressed might be helpful in interpreting the data. --Scott _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir
- [secdir] draft-livingood-woundy-p4p-experiences-10 Scott G. Kelly