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

From: "Yutaka Takeda" <[email-masked]>
Date: Mon, 8 Sep 2003 19:28:19 -0700

I have experienced the same situation with a router, not receiving a
response in the second Test 1. I treated it as "UDP BLOCKED",
however, the situation is a little worse than that.

The router we have tested with STUN has a firewall integrated. The
router does not forward responses at the second Test 1 from a STUN
server to a STUN client though the client has sent to a packet to a
transport address from which the responses are sent.

The reason I found later on was that in Test 2 before the second Test 1 
the firewall that received multiple packets from unknown address 
treated the packets as an attack and dropped all the subsequent 
packets from the same address. This is why the response in the 
second Test1 did not arrive. To make matters worse, any packets
from the address are ignored, and in order to reset this blockage
with the router, I had to ask a network admin to do so... (manual
reset)

I would like to come up with a solution to this, however, so far I have
nothing but just treating this case as being resulted in 
"UDP BLOCKED".

Any opinions or suggestions to this will be appreciated. 
Yutaka

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 04, 2003 12:13 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [midcom] STUN - NAT Discovery gap in logic?
> 
> 
> 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
> 
> 

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Sep 2003 23:15:01 -0700

You might want to put a little bit of time (like 10 ms) between sending each
of your packets. This tends to prevent the problem of the NAT thinking it is
under a DOS attack.