Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg

From: Cullen Jennings <[email-masked]>
Date: Sun, 01 Jun 2003 19:00:26 -0700

On 5/27/03 2:12 AM, "john Holdsworth" <[email-masked]>
wrote:

> The big issue for STUN is that it won't work with most (95%+?) of corporate
> NATs and firewalls which translate ports on a symmetric basis. That is if
> any of the source or destination details change a new NAT mapping is
> employed. This makes STUN useless.
>

This is simply not true and you probably don't understand what "symmetric"
means as defined in the STUN RFC - the RFC does use "symmetric" to mean
something somewhat different from what most NAT developers would mean by the
term so I do forgive the confusion to most people. Go test a Cisco IOS or
PIX based "corporate grade NAT" - you will find they are not symmetric. You
might be surprised on tests from other NATs vendors too. You will find your
95% number is very wrong.

The difference between "symmetric" and "port restricted" in STUN is nothing
to do with the security of what packets are allowed through the NAT but is
determined by if the NAT reuses port numbers when it can. Given "corporate
grade" NATs only have 65k ports per IP and don't want to run out of ports,
they generally choose to reuse the ports. This makes them port restricted
instead of symmetric. This leads to a natural tendency away from symmetric
on large NATs. 

On small NATs, such as the type that might be in your home, there is no
worry on running out of ports so more or less random things are done between
symmetric and port restricted on these devices. I have been talking to a few
of the "home NAT" vendors and explaining that:
1) symmetric and port restricted are the same from a security point of view
2) they are about the same to implement from a complexity, memory footprint,
and speed point of view
3) port restricted helps VoIP system
4) port restricted helps networked games

None of them have identified any concerns on why symmetric might be
preferred to port restricted. For some reason, 4 seems much more compelling
to them than 3. Go figure. Of course an exception to the "ho-hum" about 3 is
the vendor that has the number one market share in the SOHO NAT space is
very interested about making sure they work well with VoIP :-)

Cullen
Cisco/Linksys

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

---

From: Bryan Ford <[email-masked]>
Date: Sat, 7 Jun 2003 08:14:18 -0400

Cullen,

Thank you for your informative post.

> instead of symmetric. This leads to a natural tendency away from symmetric

I have one question about this issue that has come up recently.  I'd 
particularly like to get your view on this (as a knowledgable technical 
person from, presumably, the biggest vendor of corporate NATs :)), but also 
from others on this list who may have relevant information.  Unfortunately 
the question involves a little bit of "setup"; I hope you'll bear with me...

For the purpose of this message I would like to re-classify NATs into _three_ 
categories, based on how they allocate ports for translation sessions:

- "Cone NAT": usual definition - allocates a public NAT port number for a 
(private IP, private port) pair when the first outgoing session is 
established from that (private IP, private port) pair; reuses that 
public/private mapping in future sessions that may involve different external 
hosts and/por ports.

- "Wasteful Symmetric NAT": the typical kind of symmetric NAT - allocates a 
public NAT port each time a new outgoing session is initiated; each public 
NAT port remains allocated until that session terminates or times out and 
cannot be allocated concurrently to any other session during that time.

- "Frugal Symmetric NAT": assigns a new NAT port to each new outgoing session 
initiated from within the firewall... BUT... allocation is not done on a 
basis of "whole" port numbers at all but on "session identifiers", which 
include all the details of the session (private IP/port, nat IP/port, 
external IP/port). Therefore, a given public NAT port can actually be reused 
concurrently by multiple simultaneous (perhaps completely unrelated) 
sessions, as long as each session remains uniquely distinguishable on both 
sides of the NAT.

Since the behavior of a "frugal symmetric NAT" may not be obvious, here is a 
specific example of how one might work.  The NAT has two internal hash tables 
for looking up sessions from the information found in TCP or UDP packets.  
The first table is for packets originating on the internal network, and is 
indexed on (internal IP, internal port, external IP, external port) - i.e., 
the "session identifier" as seen by internal hosts.  The second is for 
packets originating on the external network, and is indexed on (NAT IP, NAT 
port, external IP, external port).  The NAT has NO port allocation table or 
bitmap of any kind, because allocations are not done at a port granularity.  
Instead, when outgoing traffic initiates a new internal session, for which no 
entry is seen in the first (internal-packet-lookup) hash table, the NAT 
simply picks a public NAT port randomly to generate a corresponding external 
session tuple (NAT IP, NAT port, external IP, external port), and checks to 
see if an entry for that tuple already exists in the external-packet-lookup 
hash table.  If not, the translation is created; if so, a new random port 
number is selected and the process is repeated until it succeeds or some 
fixed retry limit is reached.

The upshot is that while a Cone NAT utilizes its port space more efficiently 
than a Wasteful Symmetric NAT, a Frugal Symmetric NAT could in turn utilize 
its port space several orders of magnitude more efficiently than a Cone NAT.  
Instead of being limited to 2^16 sessions total (Wasteful Symmetric NAT) or 
2^16 translations (Cone NAT), a Frugal Symmetric NAT can potentially support 
2^16 active sessions _per external endpoint_ from any number of internal 
clients in any combination.  The space of concurrently active outgoing 
sessions possible for a given NAT IP address is effectively expanded from a 
16-bit space (NAT port number alone) to a 64-bit space (NAT port number, 
external IP, external port).  As far as realistic applications and protocols 
are concerned, a Frugal Symmetric NAT behaves indistinguishably from a 
Wasteful Symmetric NAT - i.e., it will work just fine for client/server 
traffic but will suck in the usual way for peer-to-peer traffic.

So with all that setup out of the way, here are my questions:

(a) Does anyone know if such a thing as a "Frugal Symmetric NAT" actually 
exists right now?  I know that most existing symmetric NATs are of the 
"Wasteful" variety, but I don't know if _all_ of them are.

(b) Do you think it's likely that corporate NAT vendors such as Cisco will 
feel increasing pressure to build Frugal Symmetric NATs in the forseeable 
future, as a result of the demand for larger NATs that can handle more and 
more simultaneous connections with fewer globally routable IP addresses?  
(I'm thinking AOL here as an example, which from what I hear runs "the 
world's largest NAT" in front of all its customers.)

(c) Or, do you think the increasing economic/political/whatever pressure to 
make NATs more peer-to-peer friendly, in order to support VoIP and networked 
games and all that, is in practice going to outweigh the pressure for "port 
frugality", ensuring that almost all NATs in the future will be 
(port-restricted) cone NATs?

(d) Finally, if there is a substantial amount of real pressure in _both_ 
directions (port frugality and P2P friendliness), do you see a possibility 
that vendors may start considering even more complex hybrid solutions, say, 
which may be able treat certain (P2P) traffic in Cone NAT fashion while 
behaving as a Frugal Symmetric NAT for other (client/server) traffic?

I realize that there are no absolutes here - I'm looking for opinions and 
industry projections.

Thanks very much,
Bryan

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 09 Jun 2003 05:16:15 -0700

What you are saying makes a lot of sense - I think your example helps
clarify things - I will try and put some answers inline as best I can. Just
to make the discussion easier, lets assume that that the NAT only has one
external IP address.  It does not really change much if it has more. I will
also gloss over the multiple protocols but again that makes no difference -
you can treat it as completely separate virtual NATs for each protocol. My
apologies to folks who point out this is PAT not NAT. End of disclaimers :-)

> person from, presumably, the biggest vendor of corporate NATs :)), but also
(really I'm a VoIP guy who plans to work for a major IPv6 vendor but I know
a guy who plays a ...)
> cannot be allocated concurrently to any other session during that time.

It's worth noting that when a packet arrives on the external port, the NAT
can figure where to send it on the inside by just looking at the port it
arrived on. The NAT still needs to keep the full session mapping to decide
if it should forward the packet at all - so the size of the state stored in
memory between this NAT and your frugal NAT is going to be similar.

> sessions, as long as each session remains uniquely distinguishable on both

Yes, this is a good idea and some NATs do this today. However, the details
are still in how they pick the NAT port. One way would be to use random
ports as you suggest below.

Another way would be to attempt to use the same external port for all
sessions that have the same internal IP and internal port. Because each
internal IP can only have 2^16 ports, the fact that the NAT has 2^16
external ports make for a nice mapping that the there will be enough ports
on the NAT for it to assign a unique external port for each session that has
a unique internal IP and internal port regardless of the number of internal
IPs.

Keep in mind this port allocation scheme still fully meets your frugal NAT
definition but now consider this from the STUN terminology point of view.
Because packets from the same internal IP/port use the same NAT port, this
is a port restricted NAT.

The terminology of "port restricted" in STUN was a little confusing because
many of the NAT people consider this still to be a form of "symmetric" - the
NAT folks mostly seem to define "symmetric" as you can only receive a packet
from public IP/port if you have sent to that IP/port on the same protocol.
Anyways, it is just a label defining a term so it's not worth worrying about
but it is worth nothing that the STUN definition of "symmetric" might not
line up exactly with some others.

> traffic but will suck in the usual way for peer-to-peer traffic.

A frugal NAT like you describe could support 2^(16+32+16) session for each
internal IP. A port restricted NAT can also do 2^(16+32+16) sessions for
each internal IP. 

> So with all that setup out of the way, here are my questions:

This has been a good example - I hope I have convinced you that it is
possible to build a NAT that is simultaneously "port restricted" in the STUN
terminology, "frugal" in this terminology and, from a security point of
view, only lets exactly the same packets pass that a "symmetric" NAT would
have let pass.

> "Wasteful" variety, but I don't know if _all_ of them are.

Yes they exist. (at least if you buy into my port restricted is a form a
Frugal NAT)

> world's largest NAT" in front of all its customers.)

I think the large NATs will feel pressure to support more than 2^16
sessions. There are some big NATs in China for instance.

> (port-restricted) cone NATs?

Well, it's not often you get win win - particularly with a NAT involved :-)
but I think in this case you can have port-restricted for P2P support and
lots of sessions at the same time.

> behaving as a Frugal Symmetric NAT for other (client/server) traffic?

I really don't know the answer to this one - NAT vendors have a long history
of doing strange and unnatural acts to packets. It's probably a good
prediction they will do all sorts of weird things for reasons ranging from
good to silly.   

> I realize that there are no absolutes here - I'm looking for opinions and

Hope that helps, Cullen

---

From: Bryan Ford <[email-masked]>
Date: Fri, 13 Jun 2003 21:54:37 -0400

Hi Cullen,

> > public/private mapping in future sessions that may involve different
> > external hosts and/or ports.
> >
> > - "Wasteful Symmetric NAT": the typical kind of symmetric NAT - allocates
> > a public NAT port each time a new outgoing session is initiated; each
> > public NAT port remains allocated until that session terminates or times
> > out and cannot be allocated concurrently to any other session during that
> > time.
>

True.

> > - "Frugal Symmetric NAT": assigns a new NAT port to each new outgoing
> > session initiated from within the firewall... BUT... allocation is not
> > done on a basis of "whole" port numbers at all but on "session
> > identifiers", which include all the details of the session (private
> > IP/port, nat IP/port, external IP/port). Therefore, a given public NAT
> > port can actually be reused concurrently by multiple simultaneous
> > (perhaps completely unrelated) sessions, as long as each session remains
> > uniquely distinguishable on both sides of the NAT.
>
> sessions that have the same internal IP and internal port.

That's just the same as "Cone NAT" as I described it above, right?  If so...

> Because each
> on the NAT for it to assign a unique external port for each session that
> has a unique internal IP and internal port regardless of the number of
> internal IPs.
[and from later in your message...]
> internal IP. A port restricted NAT can also do 2^(16+32+16) sessions for

I don't quite understand what you're saying here.  You seem to be saying that 
Cone NAT (or "port restricted NAT") is just as "frugal" with port space as 
the "Frugal Symmetric NAT" that I suggested, but I don't believe it is.  
(Though I really wish it was; then there'd be no question about what the 
"best" behavior is!)

You are correct that a [port restricted] cone NAT can do 2^(16+32+16) sessions 
for a given internal IP, _but only ignoring the effects of interference with 
other internal hosts_.  The potential for interference is much worse with 
cone NAT than with the frugal symmetric NAT that I suggested.  When the first 
session from a given (internal IP, internal port) first causes a cone NAT to 
allocate a NAT port and establish a translation, the cone NAT _MUST_ reserve 
that port exclusively for the use of that particular (internal IP, internal 
port) endpoint.  The NAT does not know what other external endpoints that 
internal endpoint will subsequently be used to communicate with in the 
future, and since the NAT has committed "a priori" to use the same NAT port 
for all sessions involving that internal endpoint, it must reserve that NAT 
port "up front" for all possible (external IP, external port) combinations.

The upshot is that while a cone NAT can indeed do 2^(16+32+16) sessions for a 
given internal IP - or 2^(32+16) sessions for a given internal endpoint 
(IP/port pair) - the cone NAT is limited to servicing at most 2^16 distinct 
internal endpoints at once (i.e., 2^16 distinct mappings from internal 
IP/port to NAT port), while the "frugal symmetric NAT" I suggested has no 
such limitation.

For a simple pathological-case example (but not a terribly unrealistic one), 
say there are a whole bunch of internal hosts iA, iB, iC, etc., behind the 
same cone NAT, and each internal host wants to communicate with a different 
external host xA, xB, xC, etc., respectively.  Even if each internal host 
only initiates communication through the firewall from a single (internal) 
port at that host, a cone NAT (or a wasteful symmetric NAT) will run out of 
ports after at most 2^16 internal hosts have initiated sessions (overlapping 
in time) to their corresponding external hosts, because all the NAT's ports 
will have been allocated by then.  The frugal symmetric NAT, in contrast, can 
re-use a single NAT port for multiple unrelated sessions from distinct 
internal endpoints - in this pathological case, for example, only a _single_ 
NAT port is theoretically needed for all of the sessions iA <-> xA, iB <-> 
xB, iC <-> xC, and so on.

Of course, if many internal hosts try to open simultaneous sessions to the 
_same_ external endpoint (e.g., port 80 at a very popular web server), even 
the frugal symmetric NAT will be limited to 2^16 simultaneous active sessions 
to _that_ particular external endpoint.  No getting around that as far as I 
can tell.  But 2^16 simultaneous sessions to a single external endpoint is 
much less limiting than 2^16 simultanous internal/external translations total 
(for cone NAT), or worse, 2^16 simultaneous _sessions_ total (for wasteful 
symmetric NAT).

> many of the NAT people consider this still to be a form of "symmetric" -
> the NAT folks mostly seem to define "symmetric" as you can only receive a
> packet from public IP/port if you have sent to that IP/port on the same
> protocol. Anyways, it is just a label defining a term so it's not worth
> worrying about but it is worth nothing that the STUN definition of
> "symmetric" might not line up exactly with some others.

I'll keep that in mind.  The way I understand it, the term "cone NAT" refers 
specifically to the NAT port allocation/mapping establishment behavior (i.e., 
re-using a single NAT port for all sessions originating at a single internal 
endpoint).  The terms "unrestricted", "restricted", and "port restricted", in 
contrast, seem to refer to the middlebox's policy on allowing "apparently 
unsolicited" incoming traffic to initiate new sessions - these terms might 
theoretically be just as applicable to non-NAT firewalls as to full-fledged 
NATs.  Though of course any remotely decent firewall will no doubt implement 
a "port restricted" policy towards incoming traffic by default.

> possible to build a NAT that is simultaneously "port restricted" in the
> STUN terminology, "frugal" in this terminology and, from a security point
> of view, only lets exactly the same packets pass that a "symmetric" NAT
> would have let pass.

I'm not convinced yet, but maybe I misunderstood your argument...?

> > (b) Do you think it's likely that corporate NAT vendors such as Cisco
> > will feel increasing pressure to build Frugal Symmetric NATs in the
> > forseeable future, as a result of the demand for larger NATs that can
> > handle more and more simultaneous connections with fewer globally
> > routable IP addresses? (I'm thinking AOL here as an example, which from
> > what I hear runs "the world's largest NAT" in front of all its
> > customers.)
>

That's exactly the kind of thing I'm wondering about.  And to me it seems 
likely that in the common case, most of the internal hosts behind these NATs 
will be web browsers - each initiating HTTP-over-TCP sessions from many 
different client-side port numbers to port 80 at many different external 
servers, rendering the "NAT port frugality" benefits of cone NAT mostly 
useless.  Cone NAT only saves NAT ports over wasteful symmetric NAT if the 
internal hosts initiate multiple sessions from the same internal IP/port pair 
(which the cone NAT aggregates onto a single internal/external translation), 
and that is unlikely to happen much when the internal hosts are ordinary TCP 
clients initiating outgoing sessions via connect() without an explicit 
bind(), and letting the OS assign a new client-side port number to each one.  
Either a wasteful symmetric NAT _or_ a cone NAT will run out of steam at 
around 2^16 total simultaneous internal clients at best, and probably a lot 
less because each client will often be opening sessions from several 
different internal ports to several different external servers in relatively 
quick succession, during the course of ordinary web surfing.  Only a true 
"frugal symmetric NAT", which can re-use a single NAT port for multiple 
simultaneous unrelated sessions from _different_ internal endpoints, will 
really be able to get around this problem and handle more than 2^16 distinct 
internal clients simultaneously.

Anyway, let me know if I misunderstood your argument.  Thanks again for your 
response, and I look forward to hearing from you again.

Cheers,
Bryan

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Jun 2003 23:11:18 -0700

Sorry for the short answer here but I think we are thinking different things
on port restricted and cone.

When traffic arrives on port 5000 on the outside of the NAT there are two
things that can happen - On a cone, it always gets sent to the same host on
the inside and there is only one mapping for this port. On a restricted
there is a separate mapping for every possible location it can arrive from
and depending on where it came from, it can get sent to different hosts on
the inside of the NAT.

The argument I was making does not work with a cone NAT - it requires that a
separate mapping per destination address/port is kept in the NAT.

Hope that helps clarify, Cullen

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 17 Jun 2003 19:27:51 +0200

>> employed. This makes STUN useless.

Also, you may wish to learn that STUN is very useful to detect symmetric NAT.
If a phone knows there is such a device in path, it can switch over to
active symmetric mode (comedia) to get over it.

-Jiri