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

[<[e-mail]>]

Thanks. More in-line...

Philippe Fouquart
Orange Labs Networks
[phone]


-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: Thursday, July 25, 2013 7:23 AM
To: FOUQUART Philippe OLNC/OLN
Cc: [e-mail]
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt


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

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

[PhF]  OK, thanks. The difference then is that the call server would then know whether UUI is supported to/from a particular site, it doesn't mean that UUI 'must' or 'must not' be present for a particular message. (see next) 

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

[PhF] It is. I don't know if it's the general situation for all such contracts but indeed for the baseline offer I'm familiar with, UUI is actually always included by default, but the endpoint may or may not use it, or may use it only occasionally, so at a given point in time, how would the network know whether to expect UUI to/from that site? 

-hadriel


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.