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

<philippe.fouquart@orange.com> Tue, 23 July 2013 16:23 UTC

Return-Path: <philippe.fouquart@orange.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6811E82E9 for <stir@ietfa.amsl.com>; Tue, 23 Jul 2013 09:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuiSmIKMRtxG for <stir@ietfa.amsl.com>; Tue, 23 Jul 2013 09:23:36 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CABC011E82DF for <stir@ietf.org>; Tue, 23 Jul 2013 09:23:18 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 504932DCAE9; Tue, 23 Jul 2013 18:23:13 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 35E144C024; Tue, 23 Jul 2013 18:23:13 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 18:23:12 +0200
From: philippe.fouquart@orange.com
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>, "stir@ietf.org" <stir@ietf.org>
Thread-Topic: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt
Thread-Index: AQHOfrnJIrVpZ/tZPUKeljXpre8LSZlychJw
Date: Tue, 23 Jul 2013 16:23:12 +0000
Message-ID: <19893_1374596593_51EEADF1_19893_9071_1_B5939C6860701C49AA39C5DA5189448B0B55A6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <20130712043221.11767.74779.idtracker@ietfa.amsl.com> <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com>
In-Reply-To: <1F4B4D44-BD3E-4995-876A-147832C925F9@oracle.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.23.150632
Subject: Re: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2013 16:23:41 -0000

Hadriel,

A couple of initial questions/comments on this draft. 

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

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

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

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

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

Thanks, 

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13


-----Original Message-----
From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Friday, July 12, 2013 6:39 AM
To: stir@ietf.org
Subject: [stir] I-D Action: draft-kaplan-stir-ikes-out-00.txt

Howdy,
I've been meaning to submit a couple drafts for STIR - one for how a DNS model could work, and one for how the stuff can get through SIP and other protocols in-band.

Since some of the recent discussion has touched on some of the issues, and the deadline for new drafts is fast approaching, I've submitted the latter draft just now:
http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00

Sorry about the length, and yes it's still drafty/straw-man-ish.  It's also repetitive in sections, and needs a re-write, but the general concept should be understandable.

Comments/flames appreciated.

-hadriel


Begin forwarded message:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : An Identity Key-based and Effective Signature for Origin-Unknown Types
> 	Author(s)       : Hadriel Kaplan
> 	Filename        : draft-kaplan-stir-ikes-out-00.txt
> 	Pages           : 28
> 	Date            : 2013-07-11
> 
> Abstract:
>   This document describes a mechanism and format for signing source
>   identity information of communication requests, in a manner capable
>   of crossing multiple communication protocol types - even if the
>   origin's protocol type is unknown.  This is useful for providing
>   E.164 and other forms of Caller-ID reputability for various
>   communication protocols, such as SIP, XMPP, WebRTC, H.323, and
>   SS7/ISUP.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-kaplan-stir-ikes-out
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-kaplan-stir-ikes-out-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

_________________________________________________________________________________________________________________________

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.