[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Sip] SIP Identity using Media Path




Hi, 

>>Chapter 9 says:
>> 
>>"in order for the mechanism to work, SBC-type-of-entities must permit 
>>DTLS, TLS, ICE, or HIP messages to be exchanged in the media path."
>> 
>>A small question for clarification: at what point must this exchange 
>>(two-way, I assume) work? As soon as the UAS has received the INVITE?
> 
>Yes.

As we know from our RTPSEC discussions, one of the issues of using
SBC-type-of-entities (or gates) is that you MAY NOT have end-to-end
media plane connectivity as soon as the INVITE has been sent.

Regards,

Christer


 
>The DTLS, TLS, ICE, or HIP exchange would need to occur prior 
>to displaying Caller-ID-like information to the user -- 
>otherwise, an attacker could spoof that Caller-ID 
>information.  It seems defective, to me, to display Caller-ID 
>information that was spoofed to only later learn (after doing 
>DTLS, TLS, ICE, or HIP) that the calling party had lied about 
>their identity.  
> 
>There is some protection against such an attack that could 
>reduce this risk (the Date: header is signed, so the attacker 
>would need to obtain a relatively recent SIP request) -- that 
>protection might be sufficient in networks that block 
>exchange of packets prior to 200 Ok.  If an attacker was able 
>to get ahold of such a SIP request, you would know it when 
>the attacker failed the DTLS, TLS, ICE, or HIP exchange, 
>which I suppose is better than nothing.
> 
> -d
>