Subject: [midcom] wierd behavior of restricted-cone nat

From: "Yutaka Takeda" <[email-masked]>
Date: Tue, 19 Aug 2003 15:43:57 -0700

As I was going through a test with STUN, I have been experiencing some
weired problems. I have so far noticed that some NATs which are I thought
restricted-cone NATs, sometimes act like a symmetric NAT. I thought
this is a kind of exceptional behavior which we can ingnore in most cases,
however, after reading a discussion between Bryan and Cullen a while ago
about "Frugal Symmetric NAT and port restricted-cone NAT", I started to 
wonder if this is a common and significant issue in a use of STUN or other
form of NAT discovery processes (i.e. Teredo).

If Cullen's information is true (well more than likely), the "port re-use"
process in a restricted-cone NAT could be a problem for an application
using STUN.

http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg03217.html

Here is the case I am concerned about:

There are two internal hosts (I1 and I2) behind a port restricted-cone 
NAT, and each one bound a local transport address as I1a:I1p and I2a:I2p 
respectively.(XXa is an IP address, XXp is a port) 
I1 sends a packet to an external host E1 listening at E1a:E1b. This 
causes a binding in the NAT and it allocates a MAPPED-ADDRESS (M1a:M1p).

Then, I2 sends a packet to a different external hosts (E2a:E2b). This 
time, the NAT can re-use the same MAPPED-ADDRESS (M1a:M1p) that is 
previoulsy allocated since packets sent from E1 or E2 will be correctly
routed back to I1 or I2. However, If I2 needs to send a packet to E1 
while the NAT binding (M1a:M1p-E1a:E1p) is still present, I presume
the NAT will allocate another MAPPED-ADDRESS (M2a:M2p). Say, E2 is
STUN server and E1 is a final destination transport address for I2,
the acquired MAPPED-ADDRESS (M1a:M1p) with STUN will not be useful to
talk to E1.

I1a:I1p --->(M1a:M1p)-------->E1a:E1p
              |   |      /
I2a:I2p ----- +   +-----|---->E2a:E2p
              |         |
            (M2a:M2p)---+

I am still not confident on a relevance between what I am experiencing 
and the above mentioned yet, and having hard time to reproduce this 
situation. I guess the NAT has a specific condition for starting 
re-using ports on the NAT which makes the reproduction difficult. 
Has anyone already identified this situation?

Any comments or thoughts on this will be appreciated.
Best regards,
Yutaka

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Monday, June 09, 2003 5:16 AM
> To: Bryan Ford; Midcom
> Subject: Re: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg
> 
> 
> 
> 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 :-)
> 
> 
> On 6/7/03 5:14 AM, "Bryan Ford" <[email-masked]> wrote:
> 
> > Cullen,
> > 
> > Thank you for your informative post.
> > 
> >> 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.
> > 
> > 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
> (really I'm a VoIP guy who plans to work for a major IPv6 
> vendor but I know
> a guy who plays a ...)
> > 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.
> 
> 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.
> 
> > 
> > - "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.
> > 
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > (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.
> > 
> 
> Yes they exist. (at least if you buy into my port restricted 
> is a form a
> Frugal NAT)
> 
> > (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.)
> 
> I think the large NATs will feel pressure to support more than 2^16
> sessions. There are some big NATs in China for instance.
> 
> > 
> > (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?
> > 
> 
> 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.
> 
> > (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 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
> > industry projections.
> > 
> > Thanks very much,
> > Bryan
> >
> 
> Hope that helps, Cullen 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

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