RE: [dispatch] VIPR - proposed charter version 3
"Richard Shockey" <richard@shockey.us> Sun, 04 July 2010 20:48 UTC
Return-Path: <richard@shockey.us>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA043A68B9 for <ietf@core3.amsl.com>; Sun, 4 Jul 2010 13:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.336
X-Spam-Level:
X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
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 cyN2f358WwPg for <ietf@core3.amsl.com>; Sun, 4 Jul 2010 13:48:47 -0700 (PDT)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id BEC963A66B4 for <ietf@ietf.org>; Sun, 4 Jul 2010 13:48:47 -0700 (PDT)
Received: (qmail 23165 invoked by uid 0); 4 Jul 2010 20:48:48 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 4 Jul 2010 20:48:48 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=IgKKOffrQlcZr8eXS30O3HApg8ptn8su12LISq2W2YO4jj6dDbD3N8D1F9uLvXSEYVuKtfeuZ5YDrd4p3+5ixI287YGKv7T2miw24ovqJJtPu2k9tQqrFIjbRIXBWvC8;
Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1OVW7L-00044a-IW; Sun, 04 Jul 2010 14:48:48 -0600
From: Richard Shockey <richard@shockey.us>
To: 'Peter Musgrave' <peter.musgrave@magorcorp.com>
References: <AANLkTintQWiM1BNi1Lz11i4AEUm4vnpFhHNRPRMs6ctG@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F40FB@307622ANEX5.global.avaya.com> <AANLkTinCs4ooaP7qczjOf_CMJB2tZg9XR9Ro5H-WWHK6@mail.gmail.com> <EDC652A26FB23C4EB6384A4584434A04022F4219@307622ANEX5.global.avaya.com> <001201cb1ade$4195f680$c4c1e380$@us> <AANLkTimGO9mf_q78EYJJ_UwuM834m3vJ0i4BiGqEB4KJ@mail.gmail.com>
In-Reply-To: <AANLkTimGO9mf_q78EYJJ_UwuM834m3vJ0i4BiGqEB4KJ@mail.gmail.com>
Subject: RE: [dispatch] VIPR - proposed charter version 3
Date: Sun, 04 Jul 2010 16:48:45 -0400
Message-ID: <009f01cb1bba$4c7bcd40$e57367c0$@us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CB1B98.C56A2D40"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acsa+YKSMZB7klnsTFyT3CbXkJPHXgAvFYfw
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us}
Cc: 'DISPATCH' <dispatch@ietf.org>, "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>, 'Mary Barnes' <mary.ietf.barnes@gmail.com>, 'IETF-Discussion list' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jul 2010 20:48:57 -0000
Well folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don't accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of doing so since there is no possible administrative chain of trust other than self assertion . Hence the possibility of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn't change that problem either. This has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in private trees BTW. Consequently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like. The fact that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. I do understand that many folks don't like their voice service providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not going to solve that. IMHO in the absence of any rational trust or security model you can certainly publish something as Informational but getting something past the IESG is another thing entirely. From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Saturday, July 03, 2010 5:49 PM To: Richard Shockey Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time. The mechanism in the ViPR drafts seemed to be able to accomplish the "finding the party responsible for a number" - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <richard@shockey.us> wrote: A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. "finding domains that claim to be responsible for a given phone number" This IMHO is flat out impossible. Validating or authenticating an entity that is "responsible for a phone number" is as bad as " who is the carrier of record" , is a massive rathole. Cullen and Johathan should know better. Certs? LNP ? We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 30, 2010 11:33 AM To: Mary Barnes Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. Dan > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Wednesday, June 30, 2010 6:24 PM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Hi Dan, > > The term peer to peer is intended to exclude mechanisms that > would use a central repository for the information: This was > discussed in an earlier thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > In one sense it is a solution, however, in another sense it > is reusing SIP related functionality defined in RAI and thus > is in a similar vein as specifying the use of SIP in a charter. > > Thanks, > Mary. > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > <dromasca@avaya.com> wrote: > >> The VIPR WG will address this problem by developing a peer to peer > >> based approach to finding domains that claim to be > responsible for a > >> given phone number and validation protocols to ensure a reasonable > >> likelihood that a given domain actually is responsible for > the phone > >> number. > > > > Hi, > > > > Clarification question. What exactly means 'peer to peer > based approach' > > and what kind of approaches are excluded by having this in > the charter. > > Does 'approach' mean solution? If so why does a specific type of > > solution need to be agreed in the charter, while all we > have at hand > > at this point are individual contribution I-Ds that describe the > > 'problem statement and some possible starting points for solutions'? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 8:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
- RE: [dispatch] VIPR - proposed charter version 3 Romascanu, Dan (Dan)
- RE: [dispatch] VIPR - proposed charter version 3 Romascanu, Dan (Dan)
- RE: [dispatch] VIPR - proposed charter version 3 Romascanu, Dan (Dan)
- RE: [dispatch] VIPR - proposed charter version 3 Roni Even
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- Re: [dispatch] VIPR - proposed charter version 3 Mary Barnes
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Marc Petit-Huguenin
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Adam Roach
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Paul Kyzivat
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Adam Roach
- RE: [dispatch] VIPR - Speaking of Video Calls .. Richard Shockey
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Peter Musgrave
- Re: [dispatch] VIPR - proposed charter version 3 Paul Kyzivat
- Re: [dispatch] VIPR - proposed charter version 3 Cullen Jennings
- RE: [dispatch] VIPR - proposed charter version 3 Dan Wing
- RE: [dispatch] VIPR - proposed charter version 3 Richard Shockey
- Re: [dispatch] VIPR - proposed charter version 3 Jonathan Rosenberg