Subject: [midcom] (no subject)

From: Jiri Kuthan <[email-masked]>
Date: Thu, 12 Feb 2004 18:17:31 +0100

At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote:
>This is a great piece of work. Thanks to Cullen for putting this together.

Cullen,

thanks, that's indeed a very helpful piece of information. In particular
the observation that modern NATs are rarely symmetric makes me feel better.
(The current situation is AFAIK roughly up to 20% of user population is 
behind symmetric NATs.)

Can you send me STUN traces (PCAP at best) for some of the non-deterministic 
NATs? Particularly according to some tests we did long time ago, Linksys WRT54G
was symmetric all the time. Unfortunately, I no longer have one around to retest
and I did not record firmware version either.

-jiri 

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

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 13 Feb 2004 13:08:10 +0100

>and I did not record firmware version either.

WRT to this particular case, linksys web tells me the box is Linux based
(http://www.linksys.com/support/gpl.asp) in which case chances are high
the box is symmetric all the times. I agree it would be good to verify your
list -- what a pity we just missed an opportunity at sipit.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 13 Feb 2004 14:48:13 +0100

At 08:57 PM 2/10/2004, Jonathan Rosenberg wrote:
>One conclusion I draw from this is that, as STUN itself predicts, the NAT classification algorithm is brittle because it makes assumptions about the types of NATs and there behaviors. We are now seeing NATs that have this dual behavior, depending on whether the internal port is allocated or not, and STUN's detection algorithm does not take this into account. Indeed, I would be inclined to work on reivising STUN, and in such a revision, remove the detection algorithm and explain why that was done. What do people think of that?

I think there is still some value in the NAT-type tests even with 
use of ICE. Positive assertions about traversable NATs may be brittle, 
I agree. Negative assertions about hard-to-traverse NATs are quite 
safe and can eliminiate unnecessary tries. Particularly, if you know 
you are behind a symmetric NAT you can safely eliminate STUN address 
from your offer. 

>To me, this also further strengthens the arguments behind something like ICE (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt), which uses STUN, but does *not* use the detection algorithm. Rather, it relies on dynamic connectivity checks to figure out whether an address works or not. The argument there is that, ultimately, the only way to know whether you can receive media sent from address A to interface X is if you can receive a packet from address A sent to interface X. Any other way of verifying this conclusion is based on assumptions that can be wrong.

Whereas I am quite comfortable with ICE and enjoy its e2e robustness, 
I think there is still some other, parallel, undone work. The left option 
of using a media relay indicates to me that there is an architectural 
imperfection and I see it in silly NATs (silly is an aggregate word standing 
for undeterministic or symmetric or bad or whatsoever). It seems very
desirable to me to abandon such devices and I think it is a quite realistic
goal. Cullen's draft actually strengthens my hope that it is happening.

A way the IETF can help is to collect recommendations for NATs. There was 
such an effort long time ago 
(http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt),
I maintain a very similar list as well (don't be silly, keep NAT bindings for
a while, allow  hairpinning, try to preserve port numbers, try to use stateless 
binding allocation algorithms). 

-jiri

---

From: Bryan Ford <[email-masked]>
Date: Fri, 13 Feb 2004 10:01:28 -0500

On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote:
> (http://www.iptel.org/ietf/firewall/nat/draft-ietf-mmusic-natreq4udp-00.txt
>), I maintain a very similar list as well (don't be silly, keep NAT bindings
> for a while, allow  hairpinning, try to preserve port numbers, try to use
> stateless binding allocation algorithms).

FYI, Pyda Srisuresh, Dan Kegel and I have for a while been working on a 
document whose sole purpose is to collect precisely these things - general 
recommendations for NATs, and general (protocol-independent) recommendations 
for applications trying to traverse NATs.  It's already gone through a few 
versions; the latest one recently came back from first review by the IESG, 
and we're hoping to have another, near-final update before long.  The most 
recent version is available here:

	http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

Please let me know if you find inaccuracies or have other comments/additions.  
Thanks!

Bryan

---

From: "Justin Uberti" <[email-masked]>
Date: Fri, 13 Feb 2004 10:19:45 -0500

Here at AOL we have found that the WRT54G is port-restricted cone in its 
normal mode, which is what is documented by Cullen. Our other test 
results are also mostly consistent with the document, with the exception 
of some Linksys models, where the difference may be explained by 
different firmware versions. We were not able to find any symmetric NATs 
in our admittedly small sample.

Cisco PIIX       Port
DLink DI-704P    Cone
Linksys BEFSR41  Addr
Linksys BEFSX41  Addr
Linksys BEFW11S4 Port
Linksys WRT54G   Port
Netgear RP614    Cone
Netgear WGR614   Cone

FWIW, we have found that some Linksys routers will rewrite the IP 
address in the STUN reply to be the nonroutable (e.g. 192.168.x.x) 
address rather than the NAT address, causing the STUN detection to 
classify the connectivity as "Open". For our STUN-like protocol we have 
the server XOR the IP address prior to returning it to prevent such 
rewriting.

Also, we have observed from our customers this approximate breakdown in 
market share: (obviously heavily skewed toward a US population)
Linksys     59%
Netgear     14%
DLink       13%
Belkin       5%
Microsoft    3%
SMC          2%
Siemens      2%
Zyxel        1%
ActionTec    1%
3Com        <1%
Comcast     <1%
Dell        <1%

--justin

---

From: Bryan Ford <[email-masked]>
Date: Fri, 13 Feb 2004 10:41:59 -0500

> market share: (obviously heavily skewed toward a US population)

That's very useful info - thanks very much for posting it!

Out of curiosity, does anyone have any similar info about the types of 
"big-iron" NAT boxes are most commonly deployed at the ISP or corporate 
network level rather than at the consumer level?  I assume this area is 
Cisco-dominated, but to what degree, and who are the other significant 
players, if any?  The reason I ask is because it is at this level that not 
only [[port-]restricted] cone NAT becomes important, but also hairpin aka 
loopback translation support becomes critical, if users behind the same 
top-level NAT but separate second-level (consumer) NATs are to be able to 
talk to each other.

Justin, you folks at AOL deploy a lot of such boxes, don't you?  Do you 
know/can you divulge what type they are and what their NAT behavior is?

Thanks,
Bryan

---

From: "Justin Uberti" <[email-masked]>
Date: Fri, 13 Feb 2004 13:18:47 -0500

We use Cisco PIIX for our corporate network. For our ISP customers, we 
supply fully routable addresses, i.e. we do not NAT them.

I am curious to find out from our stats how many of our customers who 
use our software but not our ISP are NATed by their own ISP. Right now 
we have to go through a lot of craziness to deal with the case you 
mention where two customers are behind the same top-level NAT but 
separate residential NATs. Does ICE address this particular case?

--justin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Feb 2004 13:25:14 -0500

> separate residential NATs. Does ICE address this particular case?

Yes. It will dynamically detect the condition and the following will occur:

If the top-level NAT supports hairpin, ICE will end up using a STUn 
discovered address outside of the top-level NAT, i.e., it would take 
advantage of the hairpin support.

If the top-level NAT doesnt support hairpin, AND there was a stun server 
between the residential and to-most NAT, and the clients were configured 
to use such a stun server, those addresses would be used. Note that in 
this case, the stun server doesnt need to be a big, publically available 
server; any user of the same ISP that doesnt own a residential nat could 
run a stun server, and that could be used.

If the top level NAT doesnt support hairpin, and there is no other stun 
server besides the one outside of the outermost nat, then the turn 
server outside the outermost nat would be used.

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

---

From: "Justin Uberti" <[email-masked]>
Date: Fri, 13 Feb 2004 13:34:04 -0500

> run a stun server, and that could be used.
q1: How would the existence of said STUN server be made known to the 
calling client?

q2: We currently use UPnP to address this particular situation, i.e. if 
we know that we are behind 2 NATs and the person we want to call is 
behind the same topmost NAT, we get the WAN address of our first-level 
NAT box using UPnP and give that to the callee. Is UPnP, or any other 
protocol for querying the WAN address of the NAT box, used in ICE?

Thanks,
--justin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Feb 2004 13:36:57 -0500

> in our admittedly small sample.

Thanks for the additional data. I think it would be really valuable to 
run the same tests Cullen has run against these, and include the results 
in the document.

> classify the connectivity as "Open".

Sigh... Cullen reports in his document that he did not see this 
behavior. Its one of my regrets in stun - that we did not properly 
encrypt the address to avoid rewriting by nat. If we were to do a 
revision of stun, I would like to address this also.

> For our STUN-like protocol we have 

This is valuable data, thanks.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Feb 2004 13:41:28 -0500

> q1: How would the existence of said STUN server be made known to the 

Configuration of some sort. There is no magic that I know of to 
automatically discover these.

> behind the same topmost NAT,

How do you know this reliably?

> we get the WAN address of our first-level 

UPnp can be used with ICE, yes. ICE's philosophy is, "the more the 
merrier" in terms of addresses. The only requirement is that there is 
always at least one guaranteed-to-work address, generally obtained 
through turn. Beyond that, a client can obtain addresses from stun, 
turn, upnp, midcom, rsip, etc., and ice will dynamically figure out the 
one that is best to use.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Feb 2004 13:46:02 -0500

Jiri Kuthan wrote:

>> One conclusion I draw from this is that, as STUN itself predicts,
>> the NAT classification algorithm is brittle because it makes
>> assumptions about the types of NATs and there behaviors. We are now
>> seeing NATs that have this dual behavior, depending on whether the
>> internal port is allocated or not, and STUN's detection algorithm
>> does not take this into account. Indeed, I would be inclined to
>> work on reivising STUN, and in such a revision, remove the
>> detection algorithm and explain why that was done. What do people
>> think of that?
> 
> 
> I think there is still some value in the NAT-type tests even with use
> of ICE. Positive assertions about traversable NATs may be brittle, I
> agree. Negative assertions about hard-to-traverse NATs are quite safe
> and can eliminiate unnecessary tries. Particularly, if you know you
> are behind a symmetric NAT you can safely eliminate STUN address from
> your offer.

I disgaree.

Cullen's results show that we are seeing hybrid NATs whose type depends 
on whether the random port selected by the client is allocated already 
or not. In such a case, if the client picks an already-allocated port 
during the detection phase, it may detect the nat as symmetric, when it 
fact it might be port restricted in other cases.

With ICE, if you happen to be unlucky during a stun allocation, turn 
would get used. If you're lucky, and you get a port-restricted port, 
then the relay would not be used.

> 
> 
> 
>> To me, this also further strengthens the arguments behind something
>> like ICE
>> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-00.txt),
>> which uses STUN, but does *not* use the detection algorithm.
>> Rather, it relies on dynamic connectivity checks to figure out
>> whether an address works or not. The argument there is that,
>> ultimately, the only way to know whether you can receive media sent
>> from address A to interface X is if you can receive a packet from
>> address A sent to interface X. Any other way of verifying this
>> conclusion is based on assumptions that can be wrong.
> 
> 
>  I think there is still some other, parallel, undone work. The left
> option of using a media relay indicates to me that there is an
> architectural imperfection and I see it in silly NATs (silly is an
> aggregate word standing for undeterministic or symmetric or bad or
> whatsoever).

Yes, it would be nice to obliterate such devices. With ICE, once 
obliterated, the relay would simply cease seeing any traffic, and you 
know at that time that you can disconnect it safely. As such, ICE 
provides a nice way to transition from here to there.

  It seems very desirable to me to abandon such devices
> and I think it is a quite realistic goal. Cullen's draft actually
> strengthens my hope that it is happening.
> 
> A way the IETF can help is to collect recommendations for NATs. There
> was such an effort long time ago 
>  I maintain a very similar list as well (don't be silly, keep NAT
> bindings for a while, allow  hairpinning, try to preserve port
> numbers, try to use stateless binding allocation algorithms).

I agree work needs to be done here.

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 14 Feb 2004 16:37:49 +0100

At 07:36 PM 2/13/2004, Jonathan Rosenberg wrote:
>Thanks for the additional data. I think it would be really valuable to run the same tests Cullen has run against these, and include the results in the document.

Absolutely. I think we should collect PCAP files for verification purposes though.
I'll be happy to do the collector job if people send them to me. A first try
is at http://iptel.org/stun_test. 

-jiri 

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 14 Feb 2004 16:13:46 +0100

[...]
At 04:01 PM 2/13/2004, Bryan Ford wrote:
> (don't be silly, keep NAT bindings

I don't think any item on my shopping list above introduces anything
new in addition to your Section 5. 

I just don't understand if there is not an overlap between your section
5.1 which mandates cone NATs and 5.3 which mandates preserving the
same translation packets with the same source address and port number.
Isn't that the same thing?

I'm not sure I like the dual-NAT-type behaviour suggested in 5.2. At least
I would have to understand how the application configuration process in
NAT would work (My midcom bias is that application awareness in
NATs is better avoided.)

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 14 Feb 2004 16:46:21 +0100

At 04:19 PM 2/13/2004, Justin Uberti wrote:
>normal mode, which is what is documented by Cullen. 

Interesting, I guess the WRT54G may have some patches -- I just retried
iptel's STUN against a Linux 2.4.21 box and the test result is symmetric.
(PCAP available for verification at http://iptel.org/stun_test)

>Our other test 

That's good news anyhow and thank you for this information.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 14 Feb 2004 17:09:28 +0100

At 07:46 PM 2/13/2004, Jonathan Rosenberg wrote:
>I disgaree.
>
>Cullen's results show that we are seeing hybrid NATs whose type depends on whether the random port selected by the client is allocated already or not. In such a case, if the client picks an already-allocated port during the detection phase, it may detect the nat as symmetric, when it fact it might be port restricted in other cases.
>
>With ICE, if you happen to be unlucky during a stun allocation, turn would get used. If you're lucky, and you get a port-restricted port, then the relay would not be used.

So here is a case which makes me puzzled and possibly needs some
extra work: SIP client behind a restrictive NAT. With STUN assumptions
it will work (as long as they hold, of course),the client will send 
a "primer" packet to UAS and UAS media will come in.

With ICE, a UAS will first check connectivity to UAC's STUN address.
The ICE draft suggests doing so on the initial application request
(SIP INVITE e.g.) to keep call set up time low. At this moment however, 
UAC's NAT is not primed yet and the STUN check reports no connectivity.

-jiri

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 15 Feb 2004 16:56:00 -0800 (PST)

Cullen,

Interesting compilation of results. Thank you. A few comments below.

1. Primary & Secondary columns in the draft being different - This strikes me
as wierd. Would appreciate if you can shed some light on the test used to
categorize it thus. If the tests did indeed correctly categrorize a box as
being different between primary & secondary port users - Does someone have a
clue as to why a vendor might have chosen to do this intentionally? (or) is it
likely a unintended bug in the product?

Take the case of a Primary being port-restricted and secondary being symmetric
- Is the primary truely tested for port-restricted NAT criteria with multiple
outgoing and incoming sessions? I..e, Did the same primary-port end-point
initiate multiple outgoing connections; And, even as some of the outgoing
connections have aged out, the permitted incoming connections are restricted to
only those coming from the (ExtAddr, ExtPort) tuples to which there were
outgoing sessions previously? Likewise, Was a secondary port user unable to
initiate multiple outgoing sessions using the same port bind? 

In case, the test was performed using a single session on primary port user, I
believe, the box may as well have been a "Symmetric NAT" all across (primary as
well as secondary port users).

Likewise, take the case of primary being port-restricted and secondary being
full-cone. Depending upon how the test was performed, this may very well have
been "Full cone" for both primary and secondary port users.

2. Group-D/BAD port-binding sounds buggy to me. Why would a vendor choose to do
this intentionally? I.e., hope this is the right thing to do most of the time?

3. Port Restricted Cone NATs & Address restricted Cone NATs

Below is my understanding of the operational behavior of restricted Cone NATs.
Essentially, I believe, both restricted Cone NATs are variations of Full-Cone
NAT, with additional firewall restrictions on the permitted incoming
connections.

I believe, the reverse of the outgoing NAT sessions are retained as firewall
packet rules to restrict what is allowed for incoming sessions. The restriction
may be one of (External address) or (External address, external port) depending
upon whether the device is Address restricted or Port restricted.

Now, the questions on their operational behavior.

Are the restrictions valid only so long as the port-BIND is active? I.e., even
as an outgoign NAT session ages out with idle time, the restricted Cone-NATs
will preserve the firewall rules in the reverse direction, so long as the
port-BIND is alive, Right? Once the port-BIND is aged out, the associated
firewall rules will disappear, right?
 
4. Several enterrises use SonicWall as their NAT/firewall. Any insight on this
from folks out there?

5. Lastly, I agree with the recommendations on the draft - Group-A type of
NATs, which are Full-Cone NATs, and support hair-pin connectivity, with or
without port-preservation. FWIW, the draft below (draft-ford-midcom-p2p-01.txt)
also recommends the same as being P2P friendly.

regards,
suresh

> Please let me know if you find inaccuracies or have other comments/additions.

=====

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 16 Feb 2004 20:00:42 +0100

At 01:56 AM 2/16/2004, Pyda Srisuresh wrote:
>as wierd. 

I'm surprised by that too -- that's why I would like to see the STUN PCAPs.

>without port-preservation. 

S od I.

-jiri

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Feb 2004 16:12:33 -0800

On Feb 13, 2004, at 10:46 AM, Jonathan Rosenberg wrote:
> Cullen's results show that we are seeing hybrid NATs whose type  
> depends on whether the random port selected by the client is allocated  
> already or not. In such a case, if the client picks an  
> already-allocated port during the detection phase, it may detect the  
> nat as symmetric, when it fact it might be port restricted in other  
> cases.
>

I find this situation sufficiently unlikely that I would prefer to  
"just use TURN" when i detect a symmetric NAT for code-path simplicity  
and lower call setup delay.

thx,
-rohan

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 21 Feb 2004 17:34:28 -0800

> revision of stun, I would like to address this also.

If you can get me the version of the Linksys that did this - that would help
me. Others have reported this too, I'm sure it happens, I just can't find a
version that does it. There was a SIP ALG on the linksys stuff but that now
defaults to off. 

I have some traces that show this happening on an older Speedstream ss2604
too so if someone has one of these and would be willing to send it to me,
I'll swap you some other Linksys with a wireless access point.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 21 Feb 2004 18:25:18 -0800

Whole bunch inline - thanks for the comments

> likely a unintended bug in the product?

I tracked down one programmer who was the guy who implemented this in one
product with this same question. It was unintentional.

It was intentional to try to preserve the port, it's more likely to make
things work and keeps port numbers the same for network snifters. I'm not
sure I fully buy the argument that you try and preserver ports but I at
least can see the argument.  Clearly you can't always use the same port
(well ignoring group D for now :-). This one set of code ended up with two
different logic flow depending on if the port was already in use or not.
Since the implementer was unaware that symmetric vs. port restricted might
make a difference at the time the code was written, they did not worry that
the behavior was different. Actually it was somewhat a surprise to the
implementer that the behavior was different.

I suspect that in all the cases where the behavior changed, it was not an
intention feature of the product but just an artifact of how the code ended
up. 

> well as secondary port users).

The test was done by using a client that two IP addresses ( call the address
A and B) on a single NIC. First stun was run from address A, and a fixed
port (9000) was used as the port that the client sent the stun tests from.
This takes a second or so. Right after that, the STUN tests are run from
port 9000 on IP address B.

On NATs that try to preserve ports, the first packet from A:9000 gets port
9000 on the public side of the NAT. When the packet comes from B, it wants
to use 9000 but that port is already in use by A so it allocates some other
port.

I believe you would get the same results if you had run two STUN tests at
the same time from two different clients running on two different PC's
behind the same NAT and both STUN clients sending their packets from the
same port number. 

The bad news about this test is that there is no way to know what type of
NAT you are behind if all you have is a single IP address.

> this intentionally? I.e., hope this is the right thing to do most of the time?

Uh, yah, I would think of this is a bug too. Some people of course would
describe all NAT's as a serious bug in an IP router. I was goofing around
with running applications from two PC's at the same time that were behind
these NATs. Ironically, the robustness of the retransmission mechanism I the
the IP protocols caused these to work better than I thought they would. One
PC would get the response it wanted, plus some garbage meant for the other
PC, then the other PC would retransmit and cause some result to be resent
that was meant for it. The robustness for the packet retransmission schemes
caused stuff to work.  I don't mean to encourage anyone to use this approach
- I think it is a bad approach - it did not work well - it just worked
better than I thought it would.

> upon whether the device is Address restricted or Port restricted.

Yes

> firewall rules will disappear, right?

Sounds like a good guess - I did not the aging and timing stuff. Most things
seemed over 30 seconds and less than or equal to 7200 seconds. I'd like to
do more experiments to learn a bit more about what types of things reset the
timers (outgoing packets, incoming, either, etc)

> 4. Several enterrises use SonicWall as their NAT/firewall. Any insight on this

I'm going to get around to testing some of the enterprise stuff some time. I
seem to recall one of the p2p authors had a more than casual understanding
of things like SonicWall. Any tests you recommend that we should look at
with enterprise systems? I want to tests that will detect anything that is
going to give me a nasty surprise when I try to deploy RTP over it.

> also recommends the same as being P2P friendly.

Cool - I've been meaning to find the time to properly understand and sync up
with you, Bryan, and Dan on the p2p draft. I've just been running out of
time but I like what it is trying to accomplish.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 21 Feb 2004 14:39:14 -0800

> Dell        <1%

That is great information to help deal with deciding what to do. Thank you
very much for providing it. If anyone could provide similar information that
would be great.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 21 Feb 2004 14:13:12 -0800

> list -- what a pity we just missed an opportunity at sipit.

Definitely agree it would be good to verify all of this. It's really easy to
make a mistake.

I put the pcap from both the client and the server for this NAT at

http://www.employees.org/~fluffy/ietf/wrt54g_client2.pcap
http://www.employees.org/~fluffy/ietf/wrt54g_server2.pcap

"public" ip of nat was 10.0.1.4

IP of stun server was 10.0.1.150 and 151

Client was at 192.168.1.100

Model linksys WRT54G
Firmware 1.42.2

Firewall protection was at default (enable) and Block Anonymous Internet
Requests was checked (default)

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 24 Feb 2004 07:55:19 -0800 (PST)

Cullen,

Thank you for the response. Please see my comments inline.

regards,
suresh

> intention feature of the product but just an artifact of how the code ended

Interesting. Thank you for sharing the insight. I suspect, it may be similarly
the case with others as well.

> > connections have aged out, the permitted incoming connections are
> restricted
> > to
> > believe, the box may as well have been a "Symmetric NAT" all across
> (primary
> > as

I still believe, there might be an error in test characterization. A
port-restricted cone-NAT is a symmetric NAT, when there is a single outgoing
session initiated from the client. Unless there are a minimum of two outgoing
sessions from the same (A, 9000) to two different (STUN-server address, port)
pair and both outgoing sessions use the same Port-translation, a NAT device
shouldnt be characterized as "port-restricted cone-NAT".

Interestignly, all rows characterized as primary to be port-restricted and
secondary to be symmetric, also have the port preservation enabled (wherever
port preservation column is filled). Dont know what to make of this. Could that
somehow have also contributed to incorrect characterization?

> behind the same NAT and both STUN clients sending their packets from the

Agreed.

> > 2. Group-D/BAD port-binding sounds buggy to me. Why would a vendor choose
> to
> > do

The problem is RFC 3489 definitions for NAPT varieties does not talk about the
relation of NAT-sessions, and port bindings to Max-idletime. Below is another
way NAPT variations could have been implemented without the aid of firewall.

A Port-restricted Cone NAT could have been implemented with multiple
NAT-sessions using the same port-bind (true NAPT implementation). An
address-restricted Cone NAT could have been implemented same as above, except
that the UDP NAT-sessions use ANY match on dest-port. A full cone NAT could
also have been implemented with UDP NAT-sessions using ANY match on
dest-address and ANY match on dest_port (or) simply making the port-BIND
unidirectional and aging out the port-bind based on max-idletime. Unlike the
above, a symmetric NAT does not maintain port bindings and each NAT-session
goes through different port translation.

> time but I like what it is trying to accomplish.

Thanks.

regards,
suresh

=====

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 26 Feb 2004 16:22:10 -0800

> likely a unintended bug in the product?

who knows the motivation?  I suspect its a bug.

> initiate multiple outgoing connections;

yes and yes.  the test client has two IP addresses from which it 
initiates several requests in some cases with the same source port.

> And, even as some of the outgoing
> restricted to
> (primary as

Exactly!

thanks,
-rohan