[apps-discuss] APPSDIR rdraft-ietf-pcp-base-22
"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 10 February 2012 21:53 UTC
Return-Path: <vkg@bell-labs.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6214821F854B for <apps-discuss@ietfa.amsl.com>; Fri, 10 Feb 2012 13:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.871
X-Spam-Level:
X-Spam-Status: No, score=-108.871 tagged_above=-999 required=5 tests=[AWL=1.728, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 cn-YbsxAGCX6 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Feb 2012 13:53:43 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4868321F8542 for <apps-discuss@ietf.org>; Fri, 10 Feb 2012 13:53:43 -0800 (PST)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q1ALrfke027373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Feb 2012 15:53:41 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q1ALrfgD015111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Feb 2012 15:53:41 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q1ALreJD004412; Fri, 10 Feb 2012 15:53:40 -0600 (CST)
Message-ID: <4F3592E5.3080707@bell-labs.com>
Date: Fri, 10 Feb 2012 15:57:57 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, draft-ietf-pcp-base@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2012 21:53:44 -0000
Document: draft-ietf-pcp-base-22 Title: Port Control Protocol (PCP) Reviewer: Vijay K. Gurbani Review Date: Feb-10-2012 IETF Last Call Date: Not known IESG Telechat Date: Not known Summary: This draft is almost ready for publication as a Proposed Standard but has a few issues that should be fixed before publication. Major issues: 0 Minor issues: 11 Major issues: 0 Issues listed below are in document order. - S5, the all zeroes IPv4 address as defined by the draft is a contribution of the draft itself, right? That is, at least I am not aware whether ::ffff:0:0 is generally used as the all-zero IPv4-mapped IPv6 address. It may well be, in which case this comment can be ignored. But if it is not a general use address and is intended to be defined by this draft, I wonder if rfc2119 MUST is appropriate here (as in "The all-zeroes IPv4 address MUST be expressed as: 80 bits of zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0)."). - S6.1, the "Opcode-specific information" block of Figure 2 is not discussed at all in the text following Figure 2. - S6.1, the "PCP Options" block of Figure 2 is not discussed at all in the text following Figure 2. You do provide a Section 6.3 that discusses options; perhaps it is sufficient to say the following at the end of the text following Figure 2: "PCP Options: Please see Section 6.3". - Ditto for S6.2 and Figure 3's use of "Opcode-specific response data" and "Options" block. - S7.1, second-to-last paragraph: I suspect that if more than one server was specified in the server list, the client will cycle through and try the next server. I also note that this document only considers one server, so exact guidance is not provided on what to do when a PCP client has more than one server. But I think it possible that the default router list (mentioned earlier in the section) creates a list of two servers: an IPv4- and IPv6-server. Would it be prudent to try the IPv6 server if the IPv4 server --- and vice-versa --- did not result in any response within the maximum retransmission interval of 15m? - S7.3, the third paragraph from the end of the section ("For both ... is RECOMMENDED."): Here you say that "A limit of 24 hours for success responses and 30 minutes for error responses is RECOMMENDED." However, in S6.4 you said that, "It is RECOMMENDED that short lifetime errors use a 30 second lifetime and long lifetime errors use a 30 minute lifetime." So --- is S7.3 treating *all* error responses as long lifetime errors? - S9.1: The algorithm provided is excellent, but can only be used when writing new servers (since it requires sending and receiving PCP messages). This should be made clear before the algorithm. (I believe that this stands to reason, but being explicit does not hurt.) Existing servers that need to be reachable from the outside, but ones whose source code cannot be modified, will need to arrange for an explicit static mapping to happen before they are started. - I believe that the above issue is true for S9.{2,3} as well. - S16.1.1: I am not sure how to interpret the listed attacks in this section. Is it the case that these attacks can happen even if PCP servers comply with the Simple Threat Model? Or is it the case that the Simple Threat Model mitigates these attacks? - S16.2: To protect against Advanced Threat Model attacks, the draft assumes a PCP security mechanism that provides channel authentication and encryption. However, no further information is provided for such a mechanism. Will it help to provide any candidates for such a mechanism (TLS? S/MIME?) or is there something entirely different in mind? - S16.3.1: As far as I can see, there is no mitigation for Denial of Service attack mounted by an attacker on the path between the PCP client and PCP server, yes? If so, it will be nice to explicitly state this. Nit: - S3, while discussing Internal Host: The term "PCP MAP" request is used here without further context, like a short definition. Clearly, the PCP MAP request arranges for a mapping to occur in the NAT ... the reader can tell that much. But all the same, for the sake of completeness, it will be good to provide a quick definition when the term is first used. - S3, while discussing Explicit static mappings: any reason why a GUI (distinct from a web-based UI) is omitted? I suspect the answer is just plain oversight, but just the same, I think it will not hurt to include it in, or simply take out the text in the brackets. - S16.2: s/mechanism which provides/mechanism that provides That's it. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/
- [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 Vijay K. Gurbani
- Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 Dan Wing
- Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 S Moonesamy
- Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 Vijay K. Gurbani
- Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 Dan Wing