Subject: [BEHAVE] Dynamic Port Reuse

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 May 2008 10:15:13 -0700

My strawman proposal is at:
http://tools.ietf.org/html/draft-wing-behave-dynamic-tcp-port-reuse-00 

Abstract:
  A strawman proposal is made to reduce public-facing TCP port use with
  large Network Address and Port Translators (NAPTs).  This proposal
  attempts to preserve emergent NAT traversal techniques.  It is
  anticipated that large NAPTs will be used for NAT64.

-d

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 May 2008 15:02:32 +0300

Hi, Dan,

a few quick comments:

(1) Meta-comment: Why wouldn't large NAPT boxes simply use multiple  
public IP addresses to avoid running out of ports?

(2) I don't understand why ALGO-1 is claimed to support client/server  
cases well. Client/server communication is characterized by the server  
listening on a single well-known port. It's hence not possible to  
reuse the same source port on the NAPT for another connection, because  
that'd clash with an existing 5-tuple. ALGO-1 can only reuse source  
ports for connections to different services (on different destination  
ports), which is what Figure 1 shows.

(3) The changes to applications that ALGO-2 requires are more invasive  
than just signaling that UNSAF is being used, because applications may  
also need to change their transmission behavior to conform to the  
"hold time" the NAPT now uses. It's IMO problematic to assume any  
application or transport protocol changes will happen.

(4) Regarding cleanup for ALGO-2 and ALGO-3, you say that the NAT can  
start reusing the port if it sees FIN or RST or other shutdown  
indication (ICMP?). That is not sufficient. RFC793 and especially  
draft-ietf-tcpm-tcpsecure specify that for examples RSTs MUST be  
ignored if they don't satisfy certain validity checks. draft-ietf-tcpm- 
icmp-attacks discusses similar deployed validity checks on ICMPs.

Lars

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 May 2008 08:09:08 -1000

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Wednesday, May 21, 2008 2:03 AM
> To: ext Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Dynamic Port Reuse
> 
> Hi, Dan,
> 
> a few quick comments:
> 

Sure, but that, too, has complications.  One that Greg Lebovitz 
mentioned at two different BEHAVE working group meetings is that
some HTTP servers, or their back-end software, was sensitive to
multiple connections from the same client arriving from different
IP addresses; it was suggested that the HTTP server's cookies
were tied to the client's IP address.

And the primary motivation for me to write this up was v4 address
conservation on the NAT64 box.

> that'd clash with an existing 5-tuple.
>
> ALGO-1 can only reuse source  

ALGO-1 can use the same source TCP port if the two TCP 
connections are going to two servers (e.g., www.cnn.com/80, 
www.ietf.org/80).

> application or transport protocol changes will happen.

Everthing is a tradeoff.  Would extending the proposed timer from
30 seconds to 60 or 90 or 120 seconds reduce your concern?

Several other people have proposed using port numbers to decide if 
UNSAF was being used, under the assmption that TCP/80, TCP/110 
(POP3), etc., don't use UNSAF.  That is certainly another direction 
to pursue.  My concern with that mechanism is that it would create
the first instance where a NAT's behavior is radically different
based on the port number.

> icmp-attacks discusses similar deployed validity checks on ICMPs.

Sure, I'll clean that up in a future version.  That's easy.

-d

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 May 2008 17:58:37 +0300

Hi,

> were tied to the client's IP address.

OK, so to work around that bug, you'd need to map NAT clients to  
public addresses persistently, and you'd loose some multiplexing  
efficiency.

> conservation on the NAT64 box.

Understood, but are we really _that_ stressed for v4 space yet?

> connections are going to two servers (e.g., www.cnn.com/80,

Sure, but that's equivalent to the above in that the 5-tuple is unique.

I think I misunderstood the "ALGO-1 should work very well for client/ 
server applications" part. ALGO-2 would actually better for (non- 
UNSAF) client/server apps, in the sense that it allows more  
multiplexing.

> 30 seconds to 60 or 90 or 120 seconds reduce your concern?

No, because irrespective of what the hold time is, defining one is  
what can potentially be a problem, because the NAPT now assumes that  
if an app hasn't done X in time Y, it will never do so.

But given that NAPTs aren't behaving very consistently anyway, maybe  
the hold time won't matter. Someone should run some experiments :-)

> based on the port number.

Right. IMO that proposal goes counter to the idea behind BEHAVE, which  
is to make NATs more regularized. Having the NAPT act differently  
based on what port numbers are used actually makes their behavior more  
diverse instead of more regularized.

The key question is how a NAPT can accurately differentiate apps that  
use UNSAF from ones that don't, because that's the characteristic that  
can be used to drive more efficient connection multiplexing. You  
propose doing this based on the observable transmission behavior,  
Iljitsch/Remi have suggested doing it based on destination ports. Both  
have pros and cons. Do other options exist?

Lars

---

From: Rémi Després <[email-masked]>
Date: Thu, 22 May 2008 17:59:11 +0200

> diverse instead of more regularized.

IMU, using a new method to solve a problem that has not been solved yet 
is not per se a problem.

Also, isn't it true that all ALGs that identify applications based on 
port numbers, and act specifically based on that, have already 
introduced NAT behaviors that depend on port numbers?

Finally, trying to identify applications based on timings of established 
connections seems to me unnecessarily complex and unreliable, especially 
to solve a problem that is trivial if ports are used.

For more details on how port-based application identification can 
contribute to "regularize" NATs, at least those that have to  use 
addresses and ports sparingly:
http://www.ietf.org/mail-archive/web/behave/current/msg03880.html

Rémi

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 22 May 2008 12:25:06 -0400

> http://www.ietf.org/mail-archive/web/behave/current/msg03880.html

A P2P application would almost certainly have the characteristics 
required by Dan's algorithms.  Whereas it would almost certainly not 
have the port numbers the other proposal is looking for.

I could see a hybrid where a NAT can assume that connections to http, 
smtp, ssh are assumed to be compatible with endpoint-dependent mapping, 
but relying on a technique that assumes it can identify an application 
that requires independent mapping with a set of port numbers is doomed 
to failure.  It just can't work when other peers are behind there own 
nats, or in the presence of double natting.

Bruce

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 May 2008 08:13:17 -1000

> Sent: Thursday, May 22, 2008 4:59 AM
> To: ext Dan Wing
> Cc: [email-masked]

The proposal is primarily for NAT64, so these would be new devices
that could -- if we specify the requirements adequately -- operate
with more consistency than today's NATs.

> have pros and cons. Do other options exist?

Those are the two proposals that I have seen.  I believe they
could reasonably be combined.  For example, from my perspective
with timers, I consider Iljitsch/Remi's proposal as using a 0-second 
timer for certain ports (e.g., TCP/80) and an infinite timer for other
ports.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 May 2008 08:20:46 -1000

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Thursday, May 22, 2008 5:59 AM
> To: Lars Eggert
> Cc: [email-masked]; ext Dan Wing

The distinction is that IETF did not standardize ALGs -- even
though every vendor ships one (FTP-aware ALGs most especially).  I
believe the only references to ALGs are in informational documents.
I expect if I'm wrong, someone will be quick to reply.  :-)

> connections seems to me unnecessarily complex and unreliable, 

Running a timer isn't too complex, and the NAPT knows about
new mappings that it needs to create when a new flow starts.

As to unreliable ...  Yes, it could be unreliable, but only
for those applications using UNSAF.  For client/server applications 
(e.g., HTTP), it is as reliable as using port numbers to decide the
NAPT's behavior.

> especially 

I do agree that using ports is easier.  But I don't see how we
would create a list of such ports, or how an application would
know which ports have port-reuse and which ports have no-port-reuse.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 23 May 2008 09:55:37 +0300

>   anticipated that large NAPTs will be used for NAT64.

ALGO-1 as it stands might break TCP. A NAT must not reuse the same port number 
for a different internal IP:port typle, toward the same remote IP:port tuple.

In any case, ALGO-1 breaks TCP-SO. I think the real issue is, whether 
TCP-SO/IPv4 really matters.... It would seem so unreliable that people will 
end up using UDP.

-- 
Rémi Denis-Courmont

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 May 2008 10:37:10 +0300

Hi,

On 2008-5-22, at 18:59, ext Rémi Després wrote:
> Also, isn't it true that all ALGs that identify applications based  
> on port numbers, and act specifically based on that, have already  

ALGs can't (only) depend on port numbers, because they also need to  
parse the application protocol to do their job. So if I run telnet on  
port 21 through a NAT, hopefully the FTP ALG implementor was smart  
enough to not only look at the port number.

(It'd be interesting to know if the "better" NATs allow an  
administrator to configure ALGs to monitor non-standard ports, too.)

> Finally, trying to identify applications based on timings of  
> established connections seems to me unnecessarily complex and  
> unreliable, especially to solve a problem that is trivial if ports  
> are used.

Both current proposals have advantages and disadvantages, and the  
tradeoffs need to be understood. I'm not a particular fan of using  
either ports or timers - both are crufty - because I'm still  
unconvinced that we actually need to solve this problem in the first  
place. Anyone got data about how often NATs run out of binding entries  
in situations where another IPv4 address isn't available?

Lars

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 May 2008 10:17:52 +0200

> TCP-SO/IPv4 really matters.... It would seem so unreliable that people will 
Is there a reference where the the nature and the scope of the alleged 
TCP-SO problem is identified?

RD

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 23 May 2008 11:33:11 +0300

Le Friday 23 May 2008 11:17:52 ext Rémi Després, vous avez écrit :
> > TCP-SO/IPv4 really matters.... It would seem so unreliable that people
> > will end up using UDP.
>

That would be the IETF70 and 71 proceedings of MMUSIC and BEHAVE.

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 May 2008 10:59:25 +0200

> enough to not only look at the port number.
Although some ALGs may be activated depending on some data parsing, some 
(e.g. FTP) do depend IMU on port numbers to be activated.

This is enough IMO to consider that a different NAT behavior based on 
ports would not be new (which was the point under discussion).

Running Telnet on the port of FTP seems strange to me, and IMO should 
not justify to make NATs any more complex.

> either ports or timers - both are crufty -
IMO, simplicity and reliability are the strong points in favor of ports 
vs timings.
So far, there is IMU no strong point in favor of timings.

> I'm still unconvinced that we actually need to solve this problem in
> the first place. Anyone got data about how often NATs run out of
> binding entries in situations where another IPv4 address isn't
> available?
The point is that more and more NATs are within ISP infrastructures. 
They are shared by potentially very large numbers of users, and may ahve 
to support huge numbers of UDP-TCP connections.

These NATs may in the future, in particular for the v4-v6 coexistence 
period, be replaced by  more scalable functions like those based on an 
address-port borrowing protocol (APBP). But the need to use sparingly 
address-port couples can only be mitigated, not suppressed.

If nothing else, susceptibility of these NATs, or APBP servers, to DOS 
attacks will strongly depend on their margin between available 
address-port couples and those that are normally used.

Rémi

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 May 2008 11:53:07 +0200

On Fri, May 23, 2008 at 10:59:25AM +0200,
 Rémi Després <[email-masked]> wrote 
 a message of 58 lines which said:

> Running Telnet on the port of FTP seems strange to me, 

A more realistic example would be running SSH over port 443
(https). This is very common practice because many "Internet"
providers (for instance, in France, Orange/3GPP) allow access only to
a few ports such as 80 and 443.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 May 2008 11:57:15 +0200

> That would be the IETF70 and 71 proceedings of MMUSIC and BEHAVE.
Thanks.

It clarifies IMU that the scope of the identified TCP-SO problem is that 
of applications that use ICE to traverse NATs.

These apllications are not subject to endpoint-dependent mapping with my 
proposal, now summarized as:
"endpoint-dependent mapping authorized iff the destination port of the 
packet that initiates the mapping is that of an application that 
supports it, i.e. FTP, DNS..."

Whether BitTorrent ports can be in the list is IMU still debated.

(The assumption is made that STUN connections of ICE are not done on 
ports of the FTP, DNS... list. But doing it would IMU be a very bad idea.)

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 May 2008 12:22:39 +0200

> a few ports such as 80 and 443.
Thanks for the info.
SSH on HTTPS should not be problematic because IMU neither one needs an ALG.

A difficult case would be one where the port of an application that 
needs an ALG is used for an application that doesn't.

Rémi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 May 2008 12:50:16 +0200

> have pros and cons. Do other options exist?
IMHO there is another important difference that is whether the default 
behaviour is endpoint independent or endpoint dependent.
In Iljitsch approach as i undrstood it, anything that does not uses the 
STUN ports is endpoint depedent. Default behaviour is then endpoint 
dependent mapping
A port approach could have a default endpoint indepedent behaviour 
except for those well know apps that are know to not require endpoint 
independent behaviour, like HTTP. (this could be similar to Remi 
approach, see my email to him)

In the timer approach, everything that does not benefits within the 
timeout is endpoint dependent. This is

imho, i think we are on the safe side if we only do endpoint depednent 
mappings for very well know widely deployed apps that don't use it. I 
mean, i don't think port 80 will be used in a different way anytime soon.

This would save quite some ports, cause they are the most widely used apps

All the rest should be endpoint independent, and we allow for future 
apps to benefit from the endpoint independency

Regards, marcelo

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 23 May 2008 11:12:37 -0400

> timer for certain ports (e.g., TCP/80) and an infinite timer for other

I think my preference would be to specify endpoint-dependent mapping 
only on "known safe ports", but I do think that the timers option is an 
intriguing idea.

The only problem I have with the timers idea is that its success for p2p 
seems to be dependent on the number of external connections (through the 
NAT) required by the application.  Which I suspect means that if the NAT 
box is in front of only a few thousand machines, then most p2p apps 
would easily meet the timer requirement because their connections would 
cross the NAT.  But if the p2p application is part of an overlay that 
exists entirely (or almost entirely) behind the NAT, either because it's 
a local group or because the NAT is in front of an entire ISP, it seems 
to be less likely that the timer condition will be met.

Maybe the right way to combine these is to view the timer as a fallback 
condition.  So here's a new proposal:

An address-port sparing NAT MAY use endpoint dependent mapping for 
connections whose destination port specifies a known-compatible protocol 
(HTTP, SMTP, etc).  Otherwise, it MUST default to endpoint-independent 
mapping characteristics.  In the event of overload, where it is no 
longer able to preserve endpoint independent mapping for new 
connections, the NAT MAY apply the timer algorithm to prioritize which 
connections receive endpoint-dependent mapping.

(obviously the list of ports, definition of overload, and the timer 
algorithm need work)

Bruce

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 May 2008 18:47:41 +0200

> connections receive endpoint-dependent mapping.

I really don't like the last part. Essentially this would result in non 
deterministic behaviour, since a nat could be endpoint independet or 
endpoint dependent depending on the load and i think we must avoid that

I would simply keep the first two parts and remov the last one

regards, marcelo

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 23 May 2008 14:14:13 -0400

marcelo bagnulo braun wrote:
>>>> Right. IMO that proposal goes counter to the idea behind BEHAVE, 
>>>> which  is to make NATs more regularized. Having the NAPT act 
>>>> differently  based on what port numbers are used actually makes 
>>>> their behavior more  diverse instead of more regularized.
>>>>
>>>> The key question is how a NAPT can accurately differentiate apps 
>>>> that  use UNSAF from ones that don't, because that's the 
>>>> characteristic that  can be used to drive more efficient connection 
>>>> multiplexing. You  propose doing this based on the observable 
>>>> transmission behavior,  Iljitsch/Remi have suggested doing it based 
>>>> on destination ports. Both  have pros and cons. Do other options exist?
>>>>       
>> only on "known safe ports", but I do think that the timers option is 
>> an intriguing idea.
>>
>> The only problem I have with the timers idea is that its success for 
>> p2p seems to be dependent on the number of external connections 
>> (through the NAT) required by the application.  Which I suspect means 
>> that if the NAT box is in front of only a few thousand machines, then 
>> most p2p apps would easily meet the timer requirement because their 
>> connections would cross the NAT.  But if the p2p application is part 
>> of an overlay that exists entirely (or almost entirely) behind the 
>> NAT, either because it's a local group or because the NAT is in front 
>> of an entire ISP, it seems to be less likely that the timer condition 
>> will be met.
>>
>> Maybe the right way to combine these is to view the timer as a 
>> fallback condition.  So here's a new proposal:
>>
>>
>> connections whose destination port specifies a known-compatible 
>> protocol (HTTP, SMTP, etc).  Otherwise, it MUST default to 
>> endpoint-independent mapping characteristics.  In the event of 
>> overload, where it is no longer able to preserve endpoint independent 
>> mapping for new connections, the NAT MAY apply the timer algorithm to 
>> prioritize which connections receive endpoint-dependent mapping.
>>   
> 
> 

Well, OK.  I don't really like the behavior much either and would prefer 
   to mandate endpoint-independent mapping all the time for all ports. 
  But removing the third part just leaves the behavior in the event of 
overload undefined.  That's not clearly better than specifying a 
not-too-terribly-evil thing to do in an overload scenario, is it?

Bruce

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 08:52:12 -1000

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2008 8:56 PM
> To: [email-masked]
> Cc: ext Dan Wing

The top of section 3 acknowledges that:

   With all algorithms proposed below, a new TCP connection from an
   internal host cannot re-use the same public TCP source port and
   address to the same remote destination port and address (i.e., you
   cannot use the same 5-tuple for a new connection).

> TCP-SO/IPv4 really matters.... It would seem so unreliable 

ALGO-1 is only intended to work for "client/server applications", such
as SMTP, HTTP, POP3, IMAP, BitTorrtent, etc.  For those client/server 
applications, I do not believe we need TCP simultaneous open.

If you want TCP simultaneous open, you would need ALGO-2 or ALGO-3 which
are UNSAF-safe (that is, they work with UNSAF and ALGO-2 and ALGO-3 
should work just fine with TCP simultaneous open).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 09:16:37 -1000

> not-too-terribly-evil thing to do in an overload scenario, is it?

Using port numbers is, itself, non-deterministic.  This is because
no two people will generate the same list ports that are safe to
re-use.  If ports are used, then in 3 years, as NAT64 vendors find
value in optimizing re-use of other port numbers, the vendors will
begin diverging which ports are re-used.

For example, here would be my list of ports that are safe to re-use:
TCP/80 (HTTP), TCP/110 (POP3), TCP/995 (POP3S), TCP/143 (IMAP), TCP/587
(SUBMIT), TCP/25 (SMTP), TCP/22 (SSH), TCP/21 (FTP), TCP/23 (TELNET),
TCP/7 (ECHO), TCP/9 (DISCARD), TCP/993 (IMAPS).

Are there non-IETF protocols that are used which would break with
port re-use?  That is, that use UNSAF or use TCP S-O?

As BitTorrent has not registered their ports with IANA, I'm not sure
what could be said in an IETF document about its ports other than 
some non-normative "and other ports that the NAT64 believes, to the
best of its knowledge, are used by client/server applications that
can safely have their TCP source ports re-used."  Which brings us
to specify non-deterministic behavior for such a NAT64.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 11:27:19 -1000

> IMO, simplicity and reliability are the strong points in 
> favor of ports vs timings.

Please build a list of ports, so we can talk about them specifically
instead of generally.

> So far, there is IMU no strong point in favor of timings.

The advantage of timing port re-use is self-learning and self-
adjusting to the needs of the TCP application.

Whether any of us consider that a 'strong point' is, I agree, a 
matter of debate.

...
> address-port couples and those that are normally used.

Yes, an ISP's NAT will certainly have to limit how many ports they 
allocate to any particular subscriber.  Even low-end home NATs
do this today (for all hosts behind the NAT) so they don't consume 
all of their memory with connection tables.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 11:27:19 -1000

> in situations where another IPv4 address isn't available?

For whatever it's worth:

Some University of Colorado researchers filled up their NAT's binding table,
unbeknownst to them: 
http://systems.cs.colorado.edu/mediawiki/index.php/Broadband_Network_Managemen
t

And I have done the same with my home NAT when using FTP to mirror the
Internet-Drafts archive (the separate FTP data connections consumed all of my
NAT's binding table entries).  My home NAT (a Linksys WRT54G with 3rd party
firmware) is configured to remember about 1000 UDP and TCP bindings.

The difference is that with NAT64, it isn't just yourself you would harm by
consuming all of the TCP ports on the NAT -- it is everyone else using that
NAT64 who cannot, now, obtain another TCP port.  The reason for NAT64 is to
avoid giving every subscriber their own IPv4 address and to get multiple
subscribers NATted to one IP address.  As Iljitsch described in the middle of
http://www.ietf.org/mail-archive/web/behave/current/msg03821.html, some
commonly-deployed applications and commonly-accessed Web 2.0 sites cause a lot
of TCP connections to be created, which reduces the number of subscribers an
ISP could expect to place behind a single IPv4 address.

-d

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 23 May 2008 17:33:18 -0400

> to specify non-deterministic behavior for such a NAT64.

So does that leave anything other than telling the people interested in 
NAT64 scalability that the NATs need to be big enough to not suffer from 
port overload?  I disbelieve that it's ever going to be possible to do 
such a thing (one misbehaving application can consume an awful lot of 
ports).  I don't know whether I believe BEHAVE can have an impact on how 
vendors develop such a device, but it seems like specifying BCP that are 
more likely to not break the world than other behaviors is useful from 
an engineering point of view.

I agree that creating a lengthy list is probably an unending task.  (I 
would argue against including bittorrent in there.)  But I think there 
is a core of widely distributed applications that probably 99% of the 
people in the room would agree with.  Even if that list is only HTTP, 
SMTP, POP, SSH, and IMAP, it will help here.  It will probably needed to 
be updated every n years to keep it current (or IPv6 will be universally 
deployed and the list can be allowed to rus).

I wasn't trying to make the argument that using port numbers was 
deterministic, only that leaving overload behavior entirely unspecified 
seems likely to produce the kind of variety of broken behavior that 
motivated BEHAVE to be formed in the first place.  If the timer 
algorithm helps to allow a NAT to avoid imposing endpoint dependent 
mapping on EVERY application when it experiences high load, that's not 
too bad of a result.  That level of load IS going to happen.

Bruce

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 11:55:14 -1000

> From: Bruce Lowekamp [mailto:[email-masked]] 
> Sent: Friday, May 23, 2008 11:33 AM
> To: Dan Wing
> Cc: 'marcelo bagnulo braun'; [email-masked]
> So does that leave anything other than telling the people 
> interested in NAT64 scalability that the NATs need to be big 
> enough to not suffer from port overload?  I disbelieve that it's 
> ever going to be possible to do such a thing (one misbehaving 
> application can consume an awful lot of ports). 

Yes, of course the NAT needs to protect itself from such intential
or unintentional abuse.  As I said in another post (which is not
yet archived),

  > Yes, an ISP's NAT will certainly have to limit how many 
  > ports they allocate to any particular subscriber.  Even low-end 
  > home NATs do this today (for all hosts behind the NAT) so they 
  > don't consume all of their memory with connection tables.

> I don't know 
> whether I believe BEHAVE can have an impact on how 
> more likely to not break the world than other behaviors is 
> useful from an engineering point of view.

The IETF's view of IPv4 NATs has historically been see-no-evil, 
hear-no-evil, speak-no-evil:  there were no specifications and
thus the "desert bloomed" with literally dozens of different
NAT styles, NAT traversal mechanisms (ALGs and no ALGs, FTP PASV,
etc.), with no overall thought or plan to how it would work in
the end other than allowing the market to sort it out.

We have an opportunity to create a specification for NAT64 and
get out of this rut.

> deployed and the list can be allowed to rus).

Yes, we may well be successful in identifying some set of ports for
client/server applications.  

But are we sure there are no UNSAF applications or applications
that need TCP S-O which run on TCP/80?  Many applications do attempt
to run on TCP/80 in an effort to work through enterprise firewalls that 
only allow TCP/80 -- Cisco and other vendors have deployed IDS and
firewalls that inspect TCP/80 traffic in an effort to block such non-HTTP
applications.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 12:03:31 -1000

> > TCP-SO/IPv4 really matters.... It would seem so unreliable 
> > that people will end up using UDP.
>
> Is there a reference where the the nature and the scope of 
> the alleged TCP-SO problem is identified?

See http://saikat.guha.cc/paper.php?id=imc05-guha:tcp

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 May 2008 12:44:01 +0200

Bruce Lowekamp escribió:
>>> overload, where it is no longer able to preserve endpoint 
>>> independent mapping for new connections, the NAT MAY apply the timer 
>>> algorithm to prioritize which connections receive endpoint-dependent 
>>> mapping.
>>>   
>>
>>
>> I really don't like the last part. Essentially this would result in 
>> non deterministic behaviour, since a nat could be endpoint independet 
>> or endpoint dependent depending on the load and i think we must avoid 
>> that
>>
> Well, OK.  I don't really like the behavior much either and would 
> prefer   to mandate endpoint-independent mapping all the time for all 
> ports.  But removing the third part just leaves the behavior in the 
> event of overload undefined.  That's not clearly better than 
> specifying a not-too-terribly-evil thing to do in an overload 
> scenario, is it?

For me in case of overloading, packets are discarded and an error
message is sent back to the sender.

I mean, i rather that things fail deterministically rather than work in
an unpredictable way

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 May 2008 12:44:13 +0200

> ISP could expect to place behind a single IPv4 address.

right, but you can deal with this, if you have more public IPv4 addresses.

The problem will be critical when we run out of v4 addresses

the question is whether we should deal with this problem now or wait
till later (when we run out of v4 addresses and there is no clear uptake
of the v6 protocol and we are really into deep trouble)

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 May 2008 12:44:41 +0200

Dan Wing escribió:
>> independent 
>>>> mapping for new connections, the NAT MAY apply the timer 
>>>>         
>> algorithm to 
>>     
>>> I really don't like the last part. Essentially this would 
>>>       
>> result in non 
>>     
>>> deterministic behaviour, since a nat could be endpoint 
>>>       
>> independet or 
>>     
>>> endpoint dependent depending on the load and i think we 
>>>       
>> must avoid that
>>     

but this goes beyond what we can do i guess

i mean, all what the ietf can do is to produce a spec. If people don't
follow the spec, then we are out of luck.

Having a list like the one you mention below in a RFC would result in
deterministic behaviour, if people implement it as specified.

I do agree that it is not very attractive to open that door cause it
would tempt implementers to do it for other ports

In general i think that all options for port reuse are bad cause the
reduce flexibility assuming some form of application behaviour.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 May 2008 16:40:23 +0200

> Understood, but are we really _that_ stressed for v4 space yet?

In a word: yes.

The IETF process is such that it's unrealistic to expect to go from  
initial discussion through rough consensus to RFC publication in less  
than two years. Then the vendors need some time to implement the RFC  
and the operators to deploy the new hard/software.

According to http://www.potaroo.net/tools/ipv4/ we are scheduled to  
run out of IPv4 addresses in november 2011.

> diverse instead of more regularized.

Unfortunately, if we want scalability we can't afford to do the right  
thing under all circumstances. Defining under which circumstances we  
will be doing the right thing and under which circumstances we won't  
seems like a good second choice. More so than things like timing,  
destination port is relatively easy to change and easy to determine by  
everyone involved.

> have pros and cons. Do other options exist?

An interesting observation is that in order to make use of endpoint  
independent mappings, a host needs to run STUN. So if the first  
session on a new port number is STUN then we know we need endpoint  
independent mapping. If it isn't, then we very likely don't.

Another option would be to dynamically correlate destination ports  
that a host is communicating with with the use of ephemeral source  
ports. Once a certain level of consistency is observed, it would then  
be possible to use endpoint dependent/independent mapping for  
destination ports in subsequent sessions.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 May 2008 16:44:23 +0200

> client/server applications.

As long as we can identify the ones that use up many ports in practice  
we should be in reasonable shape, there is no need to make an  
exhaustive list.

> firewalls that inspect TCP/80 traffic in an effort to block such non- 

[Being new to this group I have no idea what "UNSAF" is or where I  
need to go to find out... A pointer please?]

If both ends are hampered in this way they can't communicate even with  
simultaneous open. I'm also guessing that anyone being this  
restrictive won't be prepared to receive incoming sessions so endpoint  
independence is of no use.

And of course throwing away 65535 perfectly good ports doesn't really  
help scalability.

If people are really determined to shoot themselves in the foot  
there's not much we can do.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 May 2008 17:46:47 +0200

Iljitsch van Beijnum escribió:
> thing under all circumstances. 

well you can, this is called IPv6
I mean, NATs are endpoint independent and if you need more addresses,
you should use IPv6

that's one way of doing it

Of course the question then is if the IETF has enough strength to
support such approach, cause if not people would start building nats
that do port sparing in they way they see fit, and we end up in the
worst scenario

> Defining under which circumstances we  
> independent mappings, a host needs to run STUN. 

This is not the case actually

One way of using endpoint indepednecy is to use stun

There are other ways to do this

For instance, applications can do nat traversal themselves and they
don't use stun. I guess VOIP apps already do this. This is perfeclty ok
and the architecture should support that

> So if the first  
That's again assuming some application bhaviour (as in the other approaches)

In this case, you assume that application will use STUN for nat traversal

AFAIK, the ietf is not imposing stun as the only mean to traverse NATs
and doing application layer nat travrsal is a valid optiuon, that would
be render more complicated if we do this

Bottom line, hardcoding in the architecture application behaviour is a
bad idea.

So far all the proposal we have hardcode some for of behaviour:
- the timer approach hardcode the application behaviour that the
incoming communication will occur within a given timeout
- the port approach hardcode the application behaviour that certain
applications that use certain ports do not need endpoint independence
- the stun approach you mention above hardcode the application behaviour
that application only use stun for nat traversal

The question is which one of these seems like the strongest assumption

IMHO, assuming that in TCP port 80 will be used only for http and that
http will not require endpoint independence seems a reasonable 
assumption, and doing this for very well know ports would save tons of 
wasted ports and sems a reasonable tradeoff to me

> destination ports in subsequent sessions.

how would you do that?

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 25 May 2008 17:19:27 +0200

On 24 mei 2008, at 17:46, marcelo bagnulo braun wrote:

>> Unfortunately, if we want scalability we can't afford to do the  
>> right  thing under all circumstances.

> I mean, NATs are endpoint independent and if you need more addresses,

I was of course speaking within the context of using NAT(64).

As you know, I've argued before that supporting peer-to-peer  
applications in NAT64 is unnecessary because those applications can be  
run over IPv6.

If we can get rough consensus on that we can then specify endpoint  
dependent mapping for NAT64 and there is no scalability issue.

Note that there are two types of peer-to-peer applications: the ones  
where each peer must be able to communicate with any given other peer  
(like in VoIP, where you want to be able to call everyone) and the  
ones where there is no requirement that every two peers can  
communicate, as long as every peer can communicate with a reasonably  
sized subset of all peers and there is some overlap between the  
subsets. (I.e., with BitTorrent if 45% of the peers is v4, 45% is v6  
and 10% is dual stack everyone will be able to complete the download.)

For VoIP-type applications migration to IPv6 is hard, for BitTorrent- 
type applications it's easy.

> that do port sparing in they way they see fit, and we end up in the

I don't necessarily agree that this is the worst scenario. The worst  
scenario is that users can't run their applications. If we can't make  
that happen 100% of the time we should at least maximize the chances  
of things working. Consistently not working is the worst case  
scenario, even though inconsistently working a small fraction of the  
time is more frustrating.  :-)

>> An interesting observation is that in order to make use of  
>> endpoint  independent mappings, a host needs to run STUN.

> and the architecture should support that

Right. On the other hand, if we can make a solution that works well  
and scales well but only if applications use STUN I'll take that over  
the situation where things either don't work well or don't scale well  
because we don't want to force people to use STUN. Same thing for  
building in port-dependent behavior.

> Bottom line, hardcoding in the architecture application behaviour is a

What we're doing here isn't architecture, it's hacks to make things  
work.

If you want a clean architecture, use IPv6 with provider aggregatable  
addresses and no firewalling. Then you get full end-to-end and  
scalability. Unfortunately, people seem to value other things above  
those two aspects.

> that application only use stun for nat traversal

Another option would be to use a TCP option to indicate that endpoint  
independent mapping is required. However, getting clients to put  
options into TCP headers is probably a hard thing to do within a  
reasonable timeframe. But maybe it's doable to make STUNT and SIP  
servers and BitTorrent trackers etc do this on the SYN/ACK rather than  
having the client do it on the SYN.

> assumption, and doing this for very well know ports would save tons  
> of wasted ports and sems a reasonable tradeoff to me

Agree.

>> ports. Once a certain level of consistency is observed, it would  
>> then  be possible to use endpoint dependent/independent mapping  
>> for  destination ports in subsequent sessions.

> how would you do that?

Well, if you see an internal host set up 20 sessions towards port 80  
for different external systems and use a different source port each  
time it's a reasonable guess that new sessions towards port 80 don't  
need endpoint independence.

---

From: Rémi Després <[email-masked]>
Date: Mon, 26 May 2008 08:22:26 +0200

> have pros and cons. Do other options exist?
For an exact record of who did what:
- Iljitsch van Beijnium introduced the  *requirement* in details
(http://www.ietf.org/mail-archive/web/behave/current/msg03824.html)
- I introduced the principle of destination ports in "packets that 
initiate addresss-port mappings" indicate whether endpoint independent 
mapping is needed or not.
(http://www.ietf.org/mail-archive/web/behave/current/msg03824.html)
- Bruce Lowekamp introduced the principle that endpoint independent 
mapping remain the default behavior, endpoint depenency being limited to 
mappings where initial destination ports indicate its possibility.
(http://www.ietf.org/mail-archive/web/behave/current/msg03845.html)

Pros and cons are still being debated;
Also debated is whether BitTorrent ports as initial destination ports 
indicate that endpoint dependency is possible (if yes, the saving on 
address-port consumption can be huge).

Regards.

Rémi Després

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 26 May 2008 09:34:33 +0300

> need to go to find out... A pointer please?]

RFC3424.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 25 May 2008 22:30:47 -1000

...
> reduce flexibility assuming some form of application behaviour.

Good point.  And to keep it on everyone's mind, IPv4 NAPTs did something
similar:  they introduced IP address reuse which -- as we all know too well --
worked great with assumed application behavior (client/server UDP and TCP
applications work pretty well with NAPTs).

-d

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 May 2008 11:31:32 +0300

Hi,

On 2008-5-23, at 11:59, ext Rémi Després wrote:
> IMO, simplicity and reliability are the strong points in favor of  
> ports vs timings.

I understand that you have a clear preference, but I don't, so I'll  
not continue this argument here.

> They are shared by potentially very large numbers of users, and may  
> ahve to support huge numbers of UDP-TCP connections.

Understood. But my question is *why* do you think that ISP-run NATs  
will quickly run out of IPv4 addresses? Because we don't have a  
problem with NAT scalability as long as there are IPv4 addresses to  
throw at the problem. And due to the multiplexing the NAT provides,  
we'll need significantly fewer public IPv4 addresses than one per user  
(which is what we currently have without a NAT64) for the NAT. (Unless  
you assume that each user will end up having 65K active connections.)

> If nothing else, susceptibility of these NATs, or APBP servers, to  
> DOS attacks will strongly depend on their margin between available  

I don't quite parse this sentence, but if it's saying that more a  
efficient connection multiplexing is a security mechanism, I disagree.  
All it does is buy you a little more breathing room.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 May 2008 11:38:24 +0300

Hi,

On 2008-5-24, at 17:40, ext Iljitsch van Beijnum wrote:
> initial discussion through rough consensus to RFC publication in  
> less than two years. Then the vendors need some time to implement  
> the RFC and the operators to deploy the new hard/software.
>

sure, but we might be able to free up IPv4 addresses that so far have  
been allocated to end users and use them to support the NAT64 boxes.  
Unless users end up having 65K connections active, the NAT will be  
more efficient at multiplexing, and there'll be a win.

I'm curious to know if you'd think that this scenario isn't realistic?

Lars

---

From: Rémi Després <[email-masked]>
Date: Mon, 26 May 2008 12:14:52 +0200

> applications work pretty well with NAPTs).

IMU, the whole point of standardization is to obtain more compatibility, 
or to achieve more scalability, or to gain more security, or etc., 
accepting for this to reduce flexibility (in a well chosen manner). It 
has to be a trade-off.

In the particular case, the only consequence of the last proposal 
(leaving BitTorrent aside for the time being) is as follows:
If you use an HTTP, HTTPS, DNS, POP3, IMAP, or SNMP server port for 
something else than HTTP, HTTPS, DNS, POP3, IMAP, or SNMP (which 
obviously is not recommended) you should better make sure this is not 
precisely for one of the few applications that need endpoint-independent 
mapping.

BTW, it would be nice to know which applications need endpoint 
independent mapping other that those that start with STUN-SUNT-TURN-ICE 
  (which go together), and with Teredo?

Rémi

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 26 May 2008 13:21:17 +0300

>   (which go together), and with Teredo?

Many video games and a bunch of VoIP/conferencing applications using many 
different non-IETF protocols.