On Mon, 2008-10-20 at 10:20 +0200, Klaus Darilion wrote:
> 
> [EMAIL PROTECTED] schrieb:

> > You should first consider if you want to give an error, rather than
> > simply forwarding the request to the proxy for the domain in the
> > request-URI.  In many cases, a proxy will receive requests from
> > various sources, and not all of the requests will be destined for the
> > domain that "owns" the proxy.
> 
> This advice is horribly. Just forwarding the request means that the 
> proxy is an open relay, like open SMTP relays [1], and opens the door 
> for SPIT and various other kinds of attacks.

There are important differences between a SIP proxy and a open relay
mail forwarding system:

      * Mail is store-and-forward, SIP is real-time
      * A mail relay can be an amplifier: send it one message and it
        will forward that message to thousands of targets, but if you
        send a call to a SIP proxy it will only actually complete that
        call to one destination.

These combine to give advantages to the recipient of an unwanted SIP
call that an email spam recipient does not have.  The SIP call recipient
has an opportunity to trace the call to its real origin even before the
call is set up (note: I'm talking about SIP Proxies here, so the Via
path gives you an accurate trail that must include the real caller; a
B2BUA is more problematic - another reason not to deploy them).

I'm not arguing at all that "spit" is not a problem - it is, and it will
probably grow.  I doubt that it can grow to anything like the same
magnitude of problem that spam is, because it has a very different cost
model: it costs almost nothing to send an email, and open relays will
explode it for you, but to make a spit call you must have something that
can generate the RTP stream in real time to each and every recipient.

Whether or not to forward a SIP request that is not for your domain
depends on your deployment model and whether or not you want to support
end-to-end SIP calling.  If you want to be able to support end-to-end
SIP, that implies that your users can use real SIP URLs as addresses (as
opposed to PSTN numbers as a user part with your domain).  You could, of
course, limit such forwarding to clients that can authenticate as being
in your domain, but to just unconditionally reject them all because they
are not local deprives you of one of the real advantages of SIP: the
ability to reach the entire Internet.


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to