Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

[Hadriel Kaplan <[e-mail]>]

On Jul 24, 2013, at 11:46 AM, <[e-mail]> wrote:

> Right, but the "threat" for STIR is that someone receiving a INVITE/IAM gets a calling party number that it uses for caller-id display (or whatever) and the number is being maliciously misrepresented.  Obviously we don't know when it's being maliciously misrepresented or just an honest mistake/error, and many INVITES/IAMs won't be signed at all at least in the beginning, so we likely won't be able to block such calls for a very long time if ever.  Instead we'll either anonymize the calling number (block number display), or check with some other policy engine, or log it for later analysis, or send it to an IVR, or whatever - it's a local policy decision really.
> 
> So assume you get a INVITE/IAM with a RFC 6567 UUI.  It would be a local policy decision what to do.  You can decide that the destination subscriber doesn't have a UUI service, for example a mobile/home phone wouldn't, and thus treat it as an unsigned call and anonymize the calling number or block it or whatever.  Or you can decide that the SIP Trunk to an Enterprise has such UUI "service", and pass the INVITE/IAM on to it unchanged as you do today.  The IP-PBX is then responsible for deciding whether the INVITE/IAM with such a UUI is valid/allowed - for example if it's from a branch office or whatever.  That's what it has to decide already today, and we don't seem to have a spoofed caller problem for those cases today. 
> The danger with letting a RFC 6567 UUI trump an IKES UUI is that malicious sources could just start 
> adding RFC 6567 UUIs to their INVITEs.  We can easily detect and block that for destinations that don't 
> expect to get 6567 UUIs.                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> [PhF] I'm missing something here: how does an interconnect point detect that a particular end site expect UUI or not? Suppose one of your malicious source adds those RFC 6567 UUIs to get through, how would you possibly know upstream whether it is legitimate or not, as you said it's a local policy? 

Sorry, I didn't mean the ingress point (SBC/IBCF) of a carrier could block it - I just meant the carrier could block it somewhere, for example in the S-CSCF that routes the call to the IP-PBX's trunk, or an SBC connecting to the IP-PBX trunk, or whatever.


> The hard part is how to block it for IP-PBXs that do expect 6567 UUIs.  
> [PhF] It seems to me that part of the problem is precisely that you don't know which do and which don't.  

As far as I know, the carriers know if a PBX-trunk/Enterprise-customer has UUI support or not.  For example it's in the service contract/agreement with the Enterprise for SIP trunk service.  Is that not the case? (I could easily be wrong about that - it was just what I heard)


> If it becomes a problem, there are some potential solutions.  One solution is to only support 6567 UUI for inter-branch calls that stay SIP along the whole path (since the IKES info is in a SIP header, it can be used at the same time as 6567 UUI for SIP).  That's not unreasonable, because as far as I know such inter-branch calls typically only work within the same carrier, or only within a small set of fixed/known/pre-arranged set of carriers in a country.  
> If that's true, then it's not unreasonable to expect the small set of carriers to support SIP interconnect, 
> 
> [PhF] As an aside, even if they did support SIP interconnect, this seems to assume that you don't have ISUP or some encapsulation of it in parallel/addition to "full SIP". 

Sorry I should have been clearer.  I meant the IKES info is still in a SIP header, even if there's an ISUP mime body in the SIP message.  So for SIP-SIP scenarios, you can leave the RFC 6567 UUI alone, while still having IKES.  IT should probably be clearer about that in the draft.

-hadriel