Re: [Sip] Outbound Issues: slides 3 and 4 - the problem ...

[Dean Willis <dean.willis at softarmor.com>]

On Aug 9, 2006, at 1:49 PM, Cullen Jennings wrote:


> Just so we are clear on the when this could be a problem....
>
> For any UA that is automatically configured, this is unlikely to  
> every be a problem. What we are talking about here is UA where some  
> human types in the configuration information to the UA. Even though  
> they were told to enter example.com as the outbound proxy, they  
> decide to enter example.com;keep-alice=stun because perhaps they  
> saw that in some other system. Their device sends a stun packet and  
> gets black listed. Note that any services that blacklists after  
> receiving a single STUN packet with a spoofed IP address is going  
> to be trivial to totally DOS so I don't believe this sort of thing  
> will deploy buts let continue down this case. So the user UA does  
> not work. It also would not have worked if they typed in  
> elpmaxe.com (example backwards). What do they do? read a web page,  
> phone tech support, I have no idea but they do whatever they do  
> when they configure the outbound proxy information correction.  
> Eventually they find out to remove the keep-alive=stun and their  
> phone starts working.

I'm more worried about the scenario where the UA doesn't get  
blacklisted, but just throws a monkeywrench in performance, and it  
sucks just enough that people don't fix it but complain anyhow.

> For these reasons, I don't think this whole problem is not a huge  
> deal. However, if people do think it is a big deal, the obvious  
> solution to it is send and OPTIONS message to find out if the  
> server supports this.  Most people don't seem to think this is  
> enough of a problem to warrant and additional RTT when a UA boots.  
> We can come up with other possible solutions to this too (as there  
> are at least three others on this same thread).

To recap:

Unacceptable: If you're configured to use STUN, just keep STUNning  
whether it works or not. You may be dead, but you're right, and  
that's the important part.


Alternatives:

1) Use an OPTIONS transaction before stunning to find out if the  
target supports STUN
2) Use any other SIP transaction (like REGISTER) to find out if the  
target supports STUN
	a) using a Proxy-Require
	b) Using some sort of Path: tagging
3) Just go ahead and STUN, and if it doesn't work, stop sending STUN.

I'd be happy with 1+3 or 2+3. I'd even be happy with 1+3 where 1 is a  
"SHOULD" strength, but 3 needs to be a MUST. It may be common sense,  
but it requires documentation, and people seem to need "common sense"  
to have a MUST priority on it or they pretend it isn't important.

If we go the 1-SHOULD+3-MUST route, we need to include the "Because  
the proxy might think your STUN is an attack or error condition and  
black-list you" as the explanation for the SHOULD.


--
Dean





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip