[secdir] [New-work] WG Review: Port Control Protocol (pcp)

IESG Secretary <iesg-secretary@ietf.org> Tue, 27 July 2010 08:36 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 3D2D93A6A82; Tue, 27 Jul 2010 01:36:56 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 82AD93A6A82; Tue, 27 Jul 2010 01:36:55 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20100727083655.82AD93A6A82@core3.amsl.com>
Date: Tue, 27 Jul 2010 01:36:55 -0700
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Tue, 27 Jul 2010 01:54:27 -0700
Subject: [secdir] [New-work] WG Review: Port Control Protocol (pcp)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@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, 27 Jul 2010 08:36:56 -0000

A new IETF working group has been proposed in the Internet Area.  The IESG
has not made any determination as yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, August
3, 2010                            

Port Control Protocol (pcp)
Status: Under evaluation
Last updated: 2010-07-27


Internet Area Directors:
  Ralph Droms <rdroms.ietf@gmail.com>
  Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:
  Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
  General Discussion: pcp@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/pcp
  Archive: http://www.ietf.org/mail-archive/web/pcp/current/maillist.html

Description of the working group:

Middleboxes such as NATs and firewalls have seen significant deployment
in residential and enterprise networks for years. Applications have
adapted to such environments. A first family of solutions involves some
form of static configuration on the middlebox to perform port opening
and/or port forwarding. Another family of solutions works indirectly,
using external services to help the establishment of connections and
work around the NAT. STUN (RFC 5389) and TURN (RFC 5766) are examples of
such solutions. A third family of solutions include protocols that work
directly with the  middlebox to dynamically open up ports. Universal
Plug and Play Internet Gateway Device (UPnP-IGD) and NAT Port Mapping
Protocol (NAT-PMP) are examples of such solutions.

IPv4 address exhaustion is now forcing ISPs to deploy carrier-grade NAT
devices in their network. Those devices could operate either in addition
to or instead of an existing NAT device. An example of the former case
is a double NAT configuration and an example of the latter case is the
application of Dual Stack Lite (DS-Lite) in a network. These deployments
will break a fundamental assumption made by protocols, such UPnP or
NAT-PMP, that the NAT is located on the same link as the host running
the client application. As a result, such applications may break in the
presence of a carrier grade NAT.

The PCP working group is chartered to standardize a client/server Port
Control Protocol (PCP) to enable an explicit dialog with a middlebox
such as a NAT or a firewall to open up and/or forward TCP or UDP port,
regardless of the location of that middlebox. A PCP client can be used
by applications to directly dialog with the middlebox running a PCP
server. It can also be used by a home gateways on behalf of
applications. This eases the deployment of PCP in situations where
applications have already changed to support the APIs necessary for
communicating with UPnP-IGD or NAT-PMP. Those applications only work
today when the home gateway gets a public address, but may no longer
work in situations where the gateway is behind another NAT. Home
gateways could use PCP to translate and relay those UPnP and NAP-PMP
messages to the PCP server, thus allowing such applications to continue
working as they do today.

The functionality that enables the control of IPv4 middleboxes such as
NAT devices or firewalls can also be useful in IPv6 context, to control
IPv6 functionality in firewalls. As such, PCP will be defined for both
IPv4 and IPv6.

The discovery PCP servers, using classic methods such as DHCP options,
is in scope for the PCP working group. The working group will also
ensure that the protocol has the necessary security mechanisms. The
IETF will make no changes to either NAT-PMP or UPnP-IGP protocols,
and they will be used only as is.

- PCP protocol description and terminology document
- PCP service discovery document
- PCP relay of UPnP document
- PCP relay of NAT-PMP document

Goals & Milestones
- Oct 2010 First WG draft on PCP protocol description
- Dec 2010 First WG draft on PCP service discovery
- Feb 2011 First WG draft on UPnP relay
- Feb 2011 First WG draft on NAT-PMP relay
- May 2011 Send PCP protocol description to IESG for publication as 
Proposed Standard
- May 2011 Send PCP service discovery to IESG for publication as 
Proposed Standard
- Oct 2011 Send UPnP relay to IESG for publication as Proposed Standard
- Oct 2011 Send NAT-PMP relay to IESG for publication as Proposed 

New-work mailing list