[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.