Re: [Sip] RFC 4474 and SBC traversal

["Fischer, Kai" <kai.fischer at siemens.com>]

> 
> >> This issue is totally independent from E.164
> >>     
> >
> > Not fully. SBCs may exchange the domain part of the E.164 
> SIP URI, which
> > causes a break of the RFC 4474 signature. With email-style 
> URIs a simple
> > exchange is not possible.
> >   
> This is true but this applies to SIP Identity in general and not to 
> E.164 number usage with SIP Identity only.
> Hence, I would not tie it to this discussion.

My point was, that with E.164 an intermediary SBC is able to exchange
the domain part without a possibility on the terminating side to
recognize the change. With email-like SIP URIs the domain change is not
possible or only with a hack. Two cases need to be differentiated:
-SBC modifies SDP: This results in a necessity to create a new SIP
Identity signature and a change of the domain part in the From header
(valid for both types of SIP URIs email and E.164)
-SBC modifies From header field only: This is applicable to E.164 only
and as far as I have recognized from the past discussions a real world
behavior

> 
> >   
> >> I don't like the idea of requiring DTLS-SRTP to provide proof of 
> >> possession of the keying material.
> >>     
> >
> > It is also the other way round. If you use DTLS-SRTP to 
> encrypt RTP, the
> > terminating domain is interested where the call originates 
> from and in
> > which domain the SRTP connection is terminated. DTLS-SRTP is not
> > initially used as mean to establish an identity rather than as the
> > initial aim to encrypt RTP.
> >   
> 
> I understand the need to know who the end points are. However, tying 
> DTLS-SRTP is not a good idea since it
> a) increases the liklihood that SIP identity never get's 
> deployed (since 
> it is suddently far more complex than before)
> b) SIP identity is used also as a identity mechanism in areas 
> where no 
> media is exchanged.

Do you propose to not apply RFC 4474 for DTLS-SRTP fingerprint
protection and to rely on something different?

Kai

> 
> Ciao
> Hannes
> 
> > Kai
> >
> >   
> >> Ciao
> >> Hannes
> >>
> >>
> >> Elwell, John wrote:
> >>     
> >>> SBCs do exist, often for good reasons that Hadriel has expanded on
> >>> already. I firmly believe that DTLS-SRTP will not be 
> deployable in a
> >>> meaningful way without addressing this problem. Concerning 
> >>>       
> >> solutions, we
> >>     
> >>> have drafts from Kai and Dan, or perhaps a merger of the 
> two somehow
> >>> would work. It also depends to some extent whether we are 
> >>>       
> >> talking only
> >>     
> >>> about email-style URIs or about E.164-based URIs too.
> >>>
> >>> John
> >>> _______________________________________________
> >>> Sip mailing list  https://www.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
> >>>   
> >>>       
> >> _______________________________________________
> >> Sip mailing list  https://www.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
> >>
> >>     
> 
> 
_______________________________________________
Sip mailing list  https://www.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