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

"Zhangzongjian (Thomas)" <zhangzhongjian@huawei.com> Tue, 18 September 2012 02:17 UTC

Return-Path: <zhangzhongjian@huawei.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 BC4B721F850C for <pcp@ietfa.amsl.com>; Mon, 17 Sep 2012 19:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 lCFqjiMtK+Tu for <pcp@ietfa.amsl.com>; Mon, 17 Sep 2012 19:17:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3439521F8504 for <pcp@ietf.org>; Mon, 17 Sep 2012 19:17:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKT51586; Tue, 18 Sep 2012 02:17:07 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 03:16:47 +0100
Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Sep 2012 03:17:06 +0100
Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Tue, 18 Sep 2012 10:14:54 +0800
From: "Zhangzongjian (Thomas)" <zhangzhongjian@huawei.com>
To: Dan Wing <dwing@cisco.com>
Thread-Topic: [pcp] PCP mapping for 5350 and 5351 ports
Thread-Index: AQHNklFQfx9YznzFZkayNVvmBYxVuZeKGsQggAP5YiCAALcOcIAAjJfA
Date: Tue, 18 Sep 2012 02:14:54 +0000
Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC7B32@szxeml524-mbs.china.huawei.com>
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> <071d01cd92a0$21e179e0$65a46da0$@com> <0B2F754289D27B449F7F1B95456B77544EDC79B2@szxeml524-mbs.china.huawei.com> <03f201cd951c$653dbc20$2fb93460$@com>
In-Reply-To: <03f201cd951c$653dbc20$2fb93460$@com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.76.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "pcp@ietf.org" <pcp@ietf.org>
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: Tue, 18 Sep 2012 02:17:10 -0000

Sorry. 
Disagreed.  Explanation refers to my last mail.

The text to be replaced:

>    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.
> ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>

The suggested text is :

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. If PCP server knows it's internal (from which interface the PCP request is received and private network is behind this interface) and external interfaces, and there only PCP server lies in NAT gateway, PCP server can create mappings for External UDP ports 5350 or 5351
The UDP ports 5350 or 5351 may be used by PCP client, PCP proxy, UPnP-PCP interworking, it is suggested that the UPD ports 5350 or 5351 MUST NOT be used for creating mapping as the internal UDP port.  

Regards
Thomas


> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Tuesday, September 18, 2012 5:35 AM
> To: Zhangzongjian (Thomas)
> Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports
> 
> I don't understand if you are agreeing with the text, or disagreeing with
> the text.
> 
> Can you explain what change you want in the text?
> 
> -d
> 
> 
> > -----Original Message-----
> > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com]
> > Sent: Monday, September 17, 2012 12:46 AM
> > To: Dan Wing; pcp@ietf.org
> > Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports
> >
> > >    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.
> > > ......^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^
> > >
> >
> > 1. Internal UPD ports  5350 or 5351 can't be used.
> >    (1) PCP client and NAT-PMP client use 5350 and 5351 for PCP or NAT-
> > PMP protocol. They will not send a PCP/NAT-PMP mapping request use UDP
> > 5350 or 5351 as internal port. Of cause PCP server can ignore this
> > since no such a request. For security we must not permit use the UDP
> > 5350 and 5351 as internal port in Mapping entry. The attacker behind
> > CGN may send a PCP or NAT-PMP map request with 5350 or 5351 as internal
> > port. If PCP server or NAT-PMP server create a mapping use the 5350 or
> > 5351 as internal UDP port, mass Data packets from public network will
> > be send PCP client or NAT-PMP client.
> >    (2) As for UPnP, UDP ports 5350 or 5351 may be used as the internal
> > port in UPnP MAP request.  UPnP-PCP interworking send the PCP request
> > with internal UDP port 5350 or 5351 to PCP server and a mapping entry
> > is created by PCP server. Data packet sent to UPnP client from remote
> > will be forward to UPnP-PCP interworking function. The data packets
> > will be discarded by UPnP-PCP interworking device.
> >
> > 2. we can specify the case that Port is already used by the NAT gateway
> > for one of its own services.
> >   PCP server usually know which interface is internal (from which
> > interface the PCP request is received and private network is behind
> > this interface) or external, such as PCP server in CGN.  That is to say
> > (1) When only PCP server in NAT gateway, PCP server only listen on UDP
> > port 5351 at internal interfaces. UDP 5350 or 5351 can be used as the
> > external port.
> > (2)When both PCP server and PCP client in NAT gateway, PCP server will
> > listen on UDP port 5351 at internal interfaces and PCP client will
> > listen on UDP port 5351 and 5350 at external interfaces. UDP 5350 or
> > 5351 can't be used as the external port.
> > (3)When PCP proxy or UPnP-PCP interworking in NAT gate way, UDP 5350 or
> > 5351 can't be used as the external port. (This out scope of draft-PCP-
> > base)
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing@cisco.com]
> > > Sent: Saturday, September 15, 2012 1:41 AM
> > > To: Zhangzongjian (Thomas); pcp@ietf.org
> > > Subject: RE: [pcp] PCP mapping for 5350 and 5351 ports
> > >
> > > > -----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