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

From: "meng.wei2@zte.com.cn<mailto:meng.wei2@zte.com.cn>" <meng.wei2@zte.com.cn<mailto:meng.wei2@zte.com.cn>>
Date: Wednesday, July 17, 2013 4:08 AM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com<mailto:repenno@cisco.com>>
Cc: "behave-bounces@ietf.org<mailto:behave-bounces@ietf.org>" <behave-bounces@ietf.org<mailto:behave-bounces@ietf.org>>, "behave@ietf.org<mailto:behave@ietf.org>" <behave@ietf.org<mailto:behave@ietf.org>>, "Dan Wing (dwing)" <dwing@cisco.com<mailto: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

   (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<mailto: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<mailto:behave-bounces@ietf.org> [behave-bounces@ietf.org<mailto:behave-bounces@ietf.org>] on behalf of
> meng.wei2@zte.com.cn<mailto:meng.wei2@zte.com.cn> [meng.wei2@zte.com.cn<mailto:meng.wei2@zte.com.cn>]
> Sent: Tuesday, July 16, 2013 8:22 PM
> To: Reinaldo Penno (repenno)
> Cc: behave-bounces@ietf.org<mailto:behave-bounces@ietf.org>; behave@ietf.org<mailto: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<mailto: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<mailto:behave-bounces@ietf.org> [behave-bounces@ietf.org<mailto:behave-bounces@ietf.org>] on behalf of
> > Dan Wing (dwing)
> > Sent: Tuesday, July 16, 2013 3:30 PM
> > To: meng.wei2@zte.com.cn<mailto:meng.wei2@zte.com.cn>
> > Cc: behave@ietf.org<mailto:behave@ietf.org>
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
> >
> > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn<mailto: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<mailto:Behave@ietf.org>
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org<mailto:Behave@ietf.org>
> https://www.ietf.org/mailman/listinfo/behave