Question on port preservation

[Fernando Gont-2]

Folks,

I was wondering if there are any specific applications that actually
need (?) port preservation. If that were the case, I guess one could
do port preservation for specific port numbers, rather than
enabling/disabling port preservation globally.

Any thoughts?

Thanks!

Kind regards,

--
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Dan Wing]

> I was wondering if there are any specific applications that actually
> need (?) port preservation. If that were the case, I guess one could
> do port preservation for specific port numbers, rather than
> enabling/disabling port preservation globally.
>
> Any thoughts?

If you find such an application, I would ask:  what happens when
two intendances of that application are running (on the same host
or on two different hosts) behind the same NAT?

-d

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Fernando Gont-2]

At 12:13 a.m. 12/11/2008, Dan Wing wrote:

> > I was wondering if there are any specific applications that actually
> > need (?) port preservation. If that were the case, I guess one could
> > do port preservation for specific port numbers, rather than
> > enabling/disabling port preservation globally.
> >
> > Any thoughts?
>
>If you find such an application, I would ask:  what happens when
>two intendances of that application are running (on the same host
>or on two different hosts) behind the same NAT?

I completely agree with you. My point is, precisely, that I cannot
see what's the big deal of making port randomization a SHOULD. (If it
breaks an app, I'd argue that the app is already broken (i.e., they
cannot interoperate with hosts behind the other %50 of NATs that do
not do port preservation).

Nevertheless, I'd like to know if these apps that need port
reservation always use some specific source port, or what. If that
were the case, we could simply preserve only those ports, and that's it.

Thanks!

Kind regards,

--
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Francois Audet]

Again, read RFC 4787. We discuss this.

We had at some point in the draft process a recommendation to randomize, but
it was taken out because people complained.

(But I agree with you to be honest: I believe random failures are a worst
problem than "it just doesn't work)


On Nov11 2008 19:22 , "Fernando Gont" <fernando@...> wrote:

> At 12:13 a.m. 12/11/2008, Dan Wing wrote:
>
>>> I was wondering if there are any specific applications that actually
>>> need (?) port preservation. If that were the case, I guess one could
>>> do port preservation for specific port numbers, rather than
>>> enabling/disabling port preservation globally.
>>>
>>> Any thoughts?
>>
>> If you find such an application, I would ask:  what happens when
>> two intendances of that application are running (on the same host
>> or on two different hosts) behind the same NAT?
>
> I completely agree with you. My point is, precisely, that I cannot
> see what's the big deal of making port randomization a SHOULD. (If it
> breaks an app, I'd argue that the app is already broken (i.e., they
> cannot interoperate with hosts behind the other %50 of NATs that do
> not do port preservation).
>
> Nevertheless, I'd like to know if these apps that need port
> reservation always use some specific source port, or what. If that
> were the case, we could simply preserve only those ports, and that's it.
>
> Thanks!
>
> Kind regards,
>
> --
> Fernando Gont
> e-mail: fernando@... || fgont@...
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Francois Audet]

Crappy VoIP implementations (pre-SIP) that break if there are more than one
endpoint trying to use the same port from behind the same NAT.

I suspect some games too (which is probably more important).

In other words, it breaks things that don't use a fully-fledge ICE-like
protocol for NAT/FW traversal.

(...don't shoot the messenger: I didn't like that we backed out of this in
RFC 4787).


On Nov11 2008 18:12 , "Fernando Gont" <fernando@...> wrote:

> Folks,
>
> I was wondering if there are any specific applications that actually
> need (?) port preservation. If that were the case, I guess one could
> do port preservation for specific port numbers, rather than
> enabling/disabling port preservation globally.
>
> Any thoughts?
>
> Thanks!
>
> Kind regards,
>
> --
> Fernando Gont
> e-mail: fernando@... || fgont@...
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Rémi Denis-Courmont-7]

On Wednesday 12 November 2008 04:12:32 ext Fernando Gont, you wrote:
> I was wondering if there are any specific applications that actually
> need (?) port preservation. If that were the case, I guess one could
> do port preservation for specific port numbers, rather than
> enabling/disabling port preservation globally.

As far as I know, UPnP IGD works in such a way that you forward one specific
port to your own IP address - the internal and external port number is the
same. And yes, this breaks if you have two nodes using the same applications
(on the same port) behind the same NAT. That probably was not envisioned back
then.

I understand many video game protocols assume a fixed port or fixed port
range. At least my brother asked for a bunch of those when I was managing the
my parents NAT (without IGD).


But anyway, I don't see it as the NAT job to _increase_ the randomness of port
numbers. And if the NAT is not in the same "trust domain" as the NAT'ed host
(CGN), then it's even pointless. (Of course, it should avoid statistically
decreasing that randomness).

--
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Dave Hudson-3]

Fernando Gont wrote:
> I completely agree with you. My point is, precisely, that I cannot see
> what's the big deal of making port randomization a SHOULD. (If it breaks
> an app, I'd argue that the app is already broken (i.e., they cannot
> interoperate with hosts behind the other %50 of NATs that do not do port
> preservation).

Port preservation is a significant benefit to end users who have no idea
what TCP or UDP is, let alone what a port is.  There are quite a number
of apps (particularly older apps and I'm thinking about thinks like IM
clients and games) that don't use UPnP and which require users to
manually set port forwarding rules in the absence of port preservation.
  Nothing breaks by not having it but those apps don't "just work".

> Nevertheless, I'd like to know if these apps that need port reservation
> always use some specific source port, or what. If that were the case, we
> could simply preserve only those ports, and that's it.

The apps in question invariably use a specific source port but that port
is usually defined on an app-specific basis and there are hundreds or
probably thousands of different apps, each using different ports.  From
memory I've seen almost completely random ports in the rang 1024 to 64k
being used by such apps.

Another thing to consider here is that while some SOHO routers don't do
port preservation by default almost all of them (in fact all of the ones
I've looked at in the last 5 years) do have a "DMZ host" option.  The
DMZ host option forwards all packets for which there is no active
mapping to one particular host and without changing the port mapping.
Any traffic originating from the DMZ host is forwarded with port
preservation.  Such DMZ host operations are designed specifically to
help with the sorts of apps I noted above.


Regards,
Dave

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Dave Hudson-3]

Dan Wing wrote:
>
> If you find such an application, I would ask:  what happens when
> two intendances of that application are running (on the same host
> or on two different hosts) behind the same NAT?

The normal problem case is 2 hosts - if the same app can run on the same
host multiple times then it invariably can't use the same port because
only one instance of the app can't bind the socket.

In many cases the first host to use the port "wins" but in other cases
it's possible to set up a different port for the second host so you now
get 2 unique ports.

For some IM clients I've frequently found this "first host wins"
scenario, but another common usage is for games where one of the players
acts as a game server in which case often only host needs the preserved
port - in those cases on the server needs to win.

It's somewhat hit and miss of course, but in general port preservation
gives a better experience to current end users, especially with legacy apps.

FWIW within the Ubicom routing stack we made port preservation a runtime
option - it's enabled by default though.


Regards,
Dave

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Fernando Gont-2]

At 05:29 a.m. 12/11/2008, Dave Hudson wrote:

>>But anyway, I don't see it as the NAT job to _increase_ the
>>randomness of port numbers. And if the NAT is not in the same
>>"trust domain" as the NAT'ed host (CGN), then it's even pointless.
>>(Of course, it should avoid statistically decreasing that randomness).
>
>I can't see how a NAT can avoid decreasing the randomness of some
>private host if the NAT second guesses it and chooses its own idea
>of a random port.  Statistically the NAT may be significantly less
>random in its choice than the host.

Consider this scenario:
A host behind a NAT implements port randomization
The NAT overwrites the source port number, and assigns port numbers
sequentially (traditional BSD port selection algorithm)

Kind regards,

--
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Dave Hudson-3]

Rémi Denis-Courmont wrote:
>
> As far as I know, UPnP IGD works in such a way that you forward one specific
> port to your own IP address - the internal and external port number is the
> same. And yes, this breaks if you have two nodes using the same applications
> (on the same port) behind the same NAT. That probably was not envisioned back
> then.

IGD supports establishing a fixed mapping but the private and public
port numbers can be different.  In practice though I think most clients
tend to set these to the same value.

> But anyway, I don't see it as the NAT job to _increase_ the randomness of port
> numbers. And if the NAT is not in the same "trust domain" as the NAT'ed host
> (CGN), then it's even pointless. (Of course, it should avoid statistically
> decreasing that randomness).

I can't see how a NAT can avoid decreasing the randomness of some
private host if the NAT second guesses it and chooses its own idea of a
random port.  Statistically the NAT may be significantly less random in
its choice than the host.


Regards,
Dave

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Fernando Gont-2]

At 04:40 a.m. 12/11/2008, Rémi Denis-Courmont wrote:

>But anyway, I don't see it as the NAT job to
>_increase_ the randomness of port
>numbers. And if the NAT is not in the same "trust domain" as the NAT'ed host
>(CGN), then it's even pointless. (Of course, it should avoid statistically
>decreasing that randomness).

If the NAT is going to overwrite the source port
of outgoing packets, it basically has two choices:
a) Assign port numbers incrementally
b) Randomize the source port numbers

If you do "a", chances are that the host behind
the NAT was doing port randomization, and you are
"de-randomizing" :-) the source ports.
That's why I think you should do "b", unless you're doing port preservation.

Thanks!

Kind regards,

--
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Dave Hudson-3]

Fernando Gont wrote:
> If the NAT is going to overwrite the source port of outgoing packets, it
> basically has two choices:
> a) Assign port numbers incrementally
> b) Randomize the source port numbers
>
> If you do "a", chances are that the host behind the NAT was doing port
> randomization, and you are "de-randomizing" :-) the source ports.
> That's why I think you should do "b", unless you're doing port
> preservation.

But that assumes the NAT is able to choose more-random ports than the
host was able to do.  We have to assume the host is designed to give as
much randomness as it deemed necessary but we can't assume the NAT is
able to meet those same requirements.  I've seen far too many subtly
broken random number generation solutions in the past :-)


Regards,
Dave


_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Rémi Denis-Courmont-7]

On Wednesday 12 November 2008 10:31:58 ext Fernando Gont, you wrote:

> At 04:40 a.m. 12/11/2008, Rémi Denis-Courmont wrote:
> >But anyway, I don't see it as the NAT job to
> >_increase_ the randomness of port
> >numbers. And if the NAT is not in the same "trust domain" as the NAT'ed
> > host (CGN), then it's even pointless. (Of course, it should avoid
> > statistically decreasing that randomness).
>
> If the NAT is going to overwrite the source port
> of outgoing packets, it basically has two choices:
> a) Assign port numbers incrementally
> b) Randomize the source port numbers
>
> If you do "a", chances are that the host behind
> the NAT was doing port randomization, and you are
> "de-randomizing" :-) the source ports.

Yes, and I agree that's bad because it decreases randomness.

> That's why I think you should do "b", unless you're doing port
> preservation.

But you could do:
c) Pick the "next" available external port number from the internal port.

(c) does some efforts at port preservation, and will not or barely decrease
randomness.

--
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Fernando Gont-2]

At 06:08 a.m. 12/11/2008, Rémi Denis-Courmont wrote:

> > That's why I think you should do "b", unless you're doing port
> > preservation.
>
>But you could do:
>c) Pick the "next" available external port number from the internal port.
>
>(c) does some efforts at port preservation, and will not or barely decrease
>randomness.

If you are not actually preserving the port,
what's the reason for not randomizing it?
(assuming the source port was not in the range 0-1023)

Kind regards,

--
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Rémi Denis-Courmont-7]

On Wednesday 12 November 2008 11:42:06 ext Fernando Gont, you wrote:

> At 06:08 a.m. 12/11/2008, Rémi Denis-Courmont wrote:
> > > That's why I think you should do "b", unless you're doing port
> > > preservation.
> >
> >But you could do:
> >c) Pick the "next" available external port number from the internal port.
> >
> >(c) does some efforts at port preservation, and will not or barely
> > decrease randomness.
>
> If you are not actually preserving the port,
> what's the reason for not randomizing it?

That you are trying to preserve the port but happened to get into a conflict.
That you don't have good seeding for an RNG, or don't want to spoil it.

--
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Fernando Gont-2]

At 07:05 a.m. 12/11/2008, Rémi Denis-Courmont wrote:

> > If you are not actually preserving the port,
> > what's the reason for not randomizing it?
>
>That you are trying to preserve the port but happened to get into a conflict.
>That you don't have good seeding for an RNG, or don't want to spoil it.

My point is: the only argument against port
randomization has so far been that port
preservation allows some applications to work
that would otherwise not work if the ports are not preserved.

Now, if you try to do port preservation, but find
that you cannot actually preserve the port,
what's the point of sticking to non-random port
numbers that will be neither security-wise nor
will provide benefits from an interoperability point of view?

FWIW, I'd argue that algorithms #3 and #4 in
http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt 
may provide benefits not only from a security
point of view, but also from an interoperability
point of view (they may help to avoid collisions of connection-ids).

Thanks!

Kind regards,

--
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Rémi Denis-Courmont-7]

On Wednesday 12 November 2008 13:36:40 ext Fernando Gont, you wrote:

> At 07:05 a.m. 12/11/2008, Rémi Denis-Courmont wrote:
> > > If you are not actually preserving the port,
> > > what's the reason for not randomizing it?
> >
> >That you are trying to preserve the port but happened to get into a
> > conflict. That you don't have good seeding for an RNG, or don't want to
> > spoil it.
>
> My point is: the only argument against port
> randomization has so far been that port
> preservation allows some applications to work
> that would otherwise not work if the ports are not preserved.
>
> Now, if you try to do port preservation, but find
> that you cannot actually preserve the port,
> what's the point of sticking to non-random port
> numbers that will be neither security-wise nor
> will provide benefits from an interoperability point of view?

Again, no need for an RNG, or to feed said RNG.

--
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Dan Wing]

 

> -----Original Message-----
> From: Dave Hudson [mailto:ietf-behave@...]
> Sent: Tuesday, November 11, 2008 11:50 PM
> To: Fernando Gont
> Cc: Dan Wing; 'Behave Mailing List'
> Subject: Re: [BEHAVE] Question on port preservation
>
> Fernando Gont wrote:
> > I completely agree with you. My point is, precisely, that I
> cannot see
> > what's the big deal of making port randomization a SHOULD.
> (If it breaks
> > an app, I'd argue that the app is already broken (i.e., they cannot
> > interoperate with hosts behind the other %50 of NATs that
> do not do port
> > preservation).
>
> Port preservation is a significant benefit to end users who
> have no idea
> what TCP or UDP is, let alone what a port is.  There are
> quite a number
> of apps (particularly older apps and I'm thinking about
> thinks like IM
> clients and games) that don't use UPnP and which require users to
> manually set port forwarding rules in the absence of port
> preservation.
>   Nothing breaks by not having it but those apps don't "just work".

Port forwarding (as generally described at http://www.portforward.com
by configuration, and as implemented in a protocol by UPnP IGD
and NAT-PMP) is not the same as port preservation.  

Port preservation refers to how a NAT chooses the port on the public
side for a new connection.  A "port preserving NAT" will use the same
source port on the public side.  A "non-port preserving NAT" would not
use the same source port on the public side.

-d

> > Nevertheless, I'd like to know if these apps that need port
> reservation
> > always use some specific source port, or what. If that were
> the case, we
> > could simply preserve only those ports, and that's it.
>
> The apps in question invariably use a specific source port
> but that port
> is usually defined on an app-specific basis and there are hundreds or
> probably thousands of different apps, each using different
> ports.  From
> memory I've seen almost completely random ports in the rang
> 1024 to 64k
> being used by such apps.
>
> Another thing to consider here is that while some SOHO
> routers don't do
> port preservation by default almost all of them (in fact all
> of the ones
> I've looked at in the last 5 years) do have a "DMZ host" option.  The
> DMZ host option forwards all packets for which there is no active
> mapping to one particular host and without changing the port mapping.
> Any traffic originating from the DMZ host is forwarded with port
> preservation.  Such DMZ host operations are designed specifically to
> help with the sorts of apps I noted above.
>
>
> Regards,
> Dave
>

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave