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

From: "Francois Audet" <[email-masked]>
Date: Fri, 1 Oct 2004 14:07:35 -0700 (PDT)

Thanks Dan, this is extremelly useful.

My conclusions are:

(1) Bindings MUST NOT be assigned from the Well-known port range (0-1023). I think
    everybody agrees with that.

(2) I would tend to conclude that the bindings could be assigned from any other
    ports, depending on implementation, i.e. any ephemeral port or dynamic port,
    which means the whole 1024-65535.

I would therefore say that in the text, we will that UDP bindings MUST not be assigned
from the well-known port range (0-1023) and shall be assigned from the 1024-65535
range (without getting into details of ephemeral versus registered/dynamic.

Does evererybody agree?

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Friday, October 01, 2004 10:08
> To: Jonathan Rosenberg; Audet, Francois [SC100:9T51:EXCH]
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] port-type preservation?
> 
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> Yep.
> 
> > 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.
> 
> 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
> 
> > 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.
> 
> 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.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 1 Oct 2004 22:36:19 -0700 (PDT)

Francois Audet wrote:

My conclusions are:

(1) Bindings MUST NOT be assigned from the Well-known port range 
(0-1023). I think
    everybody agrees with that.
Yes. Thinking about it more, it doesn't make any sense to every assign 
ports in this range.

(2) I would tend to conclude that the bindings could be assigned from 
any other
    ports, depending on implementation, i.e. any ephemeral port or 
dynamic port,
    which means the whole 1024-65535.

I would therefore say that in the text, we will that UDP bindings MUST 
not be assigned
from the well-known port range (0-1023) and shall be assigned from the 
1024-65535
range (without getting into details of ephemeral versus registered/dynamic.
Well, lets think about that.

As Dan pointed out, not all service ports are in the well-known range. 
Many aer in the registered range. Is there a reason to believe that its 
not ok to map a source port into 53, but it would be ok to map it into 
5060? The same concerns would apply - things in the network mistaking 
this packet as a response to a query on the service port.

Ideally, I would say that a NAT shouldn't map into well-known port or 
into ports in the registered range that are in fact registered. I 
suspect that this is an unreasonable requirement, since no nat vendor is 
going to want to periodially download the iana port assignment page and 
figure out whether a new port is assigned.

-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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Oct 2004 21:36:10 -0700 (PDT)

> figure out whether a new port is assigned.

I think that requirement would be hard to meet. For one thing, a quick
glance at 

http://www.iana.org/assignments/port-numbers

makes it look like a large percentage of the ports are assigned and running
out of ports is a real issue for large NATs. Anyone know how many are free?

I guess I have not heard any harm that comes from François' proposal of only
using 1024 to 65k so I sort of lean that direction.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Oct 2004 21:36:10 -0700 (PDT)

> from the well-known port range (0-1023) and shall be assigned from the

sounds good to me.

---

From: Robert Sanders <[email-masked]>
Date: Mon, 4 Oct 2004 22:33:01 -0700 (PDT)

Cullen Jennings wrote:

I agree.  This behavior approximates the behavior of an un-NATted host, 
which I imagine we could all agree is the Platonic ideal.  I don't see a 
problem with recommending the dynamic range, given that we've already 
ruled out the only port-type-sensitive applications I've ever heard of 
(e.g., NFS) by not mapping into well-known port space.

Unless the NAT is performing actual port # preservation, of course.

regards,

--
Robert Sanders
Chief Architect, EarthLink

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Oct 2004 00:19:00 -0700 (PDT)

I don't see any harm in Francois' proposal, so much as I don't 
understand why we want to stay away from mapping something into a 
well-known protocol, but allow mapping into a registered protocol. Is 
there something "special" about the well-known protocols that makes us 
think that mapping into them is much worse than mapping into a commonly 
used registered port (like 5060)?

-Jonathan R.

Cullen Jennings wrote:

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 5 Oct 2004 04:54:47 -0700 (PDT)

I don't see any harm in Francois' proposal, so much as I don't 
understand why we want to stay away from mapping something into a 
well-known protocol, but allow mapping into a registered protocol. Is 
there something "special" about the well-known protocols that makes 
us think that mapping into them is much worse than mapping into a 
commonly used registered port (like 5060)?

-Jonathan R.
The only "harm" I can see is the chances of someone looking at the 
port number, unqualified by IP address, and thinking they know what 
the traffic is. This cluelessness seems harmless (a clueless network 
operator might think "gee, I'm carrying all KINDS of RAP ('Random 
Application Protocol') traffic", when they aren't, but since we've 
known IPsec completely breaks figuring out how much traffic you're 
carrying by application protocol for a LONG time, I can't see this as 
a big deal).

FWIW, I asked the "and do we ever reclaim any of these registered 
ports?" on NEWTRK, and the answer is "why would we ever want to do 
that?" Given that modern protocols can use any port number specified 
in a URI, I've got to assume overloading registered port numbers is 
Mostly Harmless...

Spencer

---

From: Melinda Shore <[email-masked]>
Date: Tue, 5 Oct 2004 05:40:07 -0700 (PDT)

On Tuesday, October 5, 2004, at 03:17 AM, Jonathan Rosenberg wrote:
I don't see any harm in Francois' proposal, so much as I don't 
understand why we want to stay away from mapping something into a 
well-known protocol, but allow mapping into a registered protocol. Is 
there something "special" about the well-known protocols that makes us 
think that mapping into them is much worse than mapping into a 
commonly used registered port (like 5060)?
In keeping an eye on my own machines I find that they're far more often
probed on specific well-known ports than they are port-scanned.  I'm 
less
convinced that this is a specific security issue than it is an
operational one - you don't want, say, TCP port 25 being given as part 
of
an external address.  That difference will make no difference when SIP
becomes as ubiquitous as SMTP, but at the moment it does.  Still, given
that we know that the distinction will over time become irrelevant it
seems to me that it would make more sense to say that it's preferred
to draw port numbers from the "private" pool.

Melinda

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 5 Oct 2004 06:23:35 -0700 (PDT)

I guess the more I think about this, I think these port numbers apply to
destination ports and we are only talking about source ports. It's not like
if machine A telnets to machine B that the source port will be 25. The only
practical difference I see on any of this is that on some OS you need to be
root to open a port under 1024. I agree that it's wacky that NFS runs above
1024 and tftp runs below not to mention RTP is generally not in the dynamic
range. I'm just not seeing any of this making much difference.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Oct 2004 08:28:15 -0700 (PDT)

Well, the issue that I thought was really driving the decision not to 
have the NAT allocate ports under 1024 was classification.

Even though we are talking about source ports, if a client sends a 
request to a web server, the TCP packets in response have a source port 
of 80. Thus, classification of packets by intermediate analyzers and 
other things will need to consider both source and destination port.

Thus, the danger of having the nat use the well-known range is that 
packets emininated from the private network out into the public network 
will "look" like responses to requests against well-known service ports. 
Perhaps worse, packets sent back towards the private network from the 
public side will then have this well-known port in the destination port, 
which might fool classifiers into thinking that someone is running a 
well-known service on the private side when they are not.

So, my point was, if you believe that this is a problem (and one might 
argue that it is not), then I see exactly the same problem for the 
registered ports. If a NAT maps a random UDP session onto 5060, then 
packets in and out of the NAT will be mis-classified by anything that 
happens to be listening as SIP. Is that less bad than if it was port 25, 
and the packets were misclassified as SMTP? I don't think it is any less 
bad.

Now, one might argue that this whole misclassification is nonsense, and 
that in an era of NAT and firewall bypassing by tunnelling over port 
443, anyone who is relying on ports for traffic classification is 
getting what they deserve. I believe there is still a fair amount of 
useful traffic classification by port that is happening, but YMMV.

-Jonathan R.

Cullen Jennings wrote:

---

From: Robert Sanders <[email-masked]>
Date: Tue, 5 Oct 2004 14:14:02 -0700 (PDT)

Jonathan Rosenberg wrote:
So,
my point was, if you believe that this is a problem (and one might
argue that it is not), then I see exactly the same problem for the
registered ports. If a NAT maps a random UDP session onto 5060, then
packets in and out of the NAT will be mis-classified by anything that
happens to be listening as SIP. 
True, and various firewalls and "Intrusion Prevention" devices will
react badly to traffic appearing to be from certain services that does
not conform to its expectation of that protocol.  For example, our
office's Checkpoints will drop malformed UDP packets from/to port
5060.  (As a matter of fact, it will drop many well-formed and valid
SIP packets from that port, but that's a different story.)  This is not
Checkpoint's ALG; we have that disabled.

Now,
one might argue that this whole misclassification is nonsense, and that
in an era of NAT and firewall bypassing by tunnelling over port 443,
anyone who is relying on ports for traffic classification is getting
what they deserve. I believe there is still a fair amount of useful
traffic classification by port that is happening, but YMMV.

I think that port-based traffic classification at the enterprise edge
for security purposes is a significant issue, which can be alleviated
by using dynamic ports.   The intersection between applications common
enough to deserve application-specific classification or filtering, and
those apps which use "well known" ports from the dynamic range, should
be miniscule.

If NATs only map ports into the dynamic range, then there is the
potential scarcity issue on very large NATs mentioned before.  If they
only prefer the dynamic range, then the behavior might be unpredictable
(from a single host's point of view) on very large NATs which have
exhausted their dynamic range ports.  However, prefer-dynamic is at
least as predictable as having the NAT randomly map into the entire
registered+dynamic range, and may avoid falsely triggering some
security checks.

So I'd propose this modification of the rules that Francois suggested:

(1) Bindings which alter the source port MUST NOT be
assigned from the Well-known port range (0-1023).
(2) It is RECOMMENDED that a NAT assign bindings
from the Dynamic port range first, before using ports from the
registered range.
(3) A NAT MAY preserve a source port exactly in a binding, even if that
port is from the well-known or registered range.

Rule 3 covers the Linux/Netfilter behavior, which is a useful one for
any protocol which can use random source ports.

regards,
  -- Robert

P.S. By the way, for those who are wondering who I am, I'm one of the
folks involved in implementing EarthLink's recently announced free
(Free World Dial-like) VoIP service.  My concerns right now are
dominated by voice/video and IM, plus a few other apps such as p2p
sharing and gaming.