IETF Logo Mail Archive

Re: [martini] Proposed work split:tackletelephone-numberregistration first

Adam Roach <adam@nostrum.com> Fri, 29 January 2010 16:39 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986A13A6A4B for <martini@core3.amsl.com>; Fri, 29 Jan 2010 08:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzTnT4LHm4e7 for <martini@core3.amsl.com>; Fri, 29 Jan 2010 08:39:30 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C28403A6A45 for <martini@ietf.org>; Fri, 29 Jan 2010 08:39:29 -0800 (PST)
Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0TGdoPX089213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <martini@ietf.org>; Fri, 29 Jan 2010 10:39:50 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4B630F56.1020304@nostrum.com>
Date: Fri, 29 Jan 2010 10:39:50 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: martini@ietf.org
References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><D890DEF3-37DF-462B-955A-94005E1808B5@standardstrack.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <E9F685BC6F3D40B0A113F8198BD62BE3@china.huawei.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> <A9CEEB4B-3523-487D-ACBE-FE5E739F590F@standardstrack.com> <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr>
Content-Type: multipart/alternative; boundary="------------020905000207000407040604"
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2010 16:39:31 -0000

On 1/29/10 10:28 AM, bruno.chatras@orange-ftgroup.com wrote:
> I'm not convinced that the issues identified with the 3GPP/ETSI/IMS solution prevent implementing it even outside the context of the IMS. I'm aware of a number of PBX on the market than can already accept an inbound INVITE request with a Request-URI containing either the registered contact or one of the implictly or explictly registered AoRs.

That's not really the major problem here. An incomplete list of the big 
issues off the top of my head are:

   1. Changing the semantics of REGISTER to indicate more than one human
      breaks certain security (policy) assumptions at intermediaries. It
      may also cause problems with Path, Service-Route, and connection
      re-use (that is, they may not "just work", as previously claimed,
      due to changing security properties).

   2. Changing the semantics of REGISTER (this is a different change) to
      mean "override RFC 3263 procedures with this mapping" instead of
      "add this AOR to Contact mapping to your database" breaks certain
      security assumptions at intermediaries.

   3. Using a mechanism other than DNS (a mechanism that returns
      different results than DNS) to map from domain names to IP
      addresses is effectively creating a parallel DNS system, which
      runs afoul ICANN and IAB stated positions.

   4. The current proposals don't clearly state who is "responsible" for
      a domain (as that terms is used in RFC 3261). Given that only the
      "responsible" party is allowed to retarget requests, problems
      arise with the basic model no matter who you choose as "responsible."

   5. There is some debate about whether the AORs being registered need
      to be indicated in the transaction at all (either in the request
      or in the response). Having them appear solves two separate
      problems: (a) it allows detection of mismatches between the SSP's
      idea of which AORs have been registered and the PBX's, and (b) it
      allows intermediaries to determine which AORs the registration
      pertains to. Using the 3GPP/ETSI approach would lead to
      potentially large responses, which causes issues when UDP is employed.


These are broad summaries -- the details of the problems have been given 
in prior emails and on the interim calls.

There are also the flat-out obvious protocol violations in the 3GPP/ETSI 
solution as specified, such as the syntactic violation of using 
unescaped POSIX regexes where nameaddrs are to appear, and the semantic 
violation of pushing these regexes into reg-event notifications (which 
is broken regardless of whether you escape them).

/a

v2.23.0 | Report a Bug | By Email