Re: [sipcore] "Roman's problem"

worley@ariadne.com (Dale R. Worley) Fri, 18 March 2016 20:23 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F65B12D7AB for <sipcore@ietfa.amsl.com>; Fri, 18 Mar 2016 13:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.035
X-Spam-Level:
X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOljLzCkrcC2 for <sipcore@ietfa.amsl.com>; Fri, 18 Mar 2016 13:23:40 -0700 (PDT)
Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8CA12D586 for <sipcore@ietf.org>; Fri, 18 Mar 2016 13:23:40 -0700 (PDT)
Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-06v.sys.comcast.net with comcast id XYPg1s0045Geu2801YPg4r; Fri, 18 Mar 2016 20:23:40 +0000
Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-20v.sys.comcast.net with comcast id XYPf1s0021nMCLR01YPfaX; Fri, 18 Mar 2016 20:23:40 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2IKNcsa017039; Fri, 18 Mar 2016 16:23:38 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2IKNcOo017032; Fri, 18 Mar 2016 16:23:38 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Roman Shpount <roman@telurix.com>
In-Reply-To: <CAD5OKxvyYNZ+R+QP23LPPx6TNDiAaGZTeKarvBzYJ4LvC63wXg@mail.gmail.com> (roman@telurix.com)
Sender: worley@ariadne.com
Date: Fri, 18 Mar 2016 16:23:38 -0400
Message-ID: <871t777cxh.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458332620; bh=lDQ/nGF9AxNwrTk4ZP0/nrwFXLZSBR1GPrjRgzwUcGI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FWsQSrUMiC4zpjaG3ZO3fwTnCjkRouqWVNOnBfh8dmRHUXReWotQTVVg8TPJ+GFQg xuj1sN3mFAg/Wf4Y67aNr0e3Ikdw9d7cTpoWlEDRv3l6FSTsHclJbTaJwwlhErOsCJ EvHDpCPMQsFCdg11W0Y4nlTHVzs7OYaxBVhFfdEMbVOOM5PwPF6RHWPnRbKpWJCoKY G+bD+3rLCCEGXqjPR68Su3YjnPAJJFsqfkMhtSFLFbRk/u8YwokKbsoUIpyVuhcskW pJ6G0x8/3+jjGtQKvPt42lj7dQmNA5rLm6tw5zulYD9CqVvtetyk1hgjbe/2Nfc1Tr l4yMVLcerFlGQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/3pqSAS5rtmAGVCZwpzwcYJwCL1E>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] "Roman's problem"
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2016 20:23:42 -0000

Roman Shpount <roman@telurix.com> writes:
> This is definitely something that requires further investigation, but I
> think the right way to do this is to start with DTLS and see if it can be
> adapted or improved for connection fail-over scenario.

I agree that the things you've suggested for SIP/DTLS could be quite
useful.  And in my brief study of RFC 5246 I've spotted some items that
need to be addressed.

I looked at draft-jennings-sip-dtls-05, but it is very brief and does
not address any of the concerns.  I know that it did not progress to an
RFC, but I don't know why.  I wonder if we should organize an effort to
construct SIP/DTLS to be used in these situations (UA to edge proxy),
with identification of the requirements, usage scenarios, etc.

Dale