[secdir] secdir review of draft-ietf-pcp-base

"Dan Harkins" <dharkins@lounge.org> Wed, 29 February 2012 19:46 UTC

Return-Path: <dharkins@lounge.org>
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 3DA0F21F87FC; Wed, 29 Feb 2012 11:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.645
X-Spam-Level:
X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 B6C+KxqASAri; Wed, 29 Feb 2012 11:46:05 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BB96521F87D5; Wed, 29 Feb 2012 11:46:05 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 810A81022404A; Wed, 29 Feb 2012 11:46:05 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 29 Feb 2012 11:46:05 -0800 (PST)
Message-ID: <abbfc1b88426c9b3afad1be54d9f6acf.squirrel@www.trepanning.net>
Date: Wed, 29 Feb 2012 11:46:05 -0800
From: Dan Harkins <dharkins@lounge.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-pcp-base.all@tools.ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [secdir] secdir review of draft-ietf-pcp-base
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: Wed, 29 Feb 2012 19:46:06 -0000

  My apologies for the tardiness of this review. The tracker says
it's on the agenda for the next telechat so maybe this isn't completely
useless.

  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 draft describes a simple request/response protocol to create
and manage mappings on upstream devices (like NATs) to control how
incoming packets get forwarded. It defines two threat models (a simple
one and an advanced one) that seem reasonable for the different use
cases. The Security Considerations are well-written and address all
attacks I could think of. The draft is very well-written and complete.

  PCP has a THIRD_PARTY option in which a PCP client can create a
mapping on a PCP server for a different device. This has the potential
for abuse. The implications of this option are mentioned somewhat in
passing in the section that describes the option ("Determining which PCP
clients are authorized to use the THIRD_PARTY Option for which other
hosts is deployment-dependent....A cryptographic authentication and
authorization model is outside the scope of this specification") but
it would be nice if they were addressed a bit more in the Security
Considerations section. It would be nice to see mention of:

  a) what capabilities should a PCP server have to properly address
     authorization of requests that include the THIRD_PARTY option; and,
  b) what are the implications of enabling the THIRD_PARTY option on a
     PCP server? In other words, what does a user need to understand
     before he enables it?

I understand that this is a very tardy request, my apologies again, so I
understand if this comment is not resolved.

  regards,

  Dan.