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

[<[e-mail]>]

Thanks for the clarifications. Some comments in-line. 

Philippe Fouquart
Orange Labs Networks
[phone]


-----Original Message-----
From: Hadriel Kaplan [mailto:[e-mail]] 
Sent: Wednesday, July 24, 2013 2:58 PM
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 5:57 AM, [e-mail] wrote:

> [PhF] Thanks, I get the picture now (apologies maybe I should have started with cider, always better to start with the lighter stuff first). 
> 
> I find the term canonical a bit misleading then for two reasons: 
> - the point of converting into a canonical form to me is to have a unique form upon which all subsequent operations can be done whilst the non canonical form and related information that lead to it may be discarded altogether. I now understand why the draft insists on the IKES Generator using the "source identity type" in addition to the "canonical identity", it's just that having two distinct numbers (albeit of a different nature) leading to exactly the same "canonical" string to be processed and signed differently depending on their 'type' is quite confusing. 

Just to be clear, they're not the same canonical *IKES* string in the end - an E.164 would end up with a "G:" in front, while a number-code would end up with a "C:" in front, for the IKES-IF string.

[PhF] OK, thanks. Well then maybe the trick would be to say just that, "canonical IKES string", or even indeed "normalized IKES string", (eg Determining the normalized IKES string for E.164 Numbers and Number Codes for 4.2) rather than canonical form, and say as you put it that it's "only used for IKES processing internally in the IKES generator/verifier".

> - "canonical [E.164] form" for a number is as you know a very common term to describe the international E.164 format of a number stripped out of the visual separators. The canonical form in the draft is not that, well, expect for the E.164 numbers... I wouldn't like this "canonical" form to appear 'as is' in RU/To or From, for that matter, as I said in some numbering plans in would be problematic. 

Right it doesn't change the SIP message at all, and is only used for IKES processing internally in the IKES generator/verifier.  Can you suggest a better word than "canonical"?  I was thinking "normalized" but that word is also commonly used.


> Maybe that would be preferable to use a different term; if you'd rather not, maybe you want to add something along the lines of 3966 that says that "converting a nationally-specific number code into its canonical form/string does not make it a valid E.164 number: the string consisting of the leading country-code prepended to the number code cannot be assumed to be a valid E.164 number" 

I will add that line too - thanks!  But I agree with your earlier comment as well that using a different term might help.

> [PhF] Well, sort of: a) not all of them are in "controlled environments" b) it is not uncommon in national "PSTN" interconnect offerings to support this and pass it on transparently and c) this type of access may actually be the source if not maliciously-faked, at least erroneously-configured caller-id. Maybe for c) depending on their use of the UUI, they could privately/bilaterally come up with an index of sort to assert the "on-net" calls, but I think that's just too complex.

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? 

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.  

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

at least by the time this becomes a problem.  So the IP-PBX or penultimate carrier can have a local policy that it only believes INVITE/IAM with 6567 UUI if it also has a valid IKES info in a SIP header; and the IP-PBX can even have a local policy that only allows it if the validated number is for a number it allows to use 6567 UUI for (ie, it knows the branch office private number), etc.

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