RE: [Sip] SIP Identity using Media Path

["Christer Holmberg (JO/LMF)" <christer.holmberg@xxxxxxxxxxxx>]

Hi,
 
>>>>"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.
>> 
>>A little more on this.
>> 
>>As we have discussed before, you may not have two-way connectivity 
>>before 200 OK.
>>
>>I am pretty sure what will not work with most SBCs.
>>
>>Now assume that you will have two-way connectivity before you have 
>>even sent the SDP answer.
> 
> 
>I think you meant to say "now assume that you will _not_ ..."?

What I meant to say was: Now you assume that you will have two-way
connectivity before you have even sent the SDP answer :)


>In the case of no media path, it would only be possible for the
>authentication server, and the UA receiving the SIP request, to 
>cryptographically validate the SIP headers and a very minor 
>portion of the SDP (From:, Date:, and the header that we 
>generate that copies the a=fingerprint attributes from the 
>SDP, and the few other headers described in -wing-sip-identity-media).
> 
>This provides some protection against attackers, and works through
>SBCs.  Specifically, this protects against attackers who were not
>able to obtain a validly-signed SIP request.
> 
> 
>However, only validating those SIP headers is inadequate if
>an attacker has captured or otherwise acquired a validly-signed 
>SIP request, modified the SDP (such that the signature is 
>still valid), and re-injected that SIP request into a SIP 
>proxy that forwards it to you.  In order to detect such a 
>replay attack, you need to perform one of the media-path based 
>tests that I describe in wing-sip-identity-media (DTLS-SRTP, 
>HIP, ICE, TLS).
> 
> 

>>Also, even if you don't have any SBCs, but you still have NATs, the
>>calling user often needs to send something in order to open the NAT
>>binding, and allow media plane traffic (including your identity
>>exchange) from the remote end. If you use ICE, or stand-alone 
>>STUN, you will have an open NAT binding, but if your terminal opens 
>>the network e.g. by sending dummy RTP packets, it will not be able to
do 
>>so until it has received the SDP answer.
> 
>* But if you haven't received the SDP answer, where are you sending
>those dummy RTP packets (what is their destination IP address and 
>UDP port)?

That is what I am saying: the user needs to get the SDP answer, so that
it can open the NAT binding (and allow incoming traffic)

>* If the NAT perform address-based filtering of incoming packets, 
>it drop incoming UDP packets until the device behind the NAT
>(the SIP UA, in our case) sends a packet to the IP address sending
>the incoming packet.  The SIP UA would learn that IP address upon
>receipt of the SDP answer.  Further, if the NAT is doing port
>iltering of incoming packets, the SIP UA needs to know the UDP
>port the external packet is arriving from, too (which also shows
>up in the answer).  I point out the problem with port filtering
>NATs because sending dummy UDP packets to the SBC's IP address 
>is not sufficient for those kinds of NATs.  Similarly, if the 
>NAT is symmetric (assigns a new UDP port for every new 
>destination port or destination address the SIP UA sends to), 
>sending dummy UDP packets won't be effective for symmetric
>NATs, either.
> 
>>So, I also think your solution requires support of ICE/STUN, 
>>and in the case of ICE it also requires that the SBCs 
>>don't mess up the SDP so that ICE will not be used.
> 
>No, it does not.
> 
>For protection against simple From: spoofing, it is adequate to
>simply validate the SIP headers and the signature.  For protection
>against replay attacks, it is necessary for both SIP UAs (*) to
>implement one of HIP, ICE, DTLS-SRTP, or TLS.  

Ok, so let me put it this way: any feature in your solution that, in a
NAT requirement, does require end-to-end connectivity before the SDP
answer has been sent requires at least STUN (not necessarily ICE) - or
some other mechanism which the NAT binding is opened without having the
remote SDP. And, if you use ICE, the SBCs must not modify the SDPs in a
way so that ICE is disabled.

Regards,

Christer