Subject: [midcom] STUN - NAT Discovery gap in logic?

From: [email-masked]
Date: Wed, 3 Sep 2003 19:16:52 -0700

In Figure 2 of the STUN RFC 3489, I've got a question as to a possible outcome which may indicate a gap in the logic.  The scenario is as follows:

  * - The first time Test 1 is executed (request sent to a1:p1) a valid response is returned, but the IP address is not the same.

  * - Test 2 (request sent to a1:p1) no response is obtained

  * - Here's the issue I feel. Test 1 is executed again (request sent to a2:p2) but does not get a response.  The diagram and text that precedes it does not explain what should happen if no response is obtained.

No response from the execution of Test 1 a second time to a2:p2 may fail for a number of reasons (misconfiguration of the server, firewall open for outbound STUN requests but no other ports, etc.), and I don't think it's a safe assumption that a response will be receieved.

Given this situation what should be deduced from the NAT discovery process?  I've noticed that some existing clients ignore the execution of Test 1 a second time and moves right through to Test 3.  Should another NAT status or error be returned instead?

Comments?

L

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Sep 2003 02:13:13 -0400

inline.

[email-masked] wrote:

> In Figure 2 of the STUN RFC 3489, I've got a question as to a
> possible outcome which may indicate a gap in the logic.  The
> scenario is as follows:
> 
> * - The first time Test 1 is executed (request sent to a1:p1) a
> valid response is returned, but the IP address is not the same.
> 
> * - Here's the issue I feel. Test 1 is executed again (request sent
> to a2:p2) but does not get a response.  The diagram and text that
> precedes it does not explain what should happen if no response is
> obtained.

Normally one would be received.

> 
> No response from the execution of Test 1 a second time to a2:p2 may
> fail for a number of reasons (misconfiguration of the server,
> firewall open for outbound STUN requests but no other ports, etc.),
> and I don't think it's a safe assumption that a response will be
> receieved.

As you say, its hard to deduce a specific problem from a lack of a 
response. I will say that STUN is not meant to deduce firewall 
policies, but rather nat policies. If you have a firewall that blocks 
all ports but stun, this will not be detected, as it was not designed 
for that. I don't know why you would have such a configuration though, 
as it would defeat the purpose of anything stun would be used for.

> 
> Given this situation what should be deduced from the NAT discovery
> process?  I've noticed that some existing clients ignore the
> execution of Test 1 a second time and moves right through to Test
> 3.  Should another NAT status or error be returned instead?

The execution of test 1 a second time is needed to differentiate 
between symmetric and port restricted, so I dont know why it would be 
skipped.

I feel I should make a higher level point though. We recognized when 
writing STUN that the nat type detection algorithm, being a "black box 
test", could never be definitive, and there are a lot of assumptions 
that go into the test - principally, the characterization of nat 
behaviors. These are all discussed in the IAB considerations section, 
which is worth reading.

A better approach, rather than to try to detect the type of nat you 
are behind, is to bilaterally test for connectivity with your peer 
using STUN. THis concept, called ICE, is discussed in detail in:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt

WHen a client uses ICE, it no longer needs to perform the nat type 
check described in Section 10.1 of STUN.

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

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