Subject: [midcom] Port preservation

From: "Yutaka Takeda" <[email-masked]>
Date: Fri, 23 Apr 2004 11:19:21 -0700

Does anyone know what the real motivation for NAT designers to 
implement the port preservation[1] is? Is there an actual service 
or application that depends on this behavior? I just realized that 
I know such NATs exist but why...

[1] http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt

Yutaka

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 23 Apr 2004 16:03:52 -0700 (PDT)

Port preservation is desirable in some limited cases where applications and
protocols require a certain number to be used for source and/or destination.
ex: IKE-v1 assumes UDP port 500 on both src and dest.

cheers,
suresh
 
--- Yutaka Takeda <[email-masked]> wrote:
> [1]
> http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-00.txt
> 
> Yutaka
> 

=====

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Apr 2004 10:41:30 -1000

There may be many but the two reasons I have heard are below - neither of
which make much sense to me.

Makes debugging easier by not switching the port traffic is on. This allows
network sniffers and such guess the type of traffic from the port.
(Personally I find this argument a little hard to buy given it is the source
port that is being preserved and using ports for traffic type determination
is usually based on the destination port)

Higher odds of interoperability for protocols. The argument goes that A
sends though a NAT to B. B may reply expecting to go to a certain port
number so if that does not change life will be better. I suspect that most
applications that reply to the correct IP, are likely to also reply to port
the packet came from but who knows.

The most common answer I get to this questions and the one that seems most
believable ... "Because vendor X's NAT worked that way so we made ours do
the same"

I don't know - it is a good questions. Can others provide any insight into
this?

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 26 Apr 2004 15:28:42 -0500

Hi all,
The only reason that I can think of, that may be a good reason, is to
provide the appearance that a client is communicating directly with a
server on a standard server port (for that professional, I'm a big
organization look and feel). Some applications do check for this for
paranoid security reasons, but they are less common.

We typically call this a static port translation, irregardless of
vendor, and it can be configured on many of the popular enterprise class
firewalls.

The other common type of configuration used for the same reason would be
a static IP NAT translation, which provides the server with a whole
range of ports that it can be listening on.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Monday, April 26, 2004 3:42 PM
To: Yutaka Takeda; Midcom; [email-masked]
Subject: Re: [midcom] Port preservation

There may be many but the two reasons I have heard are below - neither
of
which make much sense to me.

Makes debugging easier by not switching the port traffic is on. This
allows
network sniffers and such guess the type of traffic from the port.
(Personally I find this argument a little hard to buy given it is the
source
port that is being preserved and using ports for traffic type
determination
is usually based on the destination port)

Higher odds of interoperability for protocols. The argument goes that A
sends though a NAT to B. B may reply expecting to go to a certain port
number so if that does not change life will be better. I suspect that
most
applications that reply to the correct IP, are likely to also reply to
port
the packet came from but who knows.

The most common answer I get to this questions and the one that seems
most
believable ... "Because vendor X's NAT worked that way so we made ours
do
the same"

I don't know - it is a good questions. Can others provide any insight
into
this?

> I know such NATs exist but why...
http://www.ietf.org/internet-drafts/draft-jennings-midcom-stun-results-0
0.txt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Apr 2004 00:43:41 -0400

> paranoid security reasons, but they are less common.

For what application does the protocol expect the SOURCE port to be a 
standard server port? None that I can think of.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 27 Apr 2004 00:00:05 -0500

Jonathan,
This was merely an example. 

For clarity, common server ports in this example would be HTTP, SMTP,
FTP, etc. This is a common enterprise deployment use for static
translations that I was describing earlier.

Most developers of well behaved protocols will implement the capability
to listen on the same port they send on, or provide the capability to
configure this. Firewall/NAT vendors typically provide the capability to
configure the static IP/PORT NAT translations for these types of
services, which is why I used this as a possible reason, to answer the
question raised below.

The use described is in no way definitive, but it does provide a
practical use scenario that you will see quite often in the real world.

The capability to perform this type of configuration is essential to
providing secure access policies, a feature that I wish VoIP and other
peer-to-peer protocol developers would have modeled (Some do, but the
standard doesn't require this, which doesn't help security). 

Chris

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, April 26, 2004 11:44 PM
To: [email-masked]
Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; [email-masked]
Subject: Re: [midcom] Port preservation

-Jonathan R.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 27 Apr 2004 00:02:49 -0500

I was only providing an example, for the sake of answering a posted
question, of why a static one-to-one port mapping might be desired in a
NAT, not to justify why an application might expect a source port to be
a standard server port.

Chris

-----Original Message-----
Jonathan Rosenberg

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Apr 2004 19:36:49 -1000

On 4/26/04 7:00 PM, "Christopher A. Martin" <[email-masked]> wrote:

> FTP, etc.

Well for TCP, the NATs don't muck with ports at all. The clients I have for
HTTP, SMTP, FTP, also use source ports different than the destination ports
so that the clients don't have to open a port under 1024 which would require
them to be running as root.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Apr 2004 19:54:43 -1000

Thanks for the concrete example of IKE.

On 4/23/04 1:03 PM, "Pyda Srisuresh" <[email-masked]> wrote:

> stun mailing list
> [email-masked]
> To unsubscribe, please go to http://www.vovida.org/mailman/listinfo/stun
>

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 27 Apr 2004 08:09:17 -0500

Ya, clients typically do use random ports, I am only speaking from a
server standpoint (Enterprises don't typically static nat a client).

:)

Chris

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2004 12:37 AM
To: [email-masked]; Jonathan Rosenberg
Cc: 'Yutaka Takeda'; Midcom; [email-masked]
Subject: Re: [midcom] Port preservation

> For clarity, common server ports in this example would be HTTP, SMTP,

Well for TCP, the NATs don't muck with ports at all. The clients I have
for
HTTP, SMTP, FTP, also use source ports different than the destination
ports
so that the clients don't have to open a port under 1024 which would
require
them to be running as root.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 27 Apr 2004 08:39:42 -0500

I guess I should also state the port that I am describing is a listening
port (which is often also the source port) of the server being NATted,
while I am at it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christopher A. Martin
Sent: Tuesday, April 27, 2004 8:09 AM
To: 'Cullen Jennings'; 'Jonathan Rosenberg'
Cc: 'Yutaka Takeda'; 'Midcom'; [email-masked]
Subject: RE: [midcom] Port preservation

:)

Chris

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Apr 2004 11:48:31 -0400

I think you are confusing two things.

One is a client behind a nat speaking to a server on the public side. 
There, I think there are very, very few cases where the source port 
means anything (IKE is the only identified one there).

The other case is a server running behind the NAT (i.e., on the private 
side), which is what you are talking about below. In such a case, I 
think you would use port forwarding configuration on the nat, and so 
port preservation on dynamically created bindings isnt applicable.

-Jonathan R.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 27 Apr 2004 22:44:28 -0500

Yep, I was only using an example where a static nat might be relevant,
and it didn't include clients...it was a server example....I gave both a
port and an ip translation example...for comparison purposes only.

Chris

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2004 10:49 AM
To: [email-masked]
Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; [email-masked]
Subject: Re: [midcom] Port preservation

-Jonathan R.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 27 Apr 2004 22:45:57 -0500

I was offering another example, IKE is also an example...

This isn't hard...someone asked why the solution might be used, there
are a dozen reasons why, servers, ike are common ones...

Why dig so hard here...????  There is no confusion, just offered another
example...

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2004 10:49 AM
To: [email-masked]
Cc: 'Cullen Jennings'; 'Yutaka Takeda'; 'Midcom'; [email-masked]
Subject: Re: [midcom] Port preservation

-Jonathan R.