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

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.

A short and  probably useless answer is NAT traversal,
transcoding and security (possibly illusive) in the scenarios I know.

The real trouble is that all sorts of SDP rewriting in the field are a rule,
and not rewriting is an exception. It is just so straight-forward to do
for the applications I know. It is widely deployed, and here to stay.
Relying on e2e SDP integrity by the way of TURN seems to me
an alibi at best, if not a hopeless try to reverse history.

Therefore I would choose the opposite way and try to learn what
are the pieces for which we have a compelling need for integrity.
(either way it may be hard to set a demarcation line though).


> 
> 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.

That's the approach we have taken to deal with media relays for sake
of NAT traversal and turned out hard to deploy. I haver considered this
good enough for the particular rather simple scenarios I have been
interested in. SER calculates the message integrity protection for
outbound SDP. Even in such scenarios do ddly ALGs still appear between
signer and verifier, and are difficult to get out (even though they are
evil and shall  not be there in the first place, and are typically
controllable by the same company that controls the SIP server).

I'm therefore seeking protocols that do not require full SDP integrity
along any SIP  path segment. Only this way I think we can achieve
robustness against ALGs, SBCs, evil boxes, grand applications and
what have you, and not limit ourselves to a subset of scnarios
understood today.

-jiri

> 
> Cullen <in my individual contributor role>
> 


_______________________________________________
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