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

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. 

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

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

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

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