Subject: [midcom] STUN issue #5: reflector attacks

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 03:22:54 -0500

STUN has a RESPONSE-ADDRESS attribute. This attribute is used by the 
client to tell the server the IP/port where to send the response. This 
can be used by an attacker as a reflector attack, to mask the true 
source IP address of a dos attack.

Steve Bellovin suggested that this is best dealt with by adding, to the 
response, the source IP where the request came from, and to make sure 
its integrity protected. This adds traceability. So, you can't prevent 
this, but you can see the true source address. The proposal is to accept 
his recommendation and add a REFLECTED-FROM attribute containing this 
source address.

Note that this source address can't actually be the one from the UDP 
request (since thats easily spoofed). But rather, from the TLS exchange 
that established the USERNAME used in the request. That requires state 
in the server, OR a smart implementation which creates usernames that 
contain this IP, along with an hmac over them to protect it.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 19 Nov 2002 10:27:55 -0600

Fully agree!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Tuesday, November 19, 2002 2:23 AM
To: [email-masked]
Subject: [midcom] STUN issue #5: reflector attacks

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Nov 2002 02:11:35 -0500

This issue was discussed at length during the meeting in Atlanta. There 
was some concern raised that it didnt provide proper traceability. The 
algorithm suggested by Steve will allow the recipient of the response to 
determine the IP address where the TLS connection came from. That can be 
completely unrelated to where the UDP binding request came from. For 
example, I could open a TLS connection, get a username/password, and 
email that to someone. They could use that to launch an attack. The 
target would see my identity, not that of the attacker.

Furthermore, because of NAT, the source IP in the TLS connection would 
only point to the outermost NAT, not the specific user within.

I think that, in the end, these limitations are just fine. It is not the 
job of STUN to be an intrusion detection system. STUN nearly needs to 
point the finger to the "next person to whom the subpoena should go". If 
this is the enterprise that owns the NAT where the TLS connection came 
from, so be it. Its the NAT-vendors problems to maintain logs to trace 
the actual source. Its then the email server vendors problem to figure 
out who they mailed the username/password to.

So, even if its not the actual source, the username provides a useful 
point of contact for further investigation in the source of an attack, 
and thats sufficient.

Thus, it is my proposal that we retain the mechanism described below.

-Jonathan R.