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

[Hadriel Kaplan <[e-mail]>]

Thanks for the review and catching this stuff!  More comments inline...

On Jul 23, 2013, at 12:23 PM, [e-mail] wrote:

> Just an observation, first. Sometimes in 4.1 and 4.2 (see below), definitions seem to refer to numbers in general, examples taken from the NANP,... and some conclusion drawn essentially from an observation on the example rather than from the definition. :) 

Ahh sorry.  I need to clean the draft up for sure. :)


>> IKES also considers toll-free 1-8xx type numbers to be "E.164" numbers, 
>> even though technically they are not.
> 
> If the statement is not only about US toll free numbers but on "freephone" numbers in general ("cc-8xx" being indeed very common for that), "technically they may not be", would be more accurate I think, on other CCs some of them are actually reachable from abroad. 

OK, will fix in next rev.


>> Nationally-specific number codes are numbers that are not E.164 
>>  numbers, nor are private numbering plan numbers, but are instead 
>>  number codes used for specific purposes within national numbering 
>>  plans.  Examples of these are N11 codes in the NANP, two or three 
>>  digit emergency numbers such as 112, and inter-carrier common short 
>>  codes.  Even if they cannot be used as caller-id numbers , they are 
>>  destination numbers and thus IKES needs to support them.  
> 
> Actually short codes can sometimes be used as CgPN, again it depends on the country. Probably not emergency numbers, (although you might even find corner cases in the European 116 series, some of which qualify as such in some countries) but short codes can be. 

I meant to imply that but it didn't come across right - when I said "Even if they cannot be used as caller-id numbers", I really meant more "Even for cases where they cannot be used as caller-id numbers".


> 
>>  Likewise for nationally-specific number codes, the IKES process 
>>  generates a canonical representation of the number code.  A leading 
>>  country-code is prepended to the number code, to indicate the 
>>  national numbering plan they are for.
> 
> I suppose you've been waiting for this but the usual problem of using such "pseudo E.164 numbers" for non E.164 numbers instead of local numbers is that, for countries that use national trunk codes eg 0, you can have an overlap between the short codes and the initial digits of the E.164 NDC or the SN. It's obviously not a problem as long as we stay in the dialing plan (actually that's precisely what the national trunk code is here for, to have more spare values to use) but it seems this would mean that the assignee of say range 112 could legitimately sign +CC-112, I'm not sure that's a good thing. (although this particular one 112 is indeed generally reserved in the national E.164 numbering plan but I use it to get the picture). 

Yup, I've been waiting for that. :)

So right now in the CIDER draft it talks about there being a different domain name anchor for E.164s vs. number-codes.  So "cid.example.com" might be the E.164 anchor, while "nid.example.com" might be used for number-codes.  So a key holder for the whole E.164 range prefixed by +33-112 couldn't successfully sign a number-code of 112 in France, because the IKES-receiving verifier would look the latter E.164 up as "2.1.1.3.3.nid.example.com", while the attacker's key is only in "2.1.1.3.3.cid.example.com" and thus only valid for that number-code.

I think I put an example in where they used the same anchor, which is probably dangerous for the reason you said.  If I did, I'll fix it next rev.


>> 10.  Usage in SS7/ISUP
> [...]
>> the signature, key 
>>  index, and timestamp are carried in the User-to-User Information 
>>  parameter ;
> 
> (Noted past exchanges on this. Don't think this was addressed) Generally speaking, what if the UUI is already used for a different purpose? (eg RFC 6467 use cases)

Yeah, I was waiting for the emails discussion around it to coalesce.  I think the right thing to do would be for RFC 6567 to win - the UUI in that case is for a end-to-end UUI as used in inter-PBX/inter-branch cases, so the IKES Generator or SIP-SS7 interworking gateway should not replace it with the IKES stuff.  I'm thinking that's ok, because as far as I know those inter-PBX cases are already in controlled environments and don't have a faked caller-id problem from random sources.  Yes/no?

-hadriel