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

From: [email-masked]
Date: Mon, 8 Sep 2003 20:12:23 -0700

You hit the exact problem I was describing Yutaka with the words "I treated it as".  Someone else could intepret the situation differently, for example as an erroneous state.

I propose that the logic for NAT discovery be altered so that it shows:

                        +--------+
                        |  Test  |
                        |   I    |
                        +--------+
                             |
                             |
                             V
                            /\              /\
                         N /  \ Y          /  \ Y             +--------+
          UDP     <-------/Resp\--------->/ IP \------------->|  Test  |
          Blocked         \ ?  /          \Same/              |   II   |
                           \  /            \? /               +--------+
                            \/              \/                    |
                                             | N                  |
                                             |                    V
                                             V                    /\
                                         +--------+  Sym.      N /  \
                                         |  Test  |  UDP    <---/Resp\
                                         |   II   |  Firewall   \ ?  /
                                         +--------+              \  /
                                             |                    \/
                                             V                     |Y
                  /\                         /\                    |
  Selective   N  /  \       +--------+   N  /  \                   V
   Outbound <-- /Resp\<-----|  Test  |<--- /Resp\               Open
  /Service NAT  \  ? /      |   I    |     \ ?  /               Internet
                 \  /       +--------+      \  /
                  \/                         \/
                  |Y                          |Y
                  |                           |
                  |                           V
                  V                          Full
                  /\                          Cone
   Symmetric  N  /  \ 
      NAT  <--- / IP \
                \Same/ 
                 \? / 
                  \/ 
                  |Y 
                  | 
                  V              /\
              +--------+        /  \ Y
              |  Test  |------>/Resp\---->Restricted
              |   III  |       \ ?  /
              +--------+        \  /
                                 \/
                                  |N
                                  |       Port
                                  +------>Restricted

Whereby if the 2nd execution of Test I using the changed address fails to receive a response it is indicated to be of type "Selective Outbound/Service NAT" indicating that the NAT firewall used for outbound communication from the client has selective port filtering, or that the machine running the STUN server has chosen not to listen to request on a CHANGED-ADDRESS.  This maybe because the administrator of the STUN server may only desire the IP address discovery portion of STUN to be used and not the NAT discovery portion.

If the latter is the case, there should be something in the RFC that indicates that the STUN server will return the same IP address/port as the original request was made if it does not intend to do NAT discovery but still send out a CHANGE-ADDRESS attribute (ie. a1/p1=a2/p2).

L 

"Yutaka Takeda" <[email-masked]> wrote ..
> 
> 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
> > 
> >

---

From: [email-masked]
Date: Wed, 10 Sep 2003 23:57:30 -0700

The RFC does actually state that requests should be spaced out starting from 100ms doubling every request until 1.6s spacing is found and ultimately 9 requests have been sent.

This however is not the cause of the problem originally stated, just one of the many symptoms that can occur and leave the client in a state of unknown going by the original logic.  See a post I made, listed in the archive (http://www.ietf.org/mail-archive/working-groups/midcom/current/maillist.html) under September 9th, with a proposal for alteration to the logic to ensure that there's no room for different intepretation of the vague state that can occur.

L

Cullen Jennings <[email-masked]> wrote ..
> 
> 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.
> 
> On 9/8/03 19:28, "Yutaka Takeda" <[email-masked]> wrote:
> 
> > 
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/midcom
> >

---

From: "Yutaka Takeda" <[email-masked]>
Date: Thu, 11 Sep 2003 12:01:18 -0700

I wonder how much it is worth discussing one particular router's
behavior, however, the router I mentioned reacted to the 
re-transmission defined in RFC 3489 as Les mentioned.

Is the 10 ms interval time a general practice to prevent it? Is 
there a public reference for the interval time between packets 
from an unknown source that will be considered as DOS attack?

This might encourage a use of ICE, checking connectivity before 
sending media packets in order to avoid unnecessary firewall 
blockage, or might not because the connectivity check with STUN
itself might be treated as a DoS attack or a port scanning 
depending on configuration of a firewall.

Yutaka

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, September 10, 2003 11:15 PM
> To: Yutaka Takeda; [email-masked]
> Cc: Midcom; Jonathan Rosenberg
> 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.
>