Re: francois' comments and why RFC4474 not used in the field

On Apr 2, 2009, at 11:40 PM, Hadriel Kaplan wrote:

>
>
>
>> So are there any legitimate use cases for requiring that the protocol
>> supports MITM rewriting of SDP?
>
> We already gave you some.

I believe Cullen and Jon are arguing that no, you haven't -- you have  
just made the same non-examples 50 different ways. I know you want to  
do media-steering and see this as self evident. They want to know why  
media-steering requires SDP editing. I believe they think we need to  
make a more fundamental change to support media-steering instead of  
just hacking on the SDP.

> But really the question can just be flipped around: is there a  
> security property of the SDP's IP/port that you feel is important to  
> protect, such that we can't allow it to be changed?  Do you feel an  
> IP:port is an identity, or is somehow actually a secure indicator of  
> anything?  I mean there's plenty of other important things in SIP  
> we're not protecting with 4474 - maybe we should just sign the  
> entire SIP message, just in case.  But we don't, because we know it  
> wouldn't work in the real world, and because most of them have  
> little security value to protect.
>

Simple rational conservatism says just change something that isn't  
broken. Good enjoying practice says don't change something that  
appears to be broken until you understand the real requirements.  
Medical practice teaches us to treat the cause, not the symptom. Is  
the need to edit SDP a cause or a symptom? To me, it looks like it  
just might be a symptom of a more severe condition.

>
>> Perhaps is lots of calls started failing because they endpoints  
>> detect
>> that a MITM attack on their signaling/media has occurred, and did so
>> in a way that makes that failure evident to the MITM, then we'd see
>> fewer MITMs making that mistake.
>
> If calls started failing because of 4474, I'm fairly sure it would  
> be 4474 that would be turned off, not the SDP re-writers.  Because  
> they're not an MITM attack on users or calls - it's a MITM attack on  
> the IETF's principles.  But then again, there's no need to turn 4474  
> off - it can just be removed by a MITM.

If users start to refuse carrier services because the carrier's SBC- 
riddled architectures can't support the users security requirements,  
carriers will either fix their architectures or go broke.  
Historically, many of them would rather go broke than fix their  
architecture, and I'm okay with that.

--
Dean

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip