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

From: "Panayiotis A. Thermos" <[email-masked]>
Date: Tue, 19 Nov 2002 16:49:05 -0500

Just for clarification purposes could you provide an example of such
attack?

One scenario that I can think is where a malicious user generates multiple
STUN messages with the  RESPONSE-ADDRESS attribute pointing to
a "victim" host then according to the current draft  (and depending on the
implementation) the victim host will check the   MESSAGE-INTEGRITY
field and it will be ignored since it is not  a message that  the victim
host
has generated. I'm not clear in what scenario the REFLECTED-FROM
will be most effective given that we already some infotmation from
previous interaction over SSL.

There is also the case where a legitimate STUN response has to be
be send to another "trusted" multimedia component (other than the one
that generated the request), which is part  of the end-user's environment.
This should be addressed  seperately.

Thanks for your help.

                    Jonathan                                                                           
                    Rosenberg              To:     [email-masked]                                     
                    <jdrosen@dynami        cc:     (bcc: Panayiotis A. Thermos/Telcordia)              
                    csoft.com>             Subject:     [midcom] STUN issue #5: reflector attacks      
                                                                                                       
                    11/19/2002                                                                         
                    03:22 AM                                                                           

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Nov 2002 03:20:24 -0500

It was my understanding that he was referring to this:

V. Paxson, "An analysis of using reflectors for distributed
    denial of service attacks," ACM Computer Communication Review , Vol.
    31, July 2001.

-Jonathan R.