Re: [pcp] PCP mapping for 5350 and 5351 ports

"Dan Wing" <dwing@cisco.com> Fri, 14 September 2012 17:41 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E5121F8533 for <pcp@ietfa.amsl.com>; Fri, 14 Sep 2012 10:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suZUhdqsNpT9 for <pcp@ietfa.amsl.com>; Fri, 14 Sep 2012 10:41:20 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 087A221F851E for <pcp@ietf.org>; Fri, 14 Sep 2012 10:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4274; q=dns/txt; s=iport; t=1347644480; x=1348854080; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=BUMJFftRSzIIktQNlqo4HWqen/+uMtFb228MQDGFuFs=; b=UJplRfqNOuaLaB7sVF7UartmuxPEVqjO2C4bfoJqXf/vAM7YKEXCSx5M 1altBp1WcMCGgZpvoO+JbYvkxpafMYAu2Rs0PF+EUuG7adKBlUl9uUKd1 /gxS00llGMBnMMs8nX8/5nL7cwANTzDdVKvf/KzCXG6rJuyg0NqkI5PSJ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFABZsU1CrRDoJ/2dsb2JhbABFrAyPdoEHgiABAQEDAQEBAQUKARcQNBcBAwIJDwIEAQEoBxkOFQoJCAIEARILF4dlBQybR6AdBIsVhmgDiFaFD5Y0gWmDBg
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="55692985"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Sep 2012 17:41:12 +0000
Received: from dwingWS ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8EHfC4v029844; Fri, 14 Sep 2012 17:41:12 GMT
From: Dan Wing <dwing@cisco.com>
To: "'Zhangzongjian (Thomas)'" <zhangzhongjian@huawei.com>, pcp@ietf.org
References: <9B57C850BB53634CACEC56EF4853FF653B7B205A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <B27AE62F-1ADF-44DE-AF33-0B7A3AD6ACDB@yegin.org> <D6230CDE-E869-406F-B194-8E9B626CA8D8@lilacglade.org> <5052D3F3.8000605@toshiba.co.jp> <52B4EAD8-7B6A-452D-8738-72C59E357519@yegin.org> <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com>
In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC74BF@szxeml524-mbs.china.huawei.com>
Date: Fri, 14 Sep 2012 10:41:12 -0700
Message-ID: <071d01cd92a0$21e179e0$65a46da0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHNklFQfx9YznzFZkayNVvmBYxVuZeKGsQg
Content-Language: en-us
Subject: Re: [pcp] PCP mapping for 5350 and 5351 ports
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Fri, 14 Sep 2012 17:41:21 -0000

> -----Original Message-----
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> Zhangzongjian (Thomas)
> Sent: Friday, September 14, 2012 1:17 AM
> To: pcp@ietf.org
> Subject: [pcp] PCP mapping for 5350 and 5351 ports
> 
> Dear all
> 
> In charter 11.3 of draft draft-ietf-pcp-base-26, it said:
> 
> The PCP server MUST NOT create mappings for the PCP ports themselves
>    (5350 and 5351), and SHOULD have a policy control to deny mappings
>    for other ports.  In these cases, the error NOT_AUTHORIZED SHOULD be
>    returned.
> 
> We need to clarify:
> 1.
> What kinds port that 5350 and 5351 ports must not be used for mapping?
> Internal ports ,  external ports or both?
> 
> 2.
> What kinds protocol that the ports must not be used for mapping?  UDP
> and others?
> 
> 3.
> It also seems that different scenarios have different result. Such as,
> PCP server knows public interfaces and private interfaces in box,  Only
> PCP server in a box or both PCP server and PCP client.

During review, this confusion was pointed out.  In -27, the above
is rewritten into a much more general and clear format, and reads
as follows.  I highlighted the specific text regarding the PCP
ports numbers (5350, 5351), and the rest of the new text should 
clarify your questions (2) and (3).  If the new text is still
inadequate, please let me know.


   If no mapping exists for the Internal Address, Protocol, and Port,
   and the PCP server is able to create a mapping using the Suggested
   External Address and Port, it SHOULD do so.  This is beneficial for
   re-establishing state lost in the PCP server (e.g., due to a reboot).
   There are, however, cases where the PCP server is not able to create
   a new mapping using the Suggested External Address and Port:

   o  The Suggested External Address, Protocol, and Port is already
      assigned to another existing explicit or implicit mapping (i.e.,
      is already forwarding traffic to some other internal address and
      port).

   o  The Suggested External Address, Protocol, and Port is already used
      by the NAT gateway for one of its own services.  For example, TCP
      port 80 for the NAT gateway's own configuration web pages, or UDP
      ports 5350 and 5351, used by PCP itself.  A PCP server MUST NOT
................................................^^^^^^^^^^^^^^^^^^^^^
      create client mappings for External UDP ports 5350 or 5351.
......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   o  The Suggested External Address, Protocol, and Port is otherwise
      prohibited by the PCP server's policy.

   o  The Suggested External Address, Protocol, or Port is invalid
      (e.g., External Address 127.0.0.1, ::1, a multicast address, or
      the port is not valid for the indicated protocol).

   o  The Suggested External Address does not belong to the NAT gateway.

   o  The Suggested External Address is not configured to be used as an
      external address of the firewall or NAT gateway.

   If the PCP server cannot assign the Suggested External Address,
   Protocol, and Port, then:

   o  If the request contained the PREFER_FAILURE Option, then the PCP
      server MUST return CANNOT_PROVIDE_EXTERNAL.

   o  If the request did not contain the PREFER_FAILURE Option, and the
      PCP server can assign some other External Address and Port for
      that protocol, then the PCP server MUST do so and return the newly
      assigned External Address and Port in the response.  In no case is
      the client penalized for a 'poor' choice of Suggested External
      Address and Port.  The Suggested External Address and Port may be
      used by the server to guide its choice of what External Address
      and Port to assign, but in no case do they cause the server to
      fail to allocate an External Address and Port where otherwise it
      would have succeeded.  The presence of a non-zero Suggested
      External Address or Port is merely a hint; it never does any harm.


-d


> 
> 
> Regards
> Thomas
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp