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

[Hadriel Kaplan <[e-mail]>]

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.


> - "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.  The hard part is how to block it for IP-PBXs that do expect 6567 UUIs.  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, 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