[Gen-art] Gen-ART review of draft-ietf-pcp-base-23

Richard Barnes <rbarnes@bbn.com> Mon, 27 February 2012 13:11 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 412D321F8682 for <gen-art@ietfa.amsl.com>; Mon, 27 Feb 2012 05:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.516
X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id myH-T2WFqbgX for <gen-art@ietfa.amsl.com>; Mon, 27 Feb 2012 05:10:45 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0A40F21F8684 for <gen-art@ietf.org>; Mon, 27 Feb 2012 05:10:44 -0800 (PST)
Received: from [] (port=57158) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1S20Lf-000EA9-Tm; Mon, 27 Feb 2012 08:10:40 -0500
From: Richard Barnes <rbarnes@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Feb 2012 18:40:35 +0530
Message-Id: <199ACCDB-1B9A-4C44-BEB6-BCE9253513CB@bbn.com>
To: gen-art@ietf.org, draft-ietf-pcp-base@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
Subject: [Gen-art] Gen-ART review of draft-ietf-pcp-base-23
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2012 13:11:01 -0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pcp-base-23.txt
Reviewer:  Richard Barnes 
Review Date:  27 Feb 2012
IETF LC End Date: 27 Feb 2012
IESG Telechat Date: 01 March 2012

Summary: Almost ready

Major issues:

-- As I think others have noted during LC, it seems like it would simplify several aspects of the protocol if requests and responses could be correlated by means of a transaction identifier, instead of just by matching fields.  In addition to simplifying response processing and clarifying the meaning of lifetime parameters, this would also provide a measure of protection against address spoofing.

-- It would be helpful for the document to say a little more about risks posed from spoofed packets.  It seems like there are some cases where an off-path attacker could break synchronization in state between clients and servers, e.g., by sending gratuitous responses.  This is a rather serious attack, as it could be used by an off-path attacker to steal traffic:
1. Attacker obtains mapping from address:port=A:P on PCP controlled device to one of its ports B:Q
2. Attacker convinces client that it has a mapping from A:P to its port C:R
3. Attacker acts as a man in the middle: remote -> A:P -> B:Q -> C:R
Also, it seems the ANNOUNCE method provides an opportunity for an attacker capable of spoofing to cause an arbitrary number clients to flood the server with requests.

Minor issues:

-- The document says that v4-mapped addresses are not used as source or destination addresses for real IPv6 packets.  This is empirically not the case; in some work we have done on IPv6 traceroute scanning, we have encountered numerous routers that will respond from v4-mapped addresses.  It probably would be accurate to say that these addresses would never appear in a mapping.

-- In Section 6.4, the first paragraph says that each error is "long" or "short", but they're not all marked.  Is there a default?  It also seems like some of these errors are effectively permanent, e.g., UNSUPP_VERSION; the PCP NAT isn't going to support a new version of the protocol half an hour from now.

-- In Section 7.1, you first say that "only a single PCP server address is supported", but then in a couple of other places mention a "list of PCP servers".  Which is it?

-- In Section 7.1, it seems like it would be pretty unusual for the PCP server to be the first-hop router, at least outside of the CPE case.  Would it be better to use an anycast address to find the server?

-- I did not find that the code samples in Section 9 added any information.  The one case where one would have been helpful (9.4), there was none.