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

From: [email-masked]
Date: Thu, 4 Sep 2003 00:12:39 -0700

Comments/queries inlined (previous inserts kept for context):

> > * - 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.
> 
> Normally one would be received.
 
I would have thought this would have been the case too, however while testing against some well known publically available STUN servers connections were refused to the CHANGED-ADDRESS details.

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

This isn't a far fetched scenario, it could be quite conceivable that an enterprise could well leave the well known port for STUN (3478) open to traffic for the purpose of figuring out the NAT'd IP address from a bind response in test 1, but because the CHANGED-ADDRESS port number is arbitrary it effectively requires all outbound UDP traffic to not be restricted.  Some paranoid network admins don't allow such configurations. 

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

It's not that it's skipped as such, it's just that if the logic is followed through to the letter and no response is obtained from the 2nd Test 1, to make a decision of whether or not the IP address was local or not wouldn't be valid.  I think this greyness could be interpreted different ways by different people and it's this kind of point that the specification should resolve definitively (ie. state that this should be an error, or that Test 3 should be executed) so that everyone is reading off of the same song sheet.  Not doing so could lead to different vendors of STUN clients interpreting results differently and this would be detrimental to the purpose of STUN in the first place.  Clear resolution as to what happens should be catered in the RFC to cover a likelyhood like this, belief that things "should" work isn't in experience good enough in real life situations.

Thanks for your response Jonathan, it was much appreciated.

Les

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 04 Sep 2003 19:45:47 -0700

On 9/4/03 12:12 AM, "[email-masked]" <
> 
> I would have thought this would have been the case too, however while testing
> against some well known publically available STUN servers connections were
> refused to the CHANGED-ADDRESS details.
>

Some of the early STUN implementation ran across two servers - operational
experience showed this was a bad mistake and I have mentioned it before on
the list.

The two addresses need to be fate shared or STUN can give the wrong result.
I highly recommend all implementers run with two IP address on the same NIC
card on the same Ethernet cable. That way if the cable gets pulled or
something else happens, hopefully neither will be reachable.

The server at stun.vovida.org is in an embarrassing state of disarray and I
apologize for the poor operation of it - it's been on my todo list to fix.

Cullen

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