[pcp] UPDATED Protocol Action: 'Port Control Protocol (PCP) Authentication Mechanism' to Proposed Standard (draft-ietf-pcp-authentication-14.txt)

The IESG <iesg-secretary@ietf.org> Mon, 20 July 2015 12:03 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 114DE1A6FFD; Mon, 20 Jul 2015 05:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5XEOP5tS4L68; Mon, 20 Jul 2015 05:03:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C781A702F; Mon, 20 Jul 2015 05:03:41 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.4.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150720120341.3762.73178.idtracker@ietfa.amsl.com>
Date: Mon, 20 Jul 2015 05:03:41 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/ynlI1dFMSc0cU5xM8s9nhEgJFag>
Cc: pcp mailing list <pcp@ietf.org>, pcp chair <pcp-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [pcp] UPDATED Protocol Action: 'Port Control Protocol (PCP) Authentication Mechanism' to Proposed Standard (draft-ietf-pcp-authentication-14.txt)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 12:03:45 -0000

The IESG has approved the following document:
- 'Port Control Protocol (PCP) Authentication Mechanism'
  (draft-ietf-pcp-authentication-14.txt) as Proposed Standard

This document is the product of the Port Control Protocol Working Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:

Technical Summary:

   An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
   flexibly manage the IP address and port mapping information on
   Network Address Translators (NATs) or firewalls, to facilitate
   communication with remote hosts.  However, the un-controlled
   generation or deletion of IP address mappings on such network devices
   may cause security risks and should be avoided.  In some cases the
   client may need to prove that it is authorized to modify, create or
   delete PCP mappings.  This document describes an in-band
   authentication mechanism for PCP that can be used in those cases.
   The Extensible Authentication Protocol (EAP) is used to perform
   authentication between PCP devices.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there 
controversy about particular points or were there decisions where the consensus
was particularly rough? 

   There is strong consensus to use an EAP-based mechanism for security.
   There was, however, significant controversy about whether to use PANA.
   A consensus call was done on the list, and (rough) consensus was called by
   by the chairs in close cooperation with the responsible AD, following the
   advice outlined in what is now RFC 7282.  The chairs reported the results
   at IETF 87, with slides at
   where rough consensus was declared for not using PANA.

Document Quality:

Are there existing implementations of the protocol? Have a significant number 
of vendors indicated their plan to implement the specification? Are there any 
reviewers that merit special mention as having done a thorough review, e.g., 
one that resulted in important changes or a conclusion that the document had 
no substantive issues?

    There is at least one implementation of this protocol, and eventually
    more are expected.  Many individuals have reviewed various versions
    of this document over a long period of time.


Who is the Document Shepherd? 

    Dave Thaler <dthaler@microsoft.com>

Who is the Responsible Area Director? 

    Brian Haberman <brian@innovationslab.net>