Re: [BEHAVE] NAPGT request for comments, THANKS!

meng.wei2@zte.com.cn Mon, 29 July 2013 13:53 UTC

Return-Path: <meng.wei2@zte.com.cn>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C384B21F9926; Mon, 29 Jul 2013 06:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.245
X-Spam-Level:
X-Spam-Status: No, score=-100.245 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, 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 OGGfvBx86wo2; Mon, 29 Jul 2013 06:53:32 -0700 (PDT)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 90ABB11E80DE; Mon, 29 Jul 2013 06:52:25 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2E3791339480; Mon, 29 Jul 2013 21:51:52 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 547607397DA; Mon, 29 Jul 2013 21:51:51 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r6TDpfvc094019; Mon, 29 Jul 2013 21:51:41 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn)
In-Reply-To: <CB1B483277FEC94E9B58357040EE5D02325D26B4@xmb-rcd-x15.cisco.com>
To: "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFA2FFD2EB.38131399-ON48257BB7.0049C097-48257BB7.004C2B31@zte.com.cn>
From: meng.wei2@zte.com.cn
Date: Mon, 29 Jul 2013 21:51:40 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-29 21:51:29, Serialize complete at 2013-07-29 21:51:29
Content-Type: multipart/alternative; boundary="=_alternative 004C2B2D48257BB7_="
X-MAIL: mse01.zte.com.cn r6TDpfvc094019
Cc: "Reinaldo Penno (repenno)" <repenno@cisco.com>, "behave-bounces@ietf.org" <behave-bounces@ietf.org>, "behave@ietf.org" <behave@ietf.org>, "Dan Wing (dwing)" <dwing@cisco.com>
Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 13:53:41 -0000

Hi all,
  It's a pitty I got no comment after my presentation due to lack of 
meeting time.
  It is an important issue which small firms/family DIYers/... must face 
to
when NAT has been deployed. They attempt to achieve accessing internal 
server 
from external network environment without an extra public IP address.

  Are you interested in this topic?

  Please see the scenario in slides. 
http://tools.ietf.org/agenda/87/slides/slides-87-behave-4.pdf

Thanks for comments.

Cheers,
Wei
 


behave-bounces@ietf.org  2013/07/18 22:31:00:

> From: "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
> Date: Wednesday, July 17, 2013 9:19 PM
> To: Senthil Sivakumar <ssenthil@cisco.com>
> Cc: "behave@ietf.org" <behave@ietf.org>, "behave-bounces@ietf.org" <
> behave-bounces@ietf.org>, "Dan Wing (dwing)" <dwing@cisco.com>, 
> "Reinaldo Penno (repenno)" <repenno@cisco.com>
> Subject: Re: Re: [BEHAVE] NAPGT request for comments, THANKS!
> 
> 
> Hi, 
>   Please see inline. 
> 
> Thanks, 
> Wei 
> 
> "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>  2013-07-17 
21:30:24:
> 
> > From: "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
> > Date: Wednesday, July 17, 2013 4:08 AM
> > To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
> > Cc: "behave-bounces@ietf.org" <behave-bounces@ietf.org>, 
"behave@ietf.org" <
> > behave@ietf.org>, "Dan Wing (dwing)" <dwing@cisco.com>
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! 
> > 
> > 
> > Hi, 
> >   I got what the example means. 
> > 
> >   1-1024 is just an example, the range could be any valid value.
> > 
> >   "<1-1024> might be used as NAT, <1025-65535> might be used as 
> > dynamic NAPT", example is as below. 
> > 
> >    +----------+     +-----+    +--------+ 
> >    + Internet + ----+ NAT +----+ Server + 
> >    +----------+     +-----+    +--------+ 
> > 
> >    (1) "<1-1024> might be used as NAT" means, 
> >        A server behind a NAT. 
> >    A message, sent by server, its source port is in 1-1024 (or 
> > 4500-4501 or ...).
> >    The source address will be converted by NAT, the source port 
remains
> >    the same. 
> > 
> > [Senthil] Sorry, I didn’t read the draft, but the above logic wont 
> > work if there are multiple servers using the same source port. 
> > Also, in some applications (I think rcmd, rshell etc), the source 
> > port doesn’t have to be preserved but must be below 1024. 
> > 
> > Senthil 
> 
> [Wei] I'm presenting the proposal so as to solve this problem : assign 
port 
> x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), 
assign 
> the rest of ports to others(for common NAPT). 
>   Of course, if there are many servers bebind NAT and whether or not 
using 
> the same source port, NAT has to need more than one public address.
>   But in this case ,a server will never occupys all ports of a 
> public address, 
> just "x-y". 
> 
> [Senthil] I don’t really understand what is the use case for this? 
> Can you provide a real life use case that would benefit by this?
> What if the server listens on a port > 1024? Why would the server 
> multiple ports? Why cant a simple port forwarding work?
> 
> Senthil
> 
> Wei 
> 
> > 
> > 
> > 
> >    (2)<1025-65535> might be used as dynamic NAPT 
> >        Meanwhile, many hosts are behind NAT. They attempt to access to 

> >     internet. 
> >        A message, sent by a host, both its source address and port 
will
> >     be converted by NAT, and the new port will be in 1025-65535.
> > 
> > 
> > It will make IP address assignment more effective.
> > 
> > Cheers, 
> > Wei 
> > 
> > 
> > 
> > behave-bounces@ietf.org  2013-07-17 12:36:30:
> > 
> > > Hi, 
> > > 
> > > I'm not sure what exactly you man by "might be used as NAT". 
> > > 
> > > 0-1024 might be used for NAPT in a FCFS basis where port 
> > > preservation (this is what we are talking about here, right?) is 
needed. 
> > > 
> > > As a concrete example, many IPsec Servers still expect to see the 
> > > source port within 0-1024 and preferably a specific source port. If 
> > > that source port is used by the NAT, and more than one IPsec client 
> > > is behind it, there are a some choices available. 
> > > 
> > > - Some funky IPSec ALG (implemented in many products) 
> > > - Give a port above 1024 and hope for the best 
> > > - Deny the connection 
> > > - others.. 
> > > 
> > > Other ports for the same public IP can be used by any other internal
> > > IP address. This is very common in implementations. 
> > > 
> > > thanks, 
> > > 
> > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of
> > > meng.wei2@zte.com.cn [meng.wei2@zte.com.cn]
> > > Sent: Tuesday, July 16, 2013 8:22 PM
> > > To: Reinaldo Penno (repenno)
> > > Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing)
> > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
> > 
> > > 
> > > Hi Reinaldo, 
> > >   So I suppose <1-1024> might be used as NAT, <1025-65535> might
> be used as 
> > > dynamic NAPT. 
> > >   That is what this view says in the draft. 
> > > 
> > > Cheers, 
> > > Wei 
> > > 
> > > 
> > > behave-bounces@ietf.org 2013-07-17 09:52:34:
> > > 
> > > > I'm not sure this is a good idea. There are still some protocols 
> > > > around that use ports < 1024 and maintaining the source port after 

> > > > translation in this range is important. 
> > > > 
> > > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf 
of
> > > > Dan Wing (dwing)
> > > > Sent: Tuesday, July 16, 2013 3:30 PM
> > > > To: meng.wei2@zte.com.cn
> > > > Cc: behave@ietf.org
> > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
> > > 
> > > > 
> > > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: 
> > > > 
> > > >     I have submitted a new draft. The objective is to solve a 
> > problem that 
> > > >     prevents an external client from accessing an internal server. 

> > > > 
> > > >     https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ 
> > > > 
> > > >     I expect your comments. Thanks a lot! 
> > > > 
> > > > Draft-meng-behave-napgt appears to describe something that is very 

> > > > similar to the long-standing "DMZ host" configuration available on 

> > > > almost all residential-class NAT devices.  I don't think we could 
> > > > standardize that behavior, but perhaps that is possible. 
> > > > 
> > > > Draft-meng-behave-napgt also describes an update to the port 
> > > > assignment behavior described in http://tools.ietf.
> > > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> > > > org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 
of 
> > > > draft-meng-behave-napgt properly, it is saying that NATs should 
not 
> > > > assign ports below 1024 to dynamic connections.  This might be 
> > > > something worth considering for 
draft-ietf-behave-requirements-update? 
> > > > 
> > > > -d 
> > > > _______________________________________________
> > > > Behave mailing list
> > > > Behave@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/behave
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave