[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