Subject: [BEHAVE] draft-wing-behave-nat-control-stun-usage legacy interaction

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 2 Feb 2007 15:33:54 +0200

Hello,

As far as I understand draft-wing-behave-nat-control-stun-usage-00, it is 
proposed that STUN clients could try to probe the NAT by sending a STUN 
request to the NAT external IP address as learnt from the STUN server 
response. Interesting idea.

However, while I certainly hope it does not actually happen, as anyone checked 
that this does not trigger non-deterministic behaviors in legacy NATs, which 
could then make the NAT traversal more difficult in the end?

Note: I have not observed this behavior myself (but then again I did not test 
it at all ;) ).

-- 
Rémi Denis-Courmont <[email-masked]>
Research Engineer

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Feb 2007 14:06:47 -0800

A good question.  However, in order to thwart the attack
described in
http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-00#secti
on-6.3 of the current document, the STUN client needs to first communicate
with its outer-most NAT using TLS to obtain a STUN shared secret.  The
attack is this (from the link above):

   As described in Section 4, a STUN client can learn its outer-most NAT
   runs an embedded STUN server.  Without the STUN client's knowledge,
   the outer-most NAT may acquire a new IP address (after moving to a
   new mobile network or DHCP lease expiration).  When it acquires a new
   IP address, the STUN client will send a STUN Binding Request to the
   NAT's prior public IP address.  If an attacker acquires that public
   IP address and installs a rogue STUN server, the attacker has
   effectively acheived the attack "Compromise a Legitimate STUN Server"
   (section 12.2.1 of [RFC3489]).  The attacker will send STUN Binding
   Responses indicating his IP address, which will be indistingushable,
   to the STUN client, from the behavior of the legitimate STUN server.
   To defend against this attack, the STUN client and STUN server need
   to obtain a short-term password as described in
   [I-D.ietf-behave-rfc3489bis].

Perhaps that attack isn't bothersome to most people; I don't know.  Feedback
on this would be useful.  Many small NATs have TLS support for their HTTPS
management interface, so TLS isn't onerous.  

Another idea I have had to thwart this specific attack is to have the NAT to
return a random number that is static for the duration of the NAT's
operation (that is, it changes when the NAT crashes).  So, you would learn
your NAT's public IP address, then send it a binding request (without first
doing a shared secret request).  The NAT would return a binding response,
the XOR-INTERNAL-ADDRESS, and also return a new attribute with a random
number in it.  You could then use your NAT's built-in STUN server forever
more, so long as it returned that same attribute with that same random
number.  When that random number changed, you would talk to your STUN server
on the public Internet.  This is more lightweight than TLS and TCP, but I
haven't convinced myself it completely protects against someone else
acquiring the NAT's public IP address (through DHCP lease expiration or
through Mobile IP address reassignment, for example).

But with the current functionality as described in -00, because you need to
talk to your NAT's public IP address using TCP first, the NAT Control STUN
Usage should be very unlikely to trigger unexpected NAT behavior.

I am adjusting the next version of the document so the necessary steps are
clear.  I see that in -00's Overview of Operation section, the need to first
get a shared secret isn't spelled out.  The client procedure (section 3.6)
does describe it, though.  That was an oversight on my part, my apologies.

-d

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Friday, February 02, 2007 5:34 AM
> To: [email-masked]
> Subject: [BEHAVE] draft-wing-behave-nat-control-stun-usage 
> legacy interaction
> 
> 	Hello,
> 
> As far as I understand 
> draft-wing-behave-nat-control-stun-usage-00, it is