Subject: RE: [Ietf-behave] port-type preservation?

From: "Francois Audet" <[email-masked]>
Date: Thu, 30 Sep 2004 12:06:35 -0700 (PDT)

That's what I think.

Let's wait for Jonathan's input.

To summarize, I'm saying that instead of preserving the port range, always
use the dynamic range when doing a mapping to a new port.

My concern about preserving the well-known and registered range is that it 
could cause some traffic to look like something else and thus be intercepted 
by layer 4-7 equipment doing deep-packet inspection and causing problems.

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Thursday, September 30, 2004 11:57
> To: Audet, Francois [SC100:9T51:EXCH]; 'Jonathan Rosenberg'
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] port-type preservation?
> 
> 
> Unless we can find a modern UDP-based application that cares 
> about preserving the range, I don't see a downside.
> 
> -d
> 
> -----Original Message-----
> From: Francois Audet [mailto:audet@xxxxxxxxxxxxxxxxxx]
> Sent: Thursday, September 30, 2004 11:17 AM
> To: 'Dan Wing'; 'Jonathan Rosenberg'
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: RE: [Ietf-behave] port-type preservation?
> 
> 
> Can you explain the downside of always using the dynamic 
> range for outgoing port binding?
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@xxxxxxxxx]
> > Sent: Thursday, September 30, 2004 11:14
> > To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH]
> > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Ietf-behave] port-type preservation?
> >
> >
> > This sounds like a good idea, and it's logical.
> >
> > However, do we know of any IETF or non-IETF protocol that breaks if 
> > you don't have a source UDP port within the appropriate range?
> >
> > I poked around DNS and TFTP and neither care about the 
> source UDP port 
> > number for their operation.  NFSv2 (RFC1831) has a 
> preference for the 
> > connections to come from privileged ports, but with everyone having 
> > privileges on their own computer now-a-days I think NFS's 
> preference 
> > is historic.
> >
> > Without an application that breaks, the best I think we 
> should say is 
> > a strongly-worded "MAY", like this strawman text:
> >
> >   When deciding the source UDP port for an outgoing binding a NAT
> >   MAY choose a source port that is in the same IANA range (well
> >   known, registered, or dynamic) as the original source UDP port.
> >   However, as most modern applications to not utilize source port
> >   numbers as an indicator of trust, there is little value in a NAT
> >   to provide this function.
> >
> > -d
> >
> >
> > > -----Original Message-----
> > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf
> > Of Jonathan
> > > Rosenberg
> > > Sent: Thursday, September 30, 2004 7:52 AM
> > > To: Francois Audet
> > > Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> > > Subject: Re: [Ietf-behave] port-type preservation?
> > >
> > >
> > > Almost.
> > >
> > > What I'm saying is, if the source port on the private side
> > is in the
> > > dynamic range, the source port on the public side should
> > probably be
> > > in that range. If the source port is in the registered
> > range, so too
> > > should the source port on the public side, and same for the
> > well-known
> > > range.
> > >
> > > -Jonathan R.
> > >
> > > Francois Audet wrote:
> > >
> > > > So, if I understand correctly, you want us to put in the Behave 
> > > > document something saying that port binding assignments 
> are to be 
> > > > done from the dynamic/private port range 49152-65535?
> > > >
> > > > Right?
> > > >
> > > >  > -----Original Message-----
> > > >  > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > > >  > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On
> > Behalf Of  >
> > > > Jonathan Rosenberg  > Sent: Tuesday, September 28, 2004 
> 23:16  > 
> > > > To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'  > Subject: [Ietf-behave] 
> > > > port-type preservation?  >
> > > >  >
> > > >  > Folks,
> > > >  >
> > > >  > An interesting thread has been going on on the mmusic
> > list, which is
> > > >  > relevant to behave. The discussion was around NAT
> > preservation of
> > > >  > port-types, where the types are (for UDP) 
> "well-known" from 0  
> > > > > to 1023,  > "registered" from 1024 to 49151, and 
> > > > "dynamic/private"
> > from 49152
> > > >  > through 65535. See:
> > > >  > 
> > > > 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg02902.html
> > > >
> > > > If a NAT sees an outbound packet with one of these 
> types, does it 
> > > > attempt to maintain the preservation? That is, should 
> an outbound 
> > > > packet within the dynamic range always map to a port in
> > the dynamic
> > > > range?
> > > >
> > > > I think the behave draft should probably say something
> > about this. I
> > > > suspect its probably a good idea to preserve the port-type.
> > > >
> > > > -Jonathan R.
> > > > --
> > > > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > > > Chief Technology Officer                    Parsippany,
> > NJ 07054-2711
> > > > dynamicsoft
> > > > jdrosen@xxxxxxxxxxxxxxx                     FAX:   
> (973) 952-5050
> > > > http://www.jdrosen.net                      PHONE: 
> (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > >
> > > > _______________________________________________
> > > > Ietf-behave mailing list
> > > > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > > >
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> > > Chief Technology Officer                    Parsippany, NJ
> > 07054-2711
> > > dynamicsoft
> > > jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
> > > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com 
> > > _______________________________________________
> > > Ietf-behave mailing list
> > > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >
> >
> >
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Sep 2004 21:04:13 -0700 (PDT)

The primary issue that motivated my comment was a discussion on mmusic, 
where we really wanted to be sure that a client which had a source port 
in the dynamic range, had it also mapped to one in the dynamic range. 
The reason had to do with ICE connectivity checks getting misrouted, and 
that you would not want them to be directed to well-known service ports.

So, my extrapolation of this was that you would range port type 
presentation for the other types as well.

However, I also can't think of a case where preservation in the other 
ranges is the right thing, and so mapping everything into dynamic should 
work. My first concern about this, though, is that the dynamic range is 
not that large (16k ports). Thus, if an enterprise is buying a nat to 
mux a large number of internal hosts into a small number of addresses, 
this reduces the "compression" ratio by a factor of four, compared to 
allowing the NAT to map anywhere into the 16 bit space.

I would also expect that, in most cases, the packets originating from 
the private side of a nat would have source ports in the dynamic range. 
Almost by definition, only client/server protocols work through nat, 
implying that the packets which originate on the private side of the nat 
would be the result of a client operation in a C/S protocol. These 
ususally get sent from ephemeral ports, and operating systems should be 
allocating those from the dynamic range.

If you're running a server on a host behind a nat (which would cause the 
responses to contain the well-known service port in the source port), 
that would have required you to configure port forwarding on the nat 
anyway, so the allocation is not dynamic there.

-Jonathan R.

Francois Audet wrote:

That's what I think.

could cause some traffic to look like something else and thus be 
intercepted

 > > > >  > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On
 > > Behalf Of  >
 > > > >  > Folks,
 > > > >  > An interesting thread has been going on on the mmusic
 > > list, which is
 > > > >  > relevant to behave. The discussion was around NAT
 > > preservation of
 > > > >  > port-types, where the types are (for UDP)
 > "well-known" from 0 
 > > > >  > through 65535. See:

Chief Technology Officer                    Parsippany, NJ 07054-2711

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 1 Oct 2004 04:14:02 -0700 (PDT)

Hi, Jonathan,

The primary issue that motivated my comment was a discussion on 
mmusic, where we really wanted to be sure that a client which had a 
source port in the dynamic range, had it also mapped to one in the 
dynamic range. The reason had to do with ICE connectivity checks 
getting misrouted, and that you would not want them to be directed 
to well-known service ports.

However, I also can't think of a case where preservation in the 
other ranges is the right thing, and so mapping everything into 
dynamic should work. My first concern about this, though, is that 
the dynamic range is not that large (16k ports). Thus, if an 
enterprise is buying a nat to mux a large number of internal hosts 
into a small number of addresses, this reduces the "compression" 
ratio by a factor of four, compared to allowing the NAT to map 
anywhere into the 16 bit space.
Is it at all realistic to ask NATs to avoid "well-known service 
ports", unless they are configured for port forwarding?

Spencer

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Oct 2004 10:07:48 -0700 (PDT)

> that you would not want them to be directed to well-known service ports.

The best way to avoid using well-known service ports is to never have
a NAT map to a well-known service port.

After all, if one host uses a source port of, say, 53 (DNS), and the
NAT also uses a source port of 53, what will the NAT do when another
host also uses a source port of 53?  If the NAT uses some other port
in the well-known range (<1024), that port might be assumed -- by something
else -- to be a well-known service that carries P2P, NetBios, NFS, or
whatever traffic.

> allowing the NAT to map anywhere into the 16 bit space.

Yep.

> allocating those from the dynamic range.

Windows 2000 doesn't use the dynamic range for its ephemeral ports -
it uses a range between 1024-5000 according to:
http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/
en-us/tcpip/part4/tcpappc.mspx
(or http://tinyurl.com/56p9f) -- search for "ephemeral".

As do most other OSs:
http://www.ncftpd.com/ncftpd/doc/misc/ephemeral_ports.html

> anyway, so the allocation is not dynamic there.

Of course not all servers are in the well-known port range, though.
For example, port 5060 (SIP) isn't inside the well-known port range.

-d