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

Cullen,

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

regards,
suresh

--- Cullen Jennings <[email protected]> wrote:
> 
> Whole bunch inline - thanks for the comments
> 
> On 2/15/04 4:56 PM, "Pyda Srisuresh" <[email protected]> wrote:
> 
> > 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?
> 
> 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. 
> 

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

> > 
> > 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).
> 
> 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 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?

> 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.

Agreed.

> 
> 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.
> 
> > 
> > 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?
> > 
> 
> 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.
> 
> > 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.
> 
> Yes
> 
> > 
> > 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?
> 
> 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)
> 

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.

> > 
> > 4. Several enterrises use SonicWall as their NAT/firewall. Any insight on
> this
> > from folks out there?
> 
> 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.
> 
> > 
> > 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.
> > 
> 
> 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.
> 

Thanks.

> > regards,
> > suresh
> > 

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
> > 
> > 
> > =====
> > 
> > 
> > _______________________________________________
> > midcom mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/midcom
> > 
> 


=====