Re: [VIPR] An alternative to the VIPR ticket

Dean Willis <dean.willis@softarmor.com> Thu, 13 October 2011 22:23 UTC

Return-Path: <dean.willis@softarmor.com>
X-Original-To: vipr@ietfa.amsl.com
Delivered-To: vipr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890521F8B8F for <vipr@ietfa.amsl.com>; Thu, 13 Oct 2011 15:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.227
X-Spam-Level:
X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 hH-NumExkZf2 for <vipr@ietfa.amsl.com>; Thu, 13 Oct 2011 15:23:25 -0700 (PDT)
Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0450621F8B84 for <vipr@ietf.org>; Thu, 13 Oct 2011 15:23:24 -0700 (PDT)
Received: by yxn35 with SMTP id 35so125802yxn.38 for <vipr@ietf.org>; Thu, 13 Oct 2011 15:23:20 -0700 (PDT)
Received: by 10.150.244.20 with SMTP id r20mr6418581ybh.50.1318544600495; Thu, 13 Oct 2011 15:23:20 -0700 (PDT)
Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id m3sm3438121ang.0.2011.10.13.15.23.18 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 15:23:18 -0700 (PDT)
Message-ID: <4E9764D5.2020408@softarmor.com>
Date: Thu, 13 Oct 2011 17:23:17 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: vipr@ietf.org
References: <4E627AB4.7070806@acm.org> <4E961A6B.2090603@acm.org> <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz>
In-Reply-To: <5C4D5C85-A551-4E11-A5D6-FCC56C56A1B3@neustar.biz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [VIPR] An alternative to the VIPR ticket
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2011 22:23:25 -0000

On 10/13/11 12:25 PM, Peterson, Jon wrote:

> I furthermore suspect
> that TLS operations would not be optimal in this sort of model. Is
> the antispam property something that is best bound to the transport
> or to a single SIP request? The use cases, ultimately, answer that
> for us: consider two large ViPR domains that want to exchange traffic
> - should they have to establish a new TLS connection for each called
> number, or should they be able to send signaling for many calls over
> a single TLS connection? Are there cases where the hop-by-hop
> property of TLS weakens the utility of the mechanism? Are there
> environments we want ViPR to be useful where TLS is not available?

Perhaps the ViPR domain intermediaries shouldn't be cryptographically 
involved in TLS at all.

See: http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01


--
Dean