Re: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

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

--- Bryan Ford <[email protected]> wrote:
> On Friday 13 February 2004 08:48 am, Jiri Kuthan wrote:
> > 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).
> 
> 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
> 
> 
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom


=====