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

On Apr 1, 2009, at 12:52 AM, Dean Willis wrote:

>
> On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote:
>
>>
>> On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
>>
>>>
>>> I'm worried this is only a wishful thinking. While perfectly
>>> logical, still even in such constrained setups some bizzar
>>> ALGs do in my experience appear in the middle, change SDP
>>> and make thus the identity worthless.
>>
>> The thing I keep asking is can we make a list of reason why SDP and  
>> headers get changes and in what scenarios they do this. I think it  
>> will be hard to sort how to fix this without being clear what needs  
>> to be fixed.
>>
>> For example, one of the things we might want to say is something  
>> like: the Phone is behind a NAT and connects to it's proxy /  
>> registrar for its' domain. That proxy/b2bua whatever mucks with IP/ 
>> ports in the SDP for NAT traversal. Then we could ask if 4474 is  
>> broken in this case or not and what might be a good way of solving  
>> the problem of having UAs behind NATs.
>>
>
> You seem to be trying to construct an argument for "why 4474 isn't  
> broken" based on being able to transform every use case where RFC  
> 4474 breaks to one where it doesn't, generally by mandating a  
> different approach to solving problems (TURN vs, SDP fixup, for  
> example). You seem to expect this to prove that RFC 4474 is fine as- 
> is, needing no modification to its A/M signing.


No Dean. I am trying to get to what is the problem - and what I see  
happening is several people trying to transform that into Jon and  
Cullen are blocking work in this space which is not at all true - I  
would love to see some progress in this space.

>
>
> It might be useful to counter this with "If RFC 4474 isn't broken,  
> why isn't it being deployed?"

It's not needed in the bulk of todays deployments. Deployments using  
email stye addresses are directly connecting often with mutual TLS or  
an equivalently bound VPN. When enterprise B gets a call from [email protected] 
  and it came over a TLS connection that had a certificate of a.com,  
well you get something that meets B's authorization needs with just  
that. For deployments using E.164 style addresses - they are pretty  
much all capable of connecting in and out of the PSTN and there is no  
interest in a security properties greater than what PSTN provides as  
that is acceptable for most these users. This can easily be  
accomplished with PAI and a transitive trust model. In fact, many of  
these deployments have SP A talking to SP B talking to SP C and B  
explicitly wants to hide that they used SP C instead of terminating  
the call themselves. B needs to make it look like to A like B  
terminated the call into the PSTN vs handing it to C. These sort of  
deployments require B to look to A like the end not the middle.

> I expect that the answer is "because users currently expect to  
> correct their topological issues using SBCs instead of the tools  
> that work with 4474. You might not think they have legitimate  
> reasons for doing it this way, but the fact remains -- that's how  
> they do it.

You expect it might be one thing - fair enough, other disagree. What I  
am suggesting will be the best way to make progress is to find out  
what they do and what needs caused them to do it. Sure, for any  
problem, there will be multiple ways to skin the cat. You are accusing  
me of saying that the only way people are allowed to skin the cat is  
using a potato peeler and that most people probably will not use a  
potato peeler for cats no matter what I want. I am not in the  
slightest telling people they have to use a potato peeler - I'm  
arguing that until we have some common ground on if we are trying to  
peel a cat or potato or both, we are unlikely to make progress on the  
best tool(s) for the job.

> Technically correct or not, ordering this to flow out is likely to  
> give you wet feet.
>
> --
> 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