From nobody Tue Mar 1 08:23:34 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45A11B2E4F for ; Tue, 1 Mar 2016 08:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 G6mg6br4XuMp for ; Tue, 1 Mar 2016 08:23:33 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33721B2E58 for ; Tue, 1 Mar 2016 08:23:30 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with comcast id QgKi1s0012Udklx01gPWsJ; Tue, 01 Mar 2016 16:23:30 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id QgPV1s0091nMCLR01gPV6a; Tue, 01 Mar 2016 16:23:30 +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 u21GNSO8009909 for ; Tue, 1 Mar 2016 11:23:28 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u21GNSVp009906; Tue, 1 Mar 2016 11:23:28 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 01 Mar 2016 11:23:28 -0500 Message-ID: <87bn6ydv5r.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456849410; bh=i7uY8OXrAQwK63KB3387ET+t+goJuNMAv74kUX5TWcI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Ydj4BPLGH3ANqBCXm3FSvsVNQLAs7Q/n5fVU3mMURTk5ExS4XTddZKDdooVh9efm0 amMXCub4hRR1G3huWXdLtDJsybchFASaf4BgXAAHKUMb056R2KbqcOIWzgN/HfkUGp SBQ/OB7VVkKOQTbiIcPrda9ioNAMttCp5gqAsTMaK+HFjZb3+fce+v9tRVKkas2va3 FyiDsv3VmWT2t9+IDuaFZfO1+toGQLW/ipH+8hb4rZY2wFe8SQKkCATSObZwtmzLEH F9O0ykkXfk1JQh7a/gmELSG/5garwA0JMuoqWNBY0ucZoqZYOIA3Vi2OYyGn89/wMu Z9vzmlD3GBvpQ== Archived-At: Subject: [sipcore] Progressing draft-ietf-sipcore-dns-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:23:34 -0000 Since there seems to be no controversy, I'm planning on asking for a WGLC on 8 Mar 2016, which is two weeks after draft-ietf-sipcore-dns-dual-stack-04 was submitted. Alternatively, we could ask for time in Buenos Aires to discuss it. Opinions? Dale From nobody Tue Mar 1 08:32:12 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9141B2EAA for ; Tue, 1 Mar 2016 08:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 9eJAj8tS8yOi for ; Tue, 1 Mar 2016 08:32:04 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5208E1B2EA6 for ; Tue, 1 Mar 2016 08:31:59 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-02v.sys.comcast.net with comcast id QgX01s0012Ka2Q501gXy51; Tue, 01 Mar 2016 16:31:58 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id QgXx1s00T1nMCLR01gXyrn; Tue, 01 Mar 2016 16:31:58 +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 u21GVva4010367; Tue, 1 Mar 2016 11:31:57 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u21GVvoY010364; Tue, 1 Mar 2016 11:31:57 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <56D4ABF1.5060400@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 01 Mar 2016 11:31:56 -0500 Message-ID: <878u22durn.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456849918; bh=pIagNeYbOQblNFsikXUTB4DIIytxsmOf+7/Bcic0Oo8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=QAW75nJZ1VndRWL7lM1pDkMiN0PpX0H+ru6TX6B+/o50/scuBmWCFs1OSM+g2HmrQ O9IFBpBhpNA37DcpBCIl4f5AZ8Kv+DNhsx2ijtL2bR05w/4LaZqkxdxRDDw/2CHzd8 LRDA/+BIiObl9KlYWPM6u0rlXTx0oHCfSCaWoVvC0a6QSvCL7c/M29bKhiqCRYSYJO 213uHOqdw1VszGzGPDaaZ+AmLx5ufH6KvQQUagZVUZgYKwVR+5xn/ZjlwREhoCSTrD Lut6t1te8/cJyzmLRIY1lM7vv+9Y9LrRpKy0qAC6qN6vGKtfHMFGP9X5grlZW4ILsc S1QjdvuiH5Vlw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:32:11 -0000 Paul Kyzivat writes: > Why do we need to have a solution for UDP? My experience is that UDP is universal, so if there's a straightforward way to do it in UDP, it will make implementation much quicker. In the SIPit 31 report, I see: Implementations using each transport for SIP messages: UDP 100% TCP 86% TLS 81% (20% server-auth-only) SCTP 10% DTLS 5% Dale From nobody Tue Mar 1 08:39:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CF61B2EE3 for ; Tue, 1 Mar 2016 08:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 aFEenBGujM8Q for ; Tue, 1 Mar 2016 08:39:12 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE89E1B2EE2 for ; Tue, 1 Mar 2016 08:39:12 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-09v.sys.comcast.net with comcast id QgbU1s0062XD5SV01gfBNQ; Tue, 01 Mar 2016 16:39:11 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id QgfA1s00L1nMCLR01gfBsc; Tue, 01 Mar 2016 16:39:11 +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 u21GdAa3010756; Tue, 1 Mar 2016 11:39:10 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u21Gd9S1010753; Tue, 1 Mar 2016 11:39:09 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 01 Mar 2016 11:39:09 -0500 Message-ID: <8760x6dufm.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456850351; bh=UvhCwWmdzgUdCo9XZBORRGRZawYwXzTb+m2E+Au55RM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=lTaUtPACy0hz3YCKmcmOQj7PgRe9Inop3CepQtLvQlN7sW9m0uCFujKUxdNXldSkI 326ubpiRJ2apt5rfDcEhoE85wrNgF/sC8da4cNMpFJet13UzHjDhOl1tNixWI3q9b0 IDGKk4qWT8z2AvgafV6SKnKhkOcfzyLKGLEM2kFGD+A831i/mqK/yZTHXknqPCQY4W 0sAyT3oS/ExFDGDLunO7+iD+r3M5OURmWU7UdiaxW6oVbJDtjO+7i+uhR4c5CUmHTf xe59ysMiZHRmXu6nBmxHO6opVPdS8sCycyaJG1DBdUkhysa6MfCRnN0AYbWeDuHCBI lWabeBlSQyRvQ== Archived-At: Cc: sipcore@ietf.org, oej@edvina.net Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:39:14 -0000 "Olle E. Johansson" writes: >> C. Two or more addresses may be contacted simultaneously rather than >> sequentially if provisions are made to avoid merged requests: > > Again, this only applies to UDP. I don't see this as limited to UDP. If Happy Eyeballs processing decides to race two TCP connections to their targets (typically one IPv4 and one IPv6), ideally we don't want to have to wait a complete RTT before a the request can be sent. Better to send the request along with the SYN packet on one connection, so if we don't have to fail over to the other connection, we don't lose an RTT. > The migration to IPv6 needs to be easy, and asking for dual simultaneous > connections over TCP/TLS is big enough for many implementations. Implementing > a whole new proxy merge scheme in the same document will in my view make it as > ignored as SIP outbound currently is I see the merge scheme as being *much easier* to implement than Outbound, and probably simpler than dual simultaneous connections in TCP. > b) recommending server side DNS SRV separation, one prio per address family, > no dual stack hosts for UDP If you use SRV to prioritize address families, then don't hosts that can't access the destination with its preferred address family pay an RTT penalty? Or actually, a connection-timeout penalty? Dale From nobody Tue Mar 1 08:55:56 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8632E1B2F31 for ; Tue, 1 Mar 2016 08:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 nybB5frr7nWO for ; Tue, 1 Mar 2016 08:55:53 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414DB1B2FD6 for ; Tue, 1 Mar 2016 08:54:42 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-01v.sys.comcast.net with comcast id Qgrg1s0054xDoy801guh8R; Tue, 01 Mar 2016 16:54:41 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-05v.sys.comcast.net with comcast id Qgug1s00T1nMCLR01guhP6; Tue, 01 Mar 2016 16:54:41 +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 u21GseQK011570 for ; Tue, 1 Mar 2016 11:54:40 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u21GsdPm011567; Tue, 1 Mar 2016 11:54:39 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-Reply-To: <56D0D2B8.9090009@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 01 Mar 2016 11:54:39 -0500 Message-ID: <8737sadtps.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456851281; bh=6utro1sRtpF0XHHr+O4f7VBAzMIvHlu9+NHCc+2ppdk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=nmME3Sv0JJnPbx7yl1H3XHzgOyZ7uKFyKnxu1rLCHpt7JrCTaGq2K/kGlcxXkeul0 BdEyzFU1cPojDMcqtvUg90xbb0ujjm+eXjdhGYb7LHjkkb3r3uPYSJjnjrNjUjzWr8 wYoUqbis6VhsGevDX7COCixALwzh0ELudbj9U/z9RfOAKgRbemYy0+cbtUclmk05o2 7SdHDY5VV31zlCEA3zzKkexmfdVtwZ7LzNYCF13gD72l3gdmOkpZUcpSRoeV87PtzU hNYHgvQKPRPNbJArlmV5FskHc49x0ScNG8EOu4XrYlUd8LAHv9oAn0K8G0bVhgEeOa JzjBWJmcvtT9Q== Archived-At: Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:55:54 -0000 Paul Kyzivat writes: > I only skimmed this, but ISTM that the use of proxy-require with a new > option will make this nearly undeployable. Let me explain the proposal more clearly. The critical point is that it is an *upward-compatible* way of sending simultaneous requests while eliminating merged requests. This is important for supporting Happy Eyeballs with minimal delays to destinations that a device does not maintain flows with. Assume the device is sending this request that it received: INVITE sip:biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 20 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: To the "first" target, 10.5.0.10, it sends this request, with particular modifications to support merged requests: INVITE sip:biloxi.example.com SIP/2.0 Route: ;group=2 ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.1;group ------------------------------------------------------^^^^^^ Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: The "group" parameter in the Route header indicates that this request is part of a group. The value of the group parameter indicates two successive Via headers. The branch parameter of the Via header indexed by that value (counting from the bottom, starting with 1) indicates the identity of this request within the group. The branch parameter of the next Via header down indicates the identity of the group. If the target does not understand the group extension, it simply ignores all these parameters. In either case, the target deletes the Route header before forwarding the request. Simultaneously, to the "second" target, fd5a::0101, it sends this request: INVITE sip:biloxi.example.com SIP/2.0 Proxy-Require: group ----^^^^^^^^^^^^^^^^^^^^ Route: ;group=2 ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group ---------------------------------------------------------^^^^^^ Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: This request is similar to the previous one, but it had a unique branch parameter and includes "Proxy-Require: group". If the second target (which is presumably the same devide as the first target) does not implement the group extension, it rejects this request with a 420 error. The sending device will then postpone using this target unless and until the request to the first target fails, at which time it will send a request like the request to the first target, or a request which does not use the group extension. If the second target *does* implement the group extension, it understands that the two requests are "equivalent", in that processing either one has "equivalent effect" (from the user's point of view), and that it should accept and process one of them and reject the other with an error (495 Grouping). Detecting whether or not another request has already been processed is straightforward because it can search for an ongoing transaction whose *second* branch parameter is the same as the second branch parameter of this request. If the second target processes this request, it deletes the the Route header and the Proxy-Require header (per the specification of the "group" extension) before forwarding the request. This scheme has the advantage of minimizing the amount of state that the devices need to maintain, which makes implementation much easier than, say, SIP Outbound. Dale From nobody Tue Mar 1 09:27:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66911B3033 for ; Tue, 1 Mar 2016 09:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 fQnSp7OsEIja for ; Tue, 1 Mar 2016 09:27:15 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B771B303F for ; Tue, 1 Mar 2016 09:27:14 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-02v.sys.comcast.net with comcast id QhTD1s0062PT3Qt01hTDUV; Tue, 01 Mar 2016 17:27:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-14v.sys.comcast.net with comcast id QhTD1s00E3KdFy101hTDDC; Tue, 01 Mar 2016 17:27:13 +0000 To: "Dale R. Worley" References: <878u22durn.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56D5D0F0.6060403@alum.mit.edu> Date: Tue, 1 Mar 2016 12:27:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <878u22durn.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456853233; bh=FjtzqZj/Ww2kNjClUX29M7XePrQID0JXQGOrrDpYz+c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=DpndCsyu/C3bNxHXpEbuDcobXhCVy0eFFLhzZyfCfXPZlR2uIAHA5FBKqn6C+Q/K7 IlbNI9RwHYISZtBweu9xHAcirgVmyHm6L+8yd7zjadJvTDyJ/c/igLtob/huHAy0sB vB5iNGDYD5bNMIb8dG1LsmHYRrvPsVch0delA/hgLqJG3JY7kGJnIS4DViW4V5sUYM VANrvjnKlK11+wXDn3tAYqP4ZEfWtUrD3+RP6ciAN7NPoY2iI26JoqC+tL1CM+pYQ2 HXDS1KlZNBUBd8f3QaxdC30hPzkIaZamvvNKbKnIbF3R2cJ7Khq+ibE25U8d9Wx9Kb l2exyn8ueeklw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:27:16 -0000 On 3/1/16 11:31 AM, Dale R. Worley wrote: > Paul Kyzivat writes: >> Why do we need to have a solution for UDP? > > My experience is that UDP is universal, so if there's a straightforward > way to do it in UDP, it will make implementation much quicker. > > In the SIPit 31 report, I see: > > Implementations using each transport for SIP messages: > UDP 100% > TCP 86% > TLS 81% (20% server-auth-only) > SCTP 10% > DTLS 5% The TCP and TLS numbers are now getting pretty big. Of course UPD is 100%, since almost everybody has code in for backward compatibility. Won't the TCP numbers get more favorable if we focus on applications that also support IPv6 and then also require implementation of a new Via parameter? Wouldn't those who are doing that much new development also just bite the bullet and use TCP, thus avoiding the need for the new Via parameter? Thanks, Paul From nobody Tue Mar 1 09:35:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2511B3055 for ; Tue, 1 Mar 2016 09:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 PZH3sJIAY_AB for ; Tue, 1 Mar 2016 09:35:39 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B181D1B3041 for ; Tue, 1 Mar 2016 09:35:34 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-01v.sys.comcast.net with comcast id Qhb01s00329Cfhx01hbZ6E; Tue, 01 Mar 2016 17:35:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id QhbZ1s00M3KdFy101hbZE9; Tue, 01 Mar 2016 17:35:33 +0000 To: sipcore@ietf.org References: <8737sadtps.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56D5D2E4.7010808@alum.mit.edu> Date: Tue, 1 Mar 2016 12:35:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <8737sadtps.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456853733; bh=WaV1O9ah843CkzvgVebWcxURFJdeHdaGaVoGjnC6oJo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=eKNTr2Gf8F6C/kvR52hl/9dHEjuUmlDkH+c3RaUyz2bo2cz/NNk/zBFnCnKyRfR27 6OECRnoGERfA5rezMg8zLoZO2A7JmyKd/PuB8htYzOQ1ZNLDyj+bYz/28w3lpYsUAH HpcI4nAfZxgHfyjYMXtLGRPNAspX7Tmqq1ww6nz8zWljsoE57i0ZyYZhk4RtZPcMcD fJq5BEXSXZGHb1zHRGIN7Uak1uF7jZ+Ek4WHgVtePYLm0ewep1d7ZMtte+823t6OqI ajBNS06laNjh84kc4nAmYPuI0d0plHvQ63uayabZypLitfsDGOAvn8t+BgNNEsi4W7 oAgyBInBxaUdA== Archived-At: Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:35:40 -0000 Comment at end. On 3/1/16 11:54 AM, Dale R. Worley wrote: > Paul Kyzivat writes: >> I only skimmed this, but ISTM that the use of proxy-require with a new >> option will make this nearly undeployable. > > Let me explain the proposal more clearly. The critical point is that it > is an *upward-compatible* way of sending simultaneous requests while > eliminating merged requests. This is important for supporting Happy > Eyeballs with minimal delays to destinations that a device does not > maintain flows with. > > Assume the device is sending this request that it received: > > INVITE sip:biloxi.example.com SIP/2.0 > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 20 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > To the "first" target, 10.5.0.10, it sends this request, with particular > modifications to support merged requests: > > INVITE sip:biloxi.example.com SIP/2.0 > Route: ;group=2 > ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.1;group > ------------------------------------------------------^^^^^^ > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > The "group" parameter in the Route header indicates that this request is > part of a group. The value of the group parameter indicates two > successive Via headers. The branch parameter of the Via header indexed > by that value (counting from the bottom, starting with 1) indicates the > identity of this request within the group. The branch parameter of the > next Via header down indicates the identity of the group. > > If the target does not understand the group extension, it simply ignores > all these parameters. > > In either case, the target deletes the Route header before forwarding > the request. > > Simultaneously, to the "second" target, fd5a::0101, it sends this request: > > INVITE sip:biloxi.example.com SIP/2.0 > Proxy-Require: group > ----^^^^^^^^^^^^^^^^^^^^ > Route: ;group=2 > ----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group > ---------------------------------------------------------^^^^^^ > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > This request is similar to the previous one, but it had a unique branch > parameter and includes "Proxy-Require: group". > > If the second target (which is presumably the same devide as the first > target) does not implement the group extension, it rejects this request > with a 420 error. The sending device will then postpone using this > target unless and until the request to the first target fails, at which > time it will send a request like the request to the first target, or a > request which does not use the group extension. > > If the second target *does* implement the group extension, it > understands that the two requests are "equivalent", in that processing > either one has "equivalent effect" (from the user's point of view), and > that it should accept and process one of them and reject the other with > an error (495 Grouping). Detecting whether or not another request has > already been processed is straightforward because it can search for an > ongoing transaction whose *second* branch parameter is the same as the > second branch parameter of this request. > > If the second target processes this request, it deletes the the Route > header and the Proxy-Require header (per the specification of the > "group" extension) before forwarding the request. > > This scheme has the advantage of minimizing the amount of state that the > devices need to maintain, which makes implementation much easier than, > say, SIP Outbound. My concern is that *every* proxy on the path needs to support the 'group' option for the second message to be successful. Not just the the one nearest the target. That makes it a high bar. Otherwise what you describe does seem quite clever. Thanks, Paul From nobody Tue Mar 1 10:41:16 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32641B37DB for ; Tue, 1 Mar 2016 10:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 dTT1baZjjqYz for ; Tue, 1 Mar 2016 10:41:12 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FAD1B2E2F for ; Tue, 1 Mar 2016 10:41:12 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u21If1lN093466 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Mar 2016 12:41:01 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Dale R. Worley" , sipcore@ietf.org References: <87bn6ydv5r.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <56D5E23C.7040200@nostrum.com> Date: Tue, 1 Mar 2016 12:41:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87bn6ydv5r.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Progressing draft-ietf-sipcore-dns-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:41:14 -0000 On 3/1/16 10:23, Dale R. Worley wrote: > Since there seems to be no controversy, I'm planning on asking for a > WGLC on 8 Mar 2016, which is two weeks after > draft-ietf-sipcore-dns-dual-stack-04 was submitted. > > Alternatively, we could ask for time in Buenos Aires to discuss it. > [as chair] I think what I'd like to do is a little of both. This is a relatively important issue, and we've requested time for it in Buenos Aires just to make sure that it gets the attention that it deserves. At the same time, we'd like to see it move forward with all due speed. So I propose that we call for a three-week WGLC, starting on March 21st, and running through the Friday of the IETF meeting (April 8th). If no substantial issues are raised on-list or at the meeting, then this gives us a clear signal that the document is ready to request publication. It also ensures that we have one final face-to-face meeting to hash out any potential issues or concerns. Sound good? /a From nobody Tue Mar 1 21:03:10 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134531B4878 for ; Tue, 1 Mar 2016 21:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8hs2zO2Fa0ul for ; Tue, 1 Mar 2016 21:03:07 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767901B487C for ; Tue, 1 Mar 2016 21:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1782; q=dns/txt; s=iport; t=1456894987; x=1458104587; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tQYvNy5A+WItDYuPoPoiX/nv+zFTdyyDeUnrkcyvUJU=; b=UH3SvNDMZB/S8Uq55vAjspewFGMuzK7r76nW36cdEdJAKMm8ZuwhaZdc 8HwWBEywQjrBQHq5vblnx8XltJp0DR4PAHe4k+4c4aCdmUStaGdQyNjML BhM3gmlPHV/Vcw0CqQosa72h/ahmX3E3rHPX7ExIUXq+aRQVgO8L6R+u5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCTc9ZW/4sNJK1cgzpSbQa6LQENg?= =?us-ascii?q?WYXCoUoSgIcgTI4FAEBAQEBAQFkJ4RBAQEBAwEBAQEaBhE6CwULAgEIGAICJgI?= =?us-ascii?q?CAiULFRACBA4FiBcIDq55jxMBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHuFF4FsC?= =?us-ascii?q?IJGhzUrgQ8FhVCRPwGLLII2jnaOSwEeAQFCggIagUhqh0N+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,526,1449532800"; d="scan'208";a="76770235" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2016 05:02:53 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2252rvV009924 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 05:02:53 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 23:02:52 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 23:02:52 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Adam Roach Thread-Topic: [sipcore] Progressing draft-ietf-sipcore-dns-dual-stack Thread-Index: AQHRc9a6slaEmRW7zkqcgLFBim9BeJ9FULQAgACtwgA= Date: Wed, 2 Mar 2016 05:02:52 +0000 Message-ID: <47F3485A-2360-45E4-818E-0194063CE90C@cisco.com> References: <87bn6ydv5r.fsf@hobgoblin.ariadne.com> <56D5E23C.7040200@nostrum.com> In-Reply-To: <56D5E23C.7040200@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.45.71] Content-Type: text/plain; charset="utf-8" Content-ID: <6D2CC0B6BB6FF0419F581A092AD8C992@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Dale R. Worley" , SIPCORE Subject: Re: [sipcore] Progressing draft-ietf-sipcore-dns-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 05:03:09 -0000 DQo+IE9uIE1hciAxLCAyMDE2LCBhdCAxOjQxIFBNLCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0u Y29tPiB3cm90ZToNCj4gDQo+IE9uIDMvMS8xNiAxMDoyMywgRGFsZSBSLiBXb3JsZXkgd3JvdGU6 DQo+PiBTaW5jZSB0aGVyZSBzZWVtcyB0byBiZSBubyBjb250cm92ZXJzeSwgSSdtIHBsYW5uaW5n IG9uIGFza2luZyBmb3IgYQ0KPj4gV0dMQyBvbiA4IE1hciAyMDE2LCB3aGljaCBpcyB0d28gd2Vl a3MgYWZ0ZXINCj4+IGRyYWZ0LWlldGYtc2lwY29yZS1kbnMtZHVhbC1zdGFjay0wNCB3YXMgc3Vi bWl0dGVkLg0KPj4gDQo+PiBBbHRlcm5hdGl2ZWx5LCB3ZSBjb3VsZCBhc2sgZm9yIHRpbWUgaW4g QnVlbm9zIEFpcmVzIHRvIGRpc2N1c3MgaXQuDQo+PiANCj4gDQo+IFthcyBjaGFpcl0NCj4gDQo+ IEkgdGhpbmsgd2hhdCBJJ2QgbGlrZSB0byBkbyBpcyBhIGxpdHRsZSBvZiBib3RoLg0KPiANCj4g VGhpcyBpcyBhIHJlbGF0aXZlbHkgaW1wb3J0YW50IGlzc3VlLCBhbmQgd2UndmUgcmVxdWVzdGVk IHRpbWUgZm9yIGl0IGluIEJ1ZW5vcyBBaXJlcyBqdXN0IHRvIG1ha2Ugc3VyZSB0aGF0IGl0IGdl dHMgdGhlIGF0dGVudGlvbiB0aGF0IGl0IGRlc2VydmVzLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZSdk IGxpa2UgdG8gc2VlIGl0IG1vdmUgZm9yd2FyZCB3aXRoIGFsbCBkdWUgc3BlZWQuIFNvIEkgcHJv cG9zZSB0aGF0IHdlIGNhbGwgZm9yIGEgdGhyZWUtd2VlayBXR0xDLCBzdGFydGluZyBvbiBNYXJj aCAyMXN0LCBhbmQgcnVubmluZyB0aHJvdWdoIHRoZSBGcmlkYXkgb2YgdGhlIElFVEYgbWVldGlu ZyAoQXByaWwgOHRoKS4NCj4gDQo+IElmIG5vIHN1YnN0YW50aWFsIGlzc3VlcyBhcmUgcmFpc2Vk IG9uLWxpc3Qgb3IgYXQgdGhlIG1lZXRpbmcsIHRoZW4gdGhpcyBnaXZlcyB1cyBhIGNsZWFyIHNp Z25hbCB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byByZXF1ZXN0IHB1YmxpY2F0aW9uLiBJ dCBhbHNvIGVuc3VyZXMgdGhhdCB3ZSBoYXZlIG9uZSBmaW5hbCBmYWNlLXRvLWZhY2UgbWVldGlu ZyB0byBoYXNoIG91dCBhbnkgcG90ZW50aWFsIGlzc3VlcyBvciBjb25jZXJucy4NCj4gDQo+IFNv dW5kIGdvb2Q/DQoNCknigJltIGdvb2Qgd2l0aCB0aGF0IGFwcHJvYWNoLg0KDQotR29uemFsbw0K DQo+IA0KPiAvYQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K From nobody Wed Mar 2 07:41:30 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906A51A89A0 for ; Wed, 2 Mar 2016 07:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 LQVRikAiDZAs for ; Wed, 2 Mar 2016 07:41:28 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFEB1A899D for ; Wed, 2 Mar 2016 07:41:28 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with comcast id R3gl1s0012N9P4d013hTgx; Wed, 02 Mar 2016 15:41:27 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id R3hS1s00L1nMCLR013hTiF; Wed, 02 Mar 2016 15:41:27 +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 u22FfQiY023016; Wed, 2 Mar 2016 10:41:26 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u22FfPk5023013; Wed, 2 Mar 2016 10:41:25 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: <56D5E23C.7040200@nostrum.com> (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 02 Mar 2016 10:41:25 -0500 Message-ID: <87bn6wdh0a.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456933287; bh=CuwWTt5u8azHYFPiP+wFUA252qvlsmSBEJJ5ajtDRnE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=L3SkicVc69jyvu6DqfwIODKaa0YxF7Yu5BppdUdzW9+iQS8D2VDiQ14TT+JhrfvdN VN0YzUNEMqq+xninTzIP2KWqAkisREdsdai8wfj5FyFAf50A8Cp/7QYGQTnEXlzLuj 0jtZAz5XWQf/0m0owNaG4M+B57xf56wKeLoPWWpdnml4Re27Z2UsDXu6fAmIhk48V/ /auA8/kH/zoBv0sVohpwyM1iv/Bjymx7L9Eh9GEc6pSjQ9oVFOncl7q2EO2mF+MYXU 5EgmViuDtXrJPch/4y/PkHqzs1zX7HWh/9005yZzVvjuytkHd3esWzVhDKNEgXoHRv eF66hERTrU5PQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Progressing draft-ietf-sipcore-dns-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 15:41:29 -0000 Adam Roach writes: > I think what I'd like to do is a little of both. > > This is a relatively important issue, and we've requested time for it in > Buenos Aires just to make sure that it gets the attention that it > deserves. At the same time, we'd like to see it move forward with all > due speed. So I propose that we call for a three-week WGLC, starting on > March 21st, and running through the Friday of the IETF meeting (April 8th). > > If no substantial issues are raised on-list or at the meeting, then this > gives us a clear signal that the document is ready to request > publication. It also ensures that we have one final face-to-face meeting > to hash out any potential issues or concerns. > > Sound good? Make sense to me. Dale From nobody Wed Mar 2 11:22:20 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0D1B2DD2 for ; Wed, 2 Mar 2016 11:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 K820b6RFVB5L for ; Wed, 2 Mar 2016 11:22:16 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8C81B2D88 for ; Wed, 2 Mar 2016 11:22:16 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-03v.sys.comcast.net with comcast id R7Mw1s00753iAfU017NDz9; Wed, 02 Mar 2016 19:22:13 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-10v.sys.comcast.net with comcast id R7NC1s00E1nMCLR017NDG4; Wed, 02 Mar 2016 19:22:13 +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 u22JMCiQ002656; Wed, 2 Mar 2016 14:22:12 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u22JMB32002653; Wed, 2 Mar 2016 14:22:11 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <56D5D2E4.7010808@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 02 Mar 2016 14:22:11 -0500 Message-ID: <87io14bs7w.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456946533; bh=1dpfM76HwrjUfLzMyXz50BS6Y2pUxZYwBHSgHtK7aKk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=D1LodOZYwNEPhoGuB4otu5F8lcJjbDqbQoEpNYURrHYMpFNHRvT+J32urytPZmrYN o8KcyKS9GAT+39tALS0fV4KgsNcFfrQaSLrkvvtTqIZwTRhrnuCw7qf2OLgfF7/m3T QNyqXYFe4dKjC2Mq8BkSqI8mSwVmZ5rHDtxg9Rzgj5vZbbdEqfUBNsnOewQnfMayRp UX6Keq7NogYqoOAe3OXvRx7pq4q6fCXA94Og+SJrm2ezEubPhNuMJ4+r/PiStPZ9tD 8ItEoTTG+uM+jzgW7qytoOENmnJhT4PYiBFLLVCxn6kIlOND+bufo4UFJnHMEKuh24 sQe6r1vP+s6Kg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:22:17 -0000 Paul Kyzivat writes: > My concern is that *every* proxy on the path needs to support the > 'group' option for the second message to be successful. Not just the the > one nearest the target. That makes it a high bar. I believe that is not the case. The Proxy-Require is inserted by the sending device that we are describing, but it is *removed* by the receiving device at the end of the hop. At least, that's what I intended to say: > If the second target processes this request, it deletes the the Route > header and the Proxy-Require header (per the specification of the > "group" extension) before forwarding the request. Am I overlooking something? BTW, there's an error in my message: > Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group When IPv6 addresses appear as the transport address in a Via header, they do *not* appear inside [...]. [...] is only added when the IPv6 address appears as part of a SIP URI. Dale From nobody Wed Mar 2 11:42:11 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6501B2E1A for ; Wed, 2 Mar 2016 11:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 vfTcUXXtYFDI for ; Wed, 2 Mar 2016 11:42:01 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7E21B2E12 for ; Wed, 2 Mar 2016 11:42:01 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-01v.sys.comcast.net with comcast id R7ho1s0022AWL2D017i0Ts; Wed, 02 Mar 2016 19:42:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with comcast id R7i01s0073KdFy1017i01t; Wed, 02 Mar 2016 19:42:00 +0000 To: "Dale R. Worley" References: <87io14bs7w.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56D74206.6010804@alum.mit.edu> Date: Wed, 2 Mar 2016 14:41:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <87io14bs7w.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456947720; bh=qDr5SQBmXsuNInjSZ8BSNZvSg6YbAjQXP70G00ZW9no=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=H7ZZcXQvsIaY6bJxWobN6fnJEvzyU3fsic5sGmYaWitgbGCIjYEADHoWVgMt03ado Y4HGTjaYAqTy60A+NB0xi0Q2IF4NV9Z36kw8B1RSKw0X1qPL1VeQp1HZ0MVMFpe2Kh Xp9pFz/R+BLXLPhOwABl15Wnb8lvIRJI/t9mM2tvBfOPlfQgGY8yXzCjGYgZihClFH vX30ge8sDBt2gOeF4QcLv7oP/r3q2+wyrCpgCCTxVfldm60IQacYJhB/B+09qLGgyZ cSU8jNWO85/vh2mjF3PHODJFphinUrYls6S+puYyPXzikRm+WSB3rrjXZOAhwRuoUR uwKLzfRFwqYVQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:42:02 -0000 On 3/2/16 2:22 PM, Dale R. Worley wrote: > Paul Kyzivat writes: >> My concern is that *every* proxy on the path needs to support the >> 'group' option for the second message to be successful. Not just the the >> one nearest the target. That makes it a high bar. > > I believe that is not the case. The Proxy-Require is inserted by the > sending device that we are describing, but it is *removed* by the > receiving device at the end of the hop. At least, that's what I > intended to say: > >> If the second target processes this request, it deletes the the Route >> header and the Proxy-Require header (per the specification of the >> "group" extension) before forwarding the request. > > Am I overlooking something? This assumes that the proxy that needs to do the merging is the next hop. Why is that the case? Couldn't there be intermediate proxies? If that isn't a concern then I am less concerned. Thanks, Paul > BTW, there's an error in my message: > >> Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group > > When IPv6 addresses appear as the transport address in a Via header, > they do *not* appear inside [...]. [...] is only added when the IPv6 > address appears as part of a SIP URI. > > Dale > From nobody Wed Mar 2 11:58:18 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28D31B2E5A for ; Wed, 2 Mar 2016 11:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=no 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 nI8M6uHIp7q9 for ; Wed, 2 Mar 2016 11:58:15 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DB41B2E53 for ; Wed, 2 Mar 2016 11:58:15 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id p65so4313012wmp.0 for ; Wed, 02 Mar 2016 11:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=A5mGFBpTMDViS4DSr3kmmL1D5fCnNSNpzdgsA0SOBeo=; b=z8OO+G97RNsuHH9k0bYoWBCXB5dunFSC78g0kgpZfPkeXA+WcLl+l2GiV2SP7XdN06 TZJhWVJkeVTZULnjOF7/Yb3tFezFTYYeMUW9M5E7vryr2Kh0c6WCGFEKGmKgjQ6J0VE8 vtGS9y5SL0XjCDktPZq/7naTodavTvAVEZ8K7LYaQnBXInQdsb3kxdtWU5fptg/mWy8k EwnQ5JofsRrpwIyvGrekZjTyf2Xtdus70yfTlL9qE1ZESiMh2CBM3qvnXOACJcq31yhm qSdrm+yv2Fe94ZD479DJif8AIv3HKGmwPccN6RKxBzSEZllwVw+9zXhG7IPDqdGZc0DF 81rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=A5mGFBpTMDViS4DSr3kmmL1D5fCnNSNpzdgsA0SOBeo=; b=XaoFaff7oOFqRXPC1j/uceCOYm25B5w0fN9MpH3Vs1EaWQAv1zW6j3xUFAApd9Yiuf 8DS+XCH45Tp/bo5g6p3JPZk7y21qn3UefBx9KQ/hnHhoy/9ltB+3pqO3rB7JdoNoUr9U 6XNSezc6yF+AM6RwvTR+GpYHjML/HwgN7tRora8YvBmf1LPKM/MwIIRGs1v7OE4cVaXl zwtM9OXXC1+jjycNPsShcP/rRe3fJOdNEC2ZKiJDi0nNdqzme9N6Dtpnd3LDiWLBrwGc OVkYoYiERHwc5ZSUd5RKq59Dn8Zw47l0aIcrUDDLkya1TvMzvrHD4iTt6KSkJiBmNCJh hTaA== X-Gm-Message-State: AD7BkJLh21QLCo4nuYPh7s8WT8tyBELA7vqQzJhHV9r9AMScO+mdDE7b96EI3156o5j1DHapzk5TZtAa9T3aj1SS X-Received: by 10.28.128.86 with SMTP id b83mr1850604wmd.27.1456948694037; Wed, 02 Mar 2016 11:58:14 -0800 (PST) From: Brett Tate References: <56D5D2E4.7010808@alum.mit.edu> (pkyzivat@alum.mit.edu) <87io14bs7w.fsf@hobgoblin.ariadne.com> In-Reply-To: <87io14bs7w.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGVj4As7QpdIjxJHHG6cIZsB3aNH5++WKFA Date: Wed, 2 Mar 2016 14:58:13 -0500 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 19:58:16 -0000 Hi, > BTW, there's an error in my message: > > > Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group > > When IPv6 addresses appear as the transport address in > a Via header, they do *not* appear inside [...]. > [...] is only added when the IPv6 address appears as > part of a SIP URI. Using the brackets within Via's sent-by is correct; however the brackets would not be added as part of Via's received parameter value. The following ABNF is from RFC 3261 (some aspects were changed by RFC 5954). Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-received = "received" EQUAL (IPv4address / IPv6address) sent-by = host [ COLON port ] host = hostname / IPv4address / IPv6reference IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ ":" IPv4address ] From nobody Wed Mar 2 12:31:22 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2F1B2F9F for ; Wed, 2 Mar 2016 12:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 COrCIHCS6qAd for ; Wed, 2 Mar 2016 12:31:18 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BC01B2F9E for ; Wed, 2 Mar 2016 12:31:18 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-08v.sys.comcast.net with comcast id R8X71s0014yXVJQ018XHZV; Wed, 02 Mar 2016 20:31:17 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-06v.sys.comcast.net with comcast id R8XG1s00G1nMCLR018XHrc; Wed, 02 Mar 2016 20:31:17 +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 u22KVGnB006362 for ; Wed, 2 Mar 2016 15:31:16 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u22KVGxt006359; Wed, 2 Mar 2016 15:31:16 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 02 Mar 2016 15:31:15 -0500 Message-ID: <874mcobp0s.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456950677; bh=DcGiSBWnzuE80YdUoz5xhVuz+fZAUsJLWC3k4cj30Vg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GEEa5gXeZCE4mp26f5XQwJ7whm91q+MTjApjc2bhiheEbY2ZSBFISIdjIVy6gFNge PumEvwZNbcxupzOBtwm0eVVLqjmzjh/CJUnJrU02yrMDAbxs6kY8Vvc98fbNneTFpk ndt4BZ0L+HHPSN6A13oEBXnbFyTPylnFgCi60zySdi9dF0cdbb1gVf+L/NoLLysTID NYxRHeggnf3fTWYBdDj35lIYCEVI1r7VpVHvIn+i9rRcfNRDwW+1/ReyFjuFQjh5Fv 7r4WV6nwBkCDkiFWrNiHlCVv2Bh8/lX0RUu4fzPYW6JvAAOx5BrALPZjcI08KlWj+8 LVpggJQUfROag== Archived-At: Subject: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:31:20 -0000 Happy Eyeballs has a mess of issues surrounding UDP. Of course, the most desirable SIP transport is a TCP/TLS connection (or a SIP Outbound UDP flow) that is already established with the destination. That allows the message to be transmitted in 1/2 RTT in the common case, and the success of that particular transport is largely assured. But it requires that the sender has recently communicated with the destination. In general, UDP is undesirable. OTOH, it is the most implemented transport for SIP and its implementation is relatively simple. Even in 2014, 15% of the SIP implementations at SIPit do not support TCP. UDP has the advantage of usually getting a message to its destination in 1/2 RTT, even if the sender has not previously communicated with the destination. Typically, TCP implementations have 3/2 RTT transmission time, since data is not sent in the first packet from the initiator. TCP Fast Open (RFC 7413) can be used to shorten that time to 1/2 RTT, but it requires that the sender has recently communicated with the destination. Using TLS in a new connection adds a further RTT to TCP transmission times. Then again, perhaps we do not care if the message is delayed by an additional RTT. RFC 6555, which is really about the HTTP server case, assumes that 3/2 RTT is acceptable. OTOH, HTTP service already has to tolerate 3/2 RTT. With UDP and TCP Fast Open, if transmission time is important, it would be useful to be able to simultaneously transmit duplicate requests -- "Simultaneously" in the sense that a second request is sent before the failure of a first request is known, and "duplicate" in the sense that the success of either request obtains the desired service. In order to support this, there needs to be a way to detect and eliminate duplicate requests at some downstream point. BTW, looking at RFC 6555 section 4, I see: 4. Algorithm Requirements A "Happy Eyeballs" algorithm has two primary goals: 1. Provides fast connection for users, by quickly attempting to connect using IPv6 and (if that connection attempt is not quickly successful) to connect using IPv4. [...] The basic idea is depicted in the following diagram: DNS Server Client Server | | | 1. |<--www.example.com A?-----| | 2. |<--www.example.com AAAA?--| | 3. |---192.0.2.1------------->| | 4. |---2001:db8::1----------->| | 5. | | | 6. | |==TCP SYN, IPv6===>X | 7. | |--TCP SYN, IPv4------->| 8. | |<-TCP SYN+ACK, IPv4----| 9. | |--TCP ACK, IPv4------->| 10. | |==TCP SYN, IPv6===>X | Figure 2: Happy Eyeballs Flow 1, IPv6 Broken In the diagram above, the client sends two TCP SYNs at the same time over IPv6 (6) and IPv4 (7). In the diagram, the IPv6 path is broken but has little impact to the user because there is no long delay before using IPv4. [...] Am I misunderstanding this? Item (1) says that there is a delay between initiating an IPv6 connection and initiating an IPv4 connection, but the text at the end says that they are initiated simultaneously. Dale From nobody Wed Mar 2 13:30:59 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B51A88D1 for ; Wed, 2 Mar 2016 13:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 LVWpWy-X29aG for ; Wed, 2 Mar 2016 13:30:57 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDCC1A88F0 for ; Wed, 2 Mar 2016 13:30:56 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-6e-56d75b8de3b5 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 71.13.25494.D8B57D65; Wed, 2 Mar 2016 22:30:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 22:30:52 +0100 From: Christer Holmberg To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Happy Eyeballs -- UDP and RTT Thread-Index: AQHRdMJ9rfr5dGDAUke58iStBx2VWJ9Gq+sA Date: Wed, 2 Mar 2016 21:30:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E547C9@ESESSMB209.ericsson.se> References: <874mcobp0s.fsf@hobgoblin.ariadne.com> In-Reply-To: <874mcobp0s.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7om5v9PUwgz/dohZff2xis3h5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgylh39wNrwRamij/HFrE1MH5i7GLk5JAQMJG4 e3MCE4QtJnHh3nq2LkYuDiGBw4wSN48vYYRwFjFKTDy0E8jh4GATsJDo/qcN0iAiECSxqXMF M4gtDDRocdNzRoi4qUTvmW3sELaRxJOVp8EWsAioSPzr3sICYvMK+Eo82b0GzBYCqml+ugWs l1PAWGLLpPlgNiPQQd9PrQHrZRYQl7j1ZD7UoQISS/acZ4awRSVePv7HCmErSSy6/RmqXkdi we5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi4tz042M9VKL MpOLi/Pz9PJSSzYxAqPk4JbfujsYV792PMQowMGoxMP7Qe5amBBrYllxZe4hRgkOZiUR3o7w 62FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEedk+XQ4TEkhPLEnNTk0tSC2CyTJxcEo1MMatWheg nsFw50HthbVVrG/0Z85mZs/6nBB22ddtTaLQ1rxZ+f7rI3f6Lf1VyiLid9H4H3MfW5vnwX/3 LY5erXrD5i+q8umxNacV492vbcpbJK+7x2YZ3jmy7XJszJdNV8XMjkkvKNl8pOlz4rYyQctj 5/k3xd6d2Mdy7euUV6uvWwXd5omNbVZiKc5INNRiLipOBAAwBp9SjgIAAA== Archived-At: Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 21:30:58 -0000 Hi Dale, >Of course, the most desirable SIP transport is a TCP/TLS connection (or a = SIP Outbound UDP flow) that is already established with the destination. =20 Not sure what you mean by "destination", but an outbound flow is only creat= ed between a UA and its registrar. Regards, Christer From nobody Thu Mar 3 07:35:28 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548981A036F for ; Thu, 3 Mar 2016 07:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 gM5YWS8xLdHi for ; Thu, 3 Mar 2016 07:35:23 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A861A0248 for ; Thu, 3 Mar 2016 07:35:23 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-11v.sys.comcast.net with comcast id RTbB1s00B5Geu2801TbN1j; Thu, 03 Mar 2016 15:35:22 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-20v.sys.comcast.net with comcast id RTbM1s00N1nMCLR01TbNyS; Thu, 03 Mar 2016 15:35:22 +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 u23FZKqx005798; Thu, 3 Mar 2016 10:35:20 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u23FZKPN005795; Thu, 3 Mar 2016 10:35:20 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E547C9@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 03 Mar 2016 10:35:20 -0500 Message-ID: <87y49zr2vb.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457019322; bh=Sq79pR5MZPg5GEV166hdXxg2VqrpK383EjBC2InCDYs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=VFw0awUAmp5Nm5bzN6c1eZnt1+Sll33LNAxnis20wISnMUb36F9aBGYOxmZZnFgOo OGRoCLu4etFPC9lT/APSa6i5XhsNREfkJzruVoEik6BSqAj/kV5CczHSMyCOItLc+q 2Nh8j4MS44Eywd6KuGTLwLm0PB+J+wEwTNPgfp2ZlloKk4RmuxHkx7x5+rGcz4abCc 1N5woOTZxqKK2tFj8JPYsYEEVOGkRmHQaddIgTtQcauxaNUtynRUoduE8XPLv0yJld udsOP1l8mn6qCgRcgffHgqPlYliiGj/FmopXW/9f8637ZEVGw3teC1pPce12DzCMI8 MMGPeJUlhMCJA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 15:35:24 -0000 Christer Holmberg writes: >>Of course, the most desirable SIP transport is a TCP/TLS connection >>(or a SIP Outbound UDP flow) that is already established with the >>destination. > > Not sure what you mean by "destination", but an outbound flow is only > created between a UA and its registrar. By "destination" I mean "where the device is trying to send the message". Dale From nobody Thu Mar 3 08:56:44 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A147D1A883D for ; Thu, 3 Mar 2016 08:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 436w8Ng8WA-d for ; Thu, 3 Mar 2016 08:56:42 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D991A6FAC for ; Thu, 3 Mar 2016 08:56:42 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-03v.sys.comcast.net with comcast id RUvc1s00326dK1R01Uwh6H; Thu, 03 Mar 2016 16:56:41 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-01v.sys.comcast.net with comcast id RUwg1s00L1nMCLR01UwhuW; Thu, 03 Mar 2016 16:56:41 +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 u23Gue6C014262; Thu, 3 Mar 2016 11:56:40 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u23Gue8l014259; Thu, 3 Mar 2016 11:56:40 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 03 Mar 2016 11:56:39 -0500 Message-ID: <87wppjpkjc.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457024201; bh=z1/JS4w4g8DFUsRlp7RasjrICDo10uFuFaCHRS3n91I=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=LK9p7PDiE/ZdB5o2bdTcWF+0TpF+Auexx/cVYqJWtlV59cnUc49O/dQsH3VWNUVh+ V8wJWuk3BSfUmqmu5oCIzsk9eR7N1GFd88jnueeKk+yp6Y/w/OUfS0PECVs3Km7tak KH+qHVHa22pePoFTXMB07l9srL5UT/pa5xlzKh7MVdF7boC0IF8HKW0vv/JQjaUlow 3eiXgKwnzo/vxqNhiXcPRzknZQxG0LpJ4TUpHG2ztZVZAgvR4E9coK2cOZPoK4fkka n8i+fEg9GAHM2ArQXg/yKazUJm/A72kzh5K1kDd+PNFcpq8BFdE0VvRT/jcV2Azj// x0tGXpE/zDmAw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:56:43 -0000 Brett Tate writes: >> BTW, there's an error in my message: >> >> > Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group >> > Using the brackets within Via's sent-by is correct; however the brackets > would not be added as part of Via's received parameter value. Argh, yes, my mistake. (I forgot that sent-by is a *host*, not an address. Despite that many, many SIP devices can't handle a host name for a sent-by.) Dale From nobody Thu Mar 3 09:14:15 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859C81A88A6 for ; Thu, 3 Mar 2016 09:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 g06nwtWNX4cG for ; Thu, 3 Mar 2016 09:14:12 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FEF1A8BB1 for ; Thu, 3 Mar 2016 09:13:52 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-10v.sys.comcast.net with comcast id RVDM1s0042EPM3101VDsil; Thu, 03 Mar 2016 17:13:52 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-07v.sys.comcast.net with comcast id RVDr1s00W1nMCLR01VDrfW; Thu, 03 Mar 2016 17:13:52 +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 u23HDpKq015993; Thu, 3 Mar 2016 12:13:51 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u23HDo7I015990; Thu, 3 Mar 2016 12:13:50 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <56D74206.6010804@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 03 Mar 2016 12:13:50 -0500 Message-ID: <87twknpjqp.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457025232; bh=heX71fKf1v04JatPxf5fojq34IVuPsUX/vYpoB2z/Tw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=PbrTgNdgT2OhLO2nN7+Bu7R1OPucka8Soq9gJaa6d2IE8TEDHIY6Y8K+lVAzXRsQB ENpzOtyRvJmdFqD3wbgaI/e78QWGrPsOLOXwEEE6Rfl+buhTXJYGFXe+yQ+a1Bri6+ XqP7oEGMqEnlk2uVojYNIMZa92OPvf/Gpx6htbPMNkftAYfOWed/QGOTf5MbvM4xQ4 BKA5LMr3P7Fdt4ev+aqJXJITZ4KT+u38t7ltl/Av4w4cQ2jybFm0ebREV1twRXsJ2A DvpzdMh43FbQh9CWmDSAb7In382F1o2QHwjunQ/ZhohjNeYT0rkQ6iVZDsw+T/McM0 M/yfKiyICnMUA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 17:14:13 -0000 Paul Kyzivat writes: > This assumes that the proxy that needs to do the merging is the next > hop. Why is that the case? Couldn't there be intermediate proxies? > > If that isn't a concern then I am less concerned. I'm assuming that the Happy Eyeballs case is one where all of the target addresses go to the same device, or to one of a set of tightly-coupled devices. In that sort of situation, the merging can be done at the target(s), and the Proxy-Require device works. Originally, I looked at the merging problem in the context of having multiple routes to a distant destination, with intermediate proxies. E.g., A wants to send two copies of a request to C, one copy via B1 and one copy via B2. The best solution I've found for that case is to send: INVITE sip:biloxi.example.com SIP/2.0 Route: Route: ;group=2 Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.1;group Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: INVITE sip:biloxi.example.com SIP/2.0 Route: Route: ;group=2 Route: Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.2;group Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: In this version of the mechanism, when either request arrives at C, it sees the group parameter on its Route header, which notifies it to examine the indicated Via headers. If C does not support the group mechanism, it does not know to ignore and delete the "Route: " header, so that copy of the request will error out. If C does support the group mechanism, it deletes "Route: " and either responds 495 or routes the request to bilozi.example.com. In either version, the copies of the request have to be routed to a merge point that can correlate all SIP requests that arrive and remove duplicates. I'm trying to figure out whether it's possible to remove that restriction, and instead depend on/allow further downstream devices to notice the group parameter on the Vias to detect pairs of requests that come from different branches of a split. If I am lucky (and I don't think I am), this could all be put into the merged requests logic for UASs. Also, "lr" should be a header field parameter, not a URI parameter. Too late to change that, though. Dale From nobody Thu Mar 3 12:29:05 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10D31B4363 for ; Thu, 3 Mar 2016 12:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001] autolearn=no 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 NQVSeNZBudKG for ; Thu, 3 Mar 2016 12:29:02 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEA41B4361 for ; Thu, 3 Mar 2016 12:29:02 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id g6so28641302igt.1 for ; Thu, 03 Mar 2016 12:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=+yJqXhQFAlJB2YtnH8mqDA7XHjyCiwE7ut3JImuf6Rw=; b=17eoKTnY2okLBP4ErWroazVoFiCNY0cZOMM5b3ns0JH4p5bEg5xDh6oLEC+79TcZmo 25ydyp7GYeATcSu2Ul4lpBjF4aQkHhtNQRnHFQ/etTeZa4sMTAILgGRd1jva9ivVy8Ex XoGmkJV40Loe4S/vM/sxOg9tRcOryxzUWuPiuOKs/8ekYs1ZgQ96xIAX//xelL6wbAFm ezXAZZ1lE1W4Bmj+3wCV6Vg8Du3aZ0FtLZPJovsPCHG30Fsq2V4fEAIuLa0WwgDsrm/u Rkjl8LQVYYSYxAk0SAqhdXs3GroWI62PMJfI0LF/o+lkpBA7dbPcbArSOBDLFSF1Hp9l 1ngg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=+yJqXhQFAlJB2YtnH8mqDA7XHjyCiwE7ut3JImuf6Rw=; b=i/MHlHGbzxI5M8vGY//Phso1u054UQ7BWxCnGg451ZIMpls6lso8KMcV7Ow+/8zupO bS9CEJryN1KjuKjVW8htYafcFOMPZSMBzzuriu1GclXA1eWCT9kkCRf/tselFDH1NhEP 8ZoxGdtJ/eGdVhvncrbJ0ujHZKGlAnia0W18siBdlZ+DCakYSe0orWZYnfQVtUqUIC5j bbZqKwAZ/wvlngNE6vcX6UliuC/YAIDKEX13uXX2//G5GlfLOgUOcymM+ACHCke+8pcD dW+cDOugdO4idfcaVvp245HwAsMnNnImVoGaUzbaGDGTpZB82bppMdcoUhBD1VWlM87g P/4Q== X-Gm-Message-State: AD7BkJI7f/4XWAI79sOQsELbHpp3G9frQ1m2UF51m/cei/OEc2qt5KsrTw8Om93EUA1QRA== X-Received: by 10.50.1.6 with SMTP id 6mr1120133igi.28.1457036941974; Thu, 03 Mar 2016 12:29:01 -0800 (PST) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id wj3sm65874igb.6.2016.03.03.12.28.59 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 12:29:00 -0800 (PST) Received: by mail-io0-f182.google.com with SMTP id l127so40507565iof.3 for ; Thu, 03 Mar 2016 12:28:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr3548017ioe.145.1457036939292; Thu, 03 Mar 2016 12:28:59 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 3 Mar 2016 12:28:59 -0800 (PST) Date: Thu, 3 Mar 2016 15:28:59 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=001a1140d71e3104ab052d2ad9f9 Archived-At: Subject: [sipcore] Happy Eyeballs and UDP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 20:29:04 -0000 --001a1140d71e3104ab052d2ad9f9 Content-Type: text/plain; charset=UTF-8 Since everyone is talking about how desirable TLS is and how easy it is to deprecate UDP, can anybody point me to large scale implementations of TLS+Outbound? I know a lot of implementations for UDP which handle 1M+ of concurrent registrations. When someone tries to implement the same using TLS and Outbound it much harder: 1. Maintaining large number of TLS connections is resource intensive. If you have 1M concurrent registrations you need edge proxies which will terminate 1M concurrent TLS connections and respond to keep alive messages. This requires 10x number the servers then UDP registrations. This also exposes you to more risk of DOS attacks 2. Fail-over is much harder: For TLS/Outbound you either need to put edge proxy on VM that you can migrate to a different server (still had to deal with software failure). To deal with software failures, you need to design the mechanism for the client to recover the connection to a different edge proxy. If call is in progress this involves for the client detecting the flow failure based on keep alive failure, re-registering to get the gruu, and re-INVITE with new gruu in the contact. If server needs to send a message on the client call while this is happening, it needs to queue this message or implement some sort of non-standard re-transmit timer. This typically means call gets dropped. There is no mechanism at all to recover the transaction which is in progress while outbound proxy fails. For UDP you can move the IP address for the edge proxy to a different server. If registration and flow state is in some sort of shared DB, the fail-over occurs naturally for both the client and server. I went through couple of large scale deployments of Outbound with SIPS for large number of consumer devices. In all of them SIP registrations were scrapped and replaced with something proprietary. So, if we are talking about SIP for server to server communications, SIPS is great but it does not need Happy Eyeballs since everything can be provisioned in advance. If we are dealing with deployments that deal with large end user devices (which is where you need Happy Eyeballs) then a lot of things need to be fixed in SIP Outbound before UDP can be discarded. Regards, _____________ Roman Shpount --001a1140d71e3104ab052d2ad9f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since everyone is talking about how desirable TLS is and h= ow easy it is to deprecate UDP, can anybody point me to large scale impleme= ntations of TLS+Outbound? I know a lot of implementations for UDP which han= dle 1M+ of concurrent registrations. When someone tries to implement the sa= me using TLS and Outbound it much harder:

1. Maintaining= large number of TLS connections is resource intensive. If you have 1M conc= urrent registrations you need edge proxies which will terminate 1M concurre= nt TLS connections and respond to keep alive messages. This requires 10x nu= mber the servers then UDP registrations. This also exposes you to more risk= of DOS attacks

2. Fail-over is much harder: For T= LS/Outbound you either need to put edge proxy on VM that you can migrate to= a different server (still had to deal with software failure). To deal with= software failures, you need to design the mechanism for the client to reco= ver the connection to a different edge proxy. If call is in progress this i= nvolves for the client detecting the flow failure based on keep alive failu= re, re-registering to get the gruu, and re-INVITE with new gruu in the cont= act. If server needs to send a message on the client call while this is hap= pening, it needs to queue this message or implement some sort of non-standa= rd re-transmit timer. This typically means call gets dropped. There is no m= echanism at all to recover the transaction which is in progress while outbo= und proxy fails. For UDP you can move the IP address for the edge proxy to = a different server. If registration and flow state is in some sort of share= d DB, the fail-over occurs naturally for both the client and server.
<= div>
I went through couple of large scale deployments of Outb= ound with SIPS for large number of consumer devices. In all of them SIP reg= istrations were scrapped and replaced with something proprietary.

So, if we are talking about SIP for server to server commun= ications, SIPS is great but it does not need Happy Eyeballs since everythin= g can be provisioned in advance.

If we are dealing= with deployments that deal with large end user devices (which is where you= need Happy Eyeballs) then a lot of things need to be fixed in SIP Outbound= before UDP can be discarded.

Regards,
<= div>
_____________
Roman Shpount
--001a1140d71e3104ab052d2ad9f9-- From nobody Thu Mar 3 12:38:32 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9975D1B4397 for ; Thu, 3 Mar 2016 12:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 8aiqvyaV-rQZ for ; Thu, 3 Mar 2016 12:38:30 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D874F1B4395 for ; Thu, 3 Mar 2016 12:38:29 -0800 (PST) X-AuditID: c1b4fb30-f79d26d000006389-59-56d8a0c3bc99 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 19.2D.25481.3C0A8D65; Thu, 3 Mar 2016 21:38:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Thu, 3 Mar 2016 21:38:27 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Happy Eyeballs -- UDP and RTT Thread-Index: AQHRdWJLrfr5dGDAUke58iStBx2VWJ9ILjZQ Date: Thu, 3 Mar 2016 20:38:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E58B1D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E547C9@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <87y49zr2vb.fsf@hobgoblin.ariadne.com> In-Reply-To: <87y49zr2vb.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdT/fwghthBu97RS2+/tjEZvHyRJkD k8fk/V+ZPZYs+ckUwBTFZZOSmpNZllqkb5fAldFx8SVbwQqWihsvD7A1MG5h7mLk5JAQMJHo 7DjNAmGLSVy4t56ti5GLQ0jgMKPEnu6HrBDOIkaJI1s2A1VxcLAJWEh0/9MGMUUENCU6FuSA 9DIDmY927mUCsYWBZi5ues4IYosImEr0ntnGDmEbSWx7O5kNxGYRUJF48e0S2F5eAV+JKasn skCsms4o8b35DCtIglPAWOL5qklgzYxAx30/tYYJYpm4xK0n85kgjhaQWLLnPNQzohIvH/9j hbCVJBbd/gxVryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWM osWpxUm56UZGeqlFmcnFxfl5enmpJZsYgdFzcMtvgx2ML587HmIU4GBU4uHdsOJ6mBBrYllx Ze4hRgkOZiURXqW+G2FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeVk/XQ4TEkhPLEnNTk0tSC2C yTJxcEo1MHroPVM1ONEyg1+XR8q8pVbstrPP0mp9qyiP2+xOzczVkY1Kp773ncjwZTHhr2As cVXMaKvLSfjgzryeSV7XuPWORVrb8XSfjW/NClcllzQ8MfotITpjWs0pjvS8FY0b1v2Nk29v rbK76OIWvvjYzx9yYt6MLlwbl4v/8LjFk6feWPNb74oSS3FGoqEWc1FxIgCvL8xFmgIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 20:38:31 -0000 Hi, >>>Of course, the most desirable SIP transport is a TCP/TLS connection=20 >>>(or a SIP Outbound UDP flow) that is already established with the=20 >>>destination. >> >> Not sure what you mean by "destination", but an outbound flow is only=20 >> created between a UA and its registrar. > > By "destination" I mean "where the device is trying to send the message". If you refer to the remote UA, there is no outbound flow established with t= he UAs. Again, the outbound flow is between a UA and its registrar. Regards, Christer From nobody Thu Mar 3 14:11:58 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA56E1B2D29 for ; Thu, 3 Mar 2016 14:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_38=0.6, SPF_SOFTFAIL=0.665] autolearn=no 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 cEuHYkAwU0NU for ; Thu, 3 Mar 2016 14:11:55 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24C71B2C73 for ; Thu, 3 Mar 2016 14:11:55 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-06v.sys.comcast.net with comcast id RaB31s00127uzMh01aBuV6; Thu, 03 Mar 2016 22:11:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-02v.sys.comcast.net with comcast id RaBu1s00E3KdFy101aBuQ1; Thu, 03 Mar 2016 22:11:54 +0000 To: sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <56D8B6A9.5020900@alum.mit.edu> Date: Thu, 3 Mar 2016 17:11:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457043114; bh=Ky6DqucqHRZ/lTRVkkq6IPcnmNFNScKms2ySC4JiI1Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fapCZk8bGw85VIzxMaX2tcOPbaItxcnihtyqSyPYNj6cJCkXC8ssIcPUMW01Bm1v+ 4EfhhaOePGol9SulSvAoGNxXteSY3wo+OAr9ZHe0YzgzvGaiXprBvB591xZJw95RZD TYvQbw5qvmKr9rxmkfc3m/4+32IPbdLeSLb4vQ6oD42Eb/i+peZkC0+rOna0XUyrXF RYEwQ8fvFEK/1FIkP5PiVkVUX24iuRnnYSZauF8XdyBCy/iy2wfgRlOXOW5PwwxqT7 X6TD5ROnd3qJk0b9pKLJesdlhWUNZJD2K3UJxDLZBWOhH/TUwFcD/TDfTBj35x9dV1 gYVYO8KfQEJhA== Archived-At: Subject: Re: [sipcore] Happy Eyeballs and UDP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 22:11:56 -0000 On 3/3/16 3:28 PM, Roman Shpount wrote: > Since everyone is talking about how desirable TLS is and how easy it is > to deprecate UDP, can anybody point me to large scale implementations of > TLS+Outbound? I know a lot of implementations for UDP which handle 1M+ > of concurrent registrations. When someone tries to implement the same > using TLS and Outbound it much harder: > > 1. Maintaining large number of TLS connections is resource intensive. If > you have 1M concurrent registrations you need edge proxies which will > terminate 1M concurrent TLS connections and respond to keep alive > messages. This requires 10x number the servers then UDP registrations. > This also exposes you to more risk of DOS attacks > > 2. Fail-over is much harder: For TLS/Outbound you either need to put > edge proxy on VM that you can migrate to a different server (still had > to deal with software failure). To deal with software failures, you need > to design the mechanism for the client to recover the connection to a > different edge proxy. If call is in progress this involves for the > client detecting the flow failure based on keep alive failure, > re-registering to get the gruu, and re-INVITE with new gruu in the > contact. If server needs to send a message on the client call while this > is happening, it needs to queue this message or implement some sort of > non-standard re-transmit timer. This typically means call gets dropped. > There is no mechanism at all to recover the transaction which is in > progress while outbound proxy fails. For UDP you can move the IP address > for the edge proxy to a different server. If registration and flow state > is in some sort of shared DB, the fail-over occurs naturally for both > the client and server. Isn't that the point of multiple flows in outbound? (Of course that multiplies the number of registrations and TLS connections.) > I went through couple of large scale deployments of Outbound with SIPS > for large number of consumer devices. In all of them SIP registrations > were scrapped and replaced with something proprietary. > > So, if we are talking about SIP for server to server communications, > SIPS is great but it does not need Happy Eyeballs since everything can > be provisioned in advance. If we assume every end device has an outbound proxy, does that mean you are saying there is no problem for SIP Happy Eyeballs to solve? > If we are dealing with deployments that deal with large end user devices > (which is where you need Happy Eyeballs) then a lot of things need to be > fixed in SIP Outbound before UDP can be discarded. What do you mean by "large end user devices"? Do you mean enterprise SIP servers, such as for IVR or call center? Or enterprise SIP PBXs? Thanks, Paul From nobody Fri Mar 4 14:02:41 2016 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B511A90BE for ; Fri, 4 Mar 2016 14:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 4SkiGr58DDsd for ; Fri, 4 Mar 2016 14:02:37 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F1A1A90BD for ; Fri, 4 Mar 2016 14:02:37 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id z8so4964739ige.0 for ; Fri, 04 Mar 2016 14:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=uEtLPVCL9mKk/GAidZvQmbEzEmYpowwJ0Ms0HyHDGbo=; b=gr1ZbMSYV+cVIXpH8JE7MU+MVZA5O0DdSFjLeQW5j5m7DiD7LiVaQxBYtspX/fmk2c 91I5J+CvSyKNvKuSWDyIelukwBFDaSVcU9EAvtMD9MaZ3JSubt8UO4ZToG8s3uEieqvU oJi/jydntLmma/hZyfnTfMES/iM+zQBe/0YcjjEYjwB7KBMxjSM2EfWt2sdAzEdE+Un6 7LmjvlcHccZi9VGMcbk4dydV+Fm83Cmjjvq8ZE3fxpLejMkTIOr3WhbsFOUk2BZTGhWP letjEiD2/kXgA1eBJBGz3NBlxlV0m1JLLXUqc3Nlj3+o0GbEiHGC50jdgkzsbXkXjhtE 2OlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=uEtLPVCL9mKk/GAidZvQmbEzEmYpowwJ0Ms0HyHDGbo=; b=NWuVJKBfoZlURoSSQMQaXXhNPncAzdOMnWQFTz6LMXsU366vr4z8NYsYpOCAEqoDU4 FM+wyVmX55E2i1jiWeF/madG7HD1gdZYkm+UL+A/yo5v4gnqgT9ADakPGP7XSKB/3IMp 3f7/AUstgiwPNKE3iwlH45ndd7kTcRYOq6pXOz69ViL8x3X7YmP/rYpIa84EUpcIxykS aXLQj+8Lb2cJPkTwFZbNV9ShRpeasgiYQHIVKEMKYwGTnx4CcOZlWmfzbbQ4O/cja91O jlfTRU5oXY5XBMsECenVsPNVyi4Q+sDfg8CpV7lu76YIpUYK6K3usISQU+mi0SW11Ah+ ufow== X-Gm-Message-State: AD7BkJKA/OK/gwGlTfEsmUecQ2TQ9S9Pd5QeHmuS9PdRk94+guxQUwIa4Z/AKMz8m2qsWg== X-Received: by 10.50.124.42 with SMTP id mf10mr1173140igb.79.1457128956512; Fri, 04 Mar 2016 14:02:36 -0800 (PST) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id i187sm1956924ioi.33.2016.03.04.14.02.34 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 14:02:34 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id ir4so10547457igb.1 for ; Fri, 04 Mar 2016 14:02:34 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.109.196 with SMTP id hu4mr1244078igb.24.1457128953986; Fri, 04 Mar 2016 14:02:33 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 4 Mar 2016 14:02:33 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 17:02:33 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: sipcore@ietf.org, Paul Kyzivat Content-Type: multipart/alternative; boundary=089e011605a2b1d7d3052d4045a8 Archived-At: Subject: Re: [sipcore] sipcore Digest, Vol 84, Issue 5 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 22:02:39 -0000 --089e011605a2b1d7d3052d4045a8 Content-Type: text/plain; charset=UTF-8 On Thu, 3 Mar 2016 17:11:53 -0500, Paul Kyzivat wrote: > On 3/3/16 3:28 PM, Roman Shpount wrote: > > 2. Fail-over is much harder: For TLS/Outbound you either need to put > > edge proxy on VM that you can migrate to a different server (still had > > to deal with software failure). To deal with software failures, you need > > to design the mechanism for the client to recover the connection to a > > different edge proxy. If call is in progress this involves for the > > client detecting the flow failure based on keep alive failure, > > re-registering to get the gruu, and re-INVITE with new gruu in the > > contact. If server needs to send a message on the client call while this > > is happening, it needs to queue this message or implement some sort of > > non-standard re-transmit timer. This typically means call gets dropped. > > There is no mechanism at all to recover the transaction which is in > > progress while outbound proxy fails. For UDP you can move the IP address > > for the edge proxy to a different server. If registration and flow state > > is in some sort of shared DB, the fail-over occurs naturally for both > > the client and server. > > Isn't that the point of multiple flows in outbound? > (Of course that multiplies the number of registrations and TLS > connections.) > Multiple flows somewhat mitigate the problem of edge proxy failure at the cost of multiplying the cost of connection management. There is still and issue of temporary network failure between the end point and the proxy. In case of TLS this terminates all flows from the client to all proxies and typically terminates the call. And then there is a use case of end point migrating from one IP to another. Here the quicker flow recovery with UDP increases the chances of keeping the call running vs 7 or 8 round trips required to recover the TLS flow (TCP connection setup, TLS connection setup, registration with response and then re-invite with new GRUU). And then there is a use case when client used a temporary GRUU which was flow specific. And there is still no way to recover the transaction since, I believe, transactions are flow bound. > > I went through couple of large scale deployments of Outbound with SIPS > > for large number of consumer devices. In all of them SIP registrations > > were scrapped and replaced with something proprietary. > > > > So, if we are talking about SIP for server to server communications, > > SIPS is great but it does not need Happy Eyeballs since everything can > > be provisioned in advance. > > If we assume every end device has an outbound proxy, does that mean you > are saying there is no problem for SIP Happy Eyeballs to solve? > I meant that if SIP is used for server to server interconnects. These are interconnects between devices with capabilities well known in advance located on well known addresses. When you are interconnecting two service providers you typically know in advance if IPv6 is used, so there is no need for Happy Eyeballs. > If we are dealing with deployments that deal with large end user devices > > (which is where you need Happy Eyeballs) then a lot of things need to be > > fixed in SIP Outbound before UDP can be discarded. > > What do you mean by "large end user devices"? Do you mean enterprise SIP > servers, such as for IVR or call center? Or enterprise SIP PBXs? > It was a typing mistake. I meant "deployments that deal with large numbers of end user devices" Happy Eyeballs is needed to address situation where you have large number of end user devices located on multiple customer networks with different capabilities trying to connect to a central public service which is accessible over both IPv4 and IPv6. The point I am trying to make that all of such SIP services primarily use UDP so it is too early to discard it. _____________ Roman Shpount --089e011605a2b1d7d3052d4045a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On=C2=A0Thu, 3 Mar 2016 17:11:53 -0500,=C2=A0Paul Kyzivat <pkyzivat@alum.mit.edu>=C2=A0wrote:=
On 3/3/16 3:28 = PM, Roman Shpount wrote:
> 2. Fail-over is much harder: For TLS/Outbo= und you either need to put
> edge proxy on VM that you can migrate to a different server (still had=
> to deal with software failure). To deal with software failures, you ne= ed
> to design the mechanism for the client to recover the connection to a<= br> > different edge proxy. If call is in progress this involves for the
> client detecting the flow failure based on keep alive failure,
> re-registering to get the gruu, and re-INVITE with new gruu in the
> contact. If server needs to send a message on the client call while th= is
> is happening, it needs to queue this message or implement some sort of=
> non-standard re-transmit timer. This typically means call gets dropped= .
> There is no mechanism at all to recover the transaction which is in > progress while outbound proxy fails. For UDP you can move the IP addre= ss
> for the edge proxy to a different server. If registration and flow sta= te
> is in some sort of shared DB, the fail-over occurs naturally for both<= br> > the client and server.

Isn't that the point of multiple flows in outbound?
(Of course that multiplies the number of registrations and TLS connections.= )

Multiple flows somewhat mitigate the = problem of edge proxy failure at the cost of multiplying the cost of connec= tion management. There is still and issue of temporary network failure betw= een the end point and the proxy. In case of TLS this terminates all flows f= rom the client to all proxies and typically terminates the call. And then t= here is a use case of end point migrating from one IP to another. Here the = quicker flow recovery with UDP increases the chances of keeping the call ru= nning vs 7 or 8 round trips required to recover the TLS flow (TCP connectio= n setup, TLS connection setup, registration with response and then re-invit= e with new GRUU). And then there is a use case when client used a temporary= GRUU which was flow specific. And there is still no way to recover the tra= nsaction since, I believe, transactions are flow bound.
=C2=A0
> I went through couple of large scale deployments o= f Outbound with SIPS
> for large number of consumer devices. In all of them SIP registrations=
> were scrapped and replaced with something proprietary.
>
> So, if we are talking about SIP for server to server communications, > SIPS is great but it does not need Happy Eyeballs since everything can=
> be provisioned in advance.

If we assume every end device has an outbound proxy, does that mean you
are saying there is no problem for SIP Happy Eyeballs to solve?
=C2=A0
I meant that if SIP is used for server to server= interconnects. These are interconnects between devices with capabilities w= ell known in advance located on well known addresses. When you are intercon= necting two service providers you typically know in advance if IPv6 is used= , so there is no need for Happy Eyeballs.

> If we are dealing with deployments that deal with large end user d= evices
> (which is where you need Happy Eyeballs) then a lot of things need to = be
> fixed in SIP Outbound before UDP can be discarded.

What do you mean by "large end user devices"? Do you mean enterpr= ise SIP
servers, such as for IVR or call center? Or enterprise SIP PBXs?

It was a typing mistake. I meant "deployment= s that deal with large numbers of end user devices"

Happy Eyeballs is needed to address situation where you have la= rge number of end user devices located on multiple customer networks with d= ifferent capabilities trying to connect to a central public service which i= s accessible over both IPv4 and IPv6. The point I am trying to make that al= l of such SIP services primarily use UDP so it is too early to discard it.<= /div>

_____________=
Roman Shpount
=C2=A0
--089e011605a2b1d7d3052d4045a8-- From nobody Mon Mar 7 09:32:13 2016 Return-Path: X-Original-To: sipcore@ietfc.amsl.com Delivered-To: sipcore@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 509891CD68A for ; Mon, 7 Mar 2016 09:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.972] autolearn=no autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om_4lds8Gn3U for ; Mon, 7 Mar 2016 09:32:07 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 8E3971CD68D for ; Mon, 7 Mar 2016 09:32:03 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-11v.sys.comcast.net with comcast id T5Xc1s0032Qkjl9015Y2RH; Mon, 07 Mar 2016 17:32:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id T5Y21s0013KdFy1015Y2Mw; Mon, 07 Mar 2016 17:32:02 +0000 To: Roman Shpount , sipcore@ietf.org References: From: Paul Kyzivat Message-ID: <56DDBB10.6050909@alum.mit.edu> Date: Mon, 7 Mar 2016 12:32:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457371922; bh=a7Nh88sJl+yhcoysQFy9babfRV8ymwrUBAR84IMx8Yk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=qyLsJX3mXEQiXw3XbpVtvxy4Y1BmuCSaQA1wwmssziorDbxf+43EpMcCYbHNB73kt TQELN6YzbA2xCRQ8PBpNx7tcVSACnGOXugdPMl9gUNd1zoRpjH3FvJ4m0ssWJ3/8JW 6eyPYacdft7zRpAGyYlgyzq+hb/Kvowco4QvbS+jvi1qjIZ+XPABWjDV8R5yMUxuG0 hswxCFq+iuBC1PF+GrBwy9UXOS59EGtYY9iz1tVa1UTVskoiaPOZge5mHgdpHx3F/e x6Cdj+CzgnF9hyYBizxZ3LN6mZqILu59ErgqcnVms4sQ23sIVV65x6oRmsuPAX+kYD pTYJscsbgzLbA== Archived-At: Subject: [sipcore] SIP TLS issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 17:32:13 -0000 Inline. On 3/4/16 5:02 PM, Roman Shpount wrote: > On Thu, 3 Mar 2016 17:11:53 -0500, Paul Kyzivat > wrote: > > On 3/3/16 3:28 PM, Roman Shpount wrote: > > 2. Fail-over is much harder: For TLS/Outbound you either need to put > > edge proxy on VM that you can migrate to a different server > (still had > > to deal with software failure). To deal with software failures, > you need > > to design the mechanism for the client to recover the connection to a > > different edge proxy. If call is in progress this involves for the > > client detecting the flow failure based on keep alive failure, > > re-registering to get the gruu, and re-INVITE with new gruu in the > > contact. If server needs to send a message on the client call > while this > > is happening, it needs to queue this message or implement some > sort of > > non-standard re-transmit timer. This typically means call gets > dropped. > > There is no mechanism at all to recover the transaction which is in > > progress while outbound proxy fails. For UDP you can move the IP > address > > for the edge proxy to a different server. If registration and > flow state > > is in some sort of shared DB, the fail-over occurs naturally for both > > the client and server. > > Isn't that the point of multiple flows in outbound? > (Of course that multiplies the number of registrations and TLS > connections.) > > > Multiple flows somewhat mitigate the problem of edge proxy failure at > the cost of multiplying the cost of connection management. There is > still and issue of temporary network failure between the end point and > the proxy. In case of TLS this terminates all flows from the client to > all proxies and typically terminates the call. And then there is a use > case of end point migrating from one IP to another. Here the quicker > flow recovery with UDP increases the chances of keeping the call running > vs 7 or 8 round trips required to recover the TLS flow (TCP connection > setup, TLS connection setup, registration with response and then > re-invite with new GRUU). And then there is a use case when client used > a temporary GRUU which was flow specific. And there is still no way to > recover the transaction since, I believe, transactions are flow bound. > > > I went through couple of large scale deployments of Outbound with > SIPS > > for large number of consumer devices. In all of them SIP > registrations > > were scrapped and replaced with something proprietary. > > > > So, if we are talking about SIP for server to server communications, > > SIPS is great but it does not need Happy Eyeballs since > everything can > > be provisioned in advance. > > If we assume every end device has an outbound proxy, does that mean you > are saying there is no problem for SIP Happy Eyeballs to solve? > > I meant that if SIP is used for server to server interconnects. These > are interconnects between devices with capabilities well known in > advance located on well known addresses. When you are interconnecting > two service providers you typically know in advance if IPv6 is used, so > there is no need for Happy Eyeballs. Do you mean interconnect of service providers that have individual peering relationships? What about interconnections between arbitrary enterprises? (Possibly big ones.) It seems like there are likely cases there they won't have individual agreements. > > If we are dealing with deployments that deal with large end user > devices > > (which is where you need Happy Eyeballs) then a lot of things > need to be > > fixed in SIP Outbound before UDP can be discarded. > > What do you mean by "large end user devices"? Do you mean enterprise SIP > servers, such as for IVR or call center? Or enterprise SIP PBXs? > > > It was a typing mistake. I meant "deployments that deal with large > numbers of end user devices" > > Happy Eyeballs is needed to address situation where you have large > number of end user devices located on multiple customer networks with > different capabilities trying to connect to a central public service > which is accessible over both IPv4 and IPv6. The point I am trying to > make that all of such SIP services primarily use UDP so it is too early > to discard it. The obvious problems here are: 1) security 2) large sip messages and UDP message fragmentation If only (1) were a problem, then maybe the answer would be SIP over DTLS. But that has never happened. My impression is that it was deemed to not be worthwhile because of (2). That it people should jump right to TLS to solve both problems at once. Thanks, Paul From nobody Mon Mar 7 09:57:47 2016 Return-Path: X-Original-To: sipcore@ietfc.amsl.com Delivered-To: sipcore@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 990DB1CD73A for ; Mon, 7 Mar 2016 09:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0-l9TZaaEPr for ; Mon, 7 Mar 2016 09:57:26 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id A32F51CD734 for ; Mon, 7 Mar 2016 09:57:19 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id ig19so30579666igb.0 for ; Mon, 07 Mar 2016 09:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=UQr8kaFtkKHjNsqPDIfOc4xydqUkeOljrAgRZRmh7bo=; b=sZX+CMNHT3QA3jZG3s1osrAJAmrFXxq3gxgt3J96YlUdDREGKniVxdWMfN1UxIB45p P6wWKbcq8I274CxBpY6pb+QirnACGgmGPj1cJ3ocmpRodTEuds0FoBruSKUbb1ES4uWm x7CQeZTaOVCRbQufaMtSbm2FuFtIKO4Ir6twYydQ3vpdkrNtNWX2FQLFL66oCHBvsK8U ebvP/q25GSmjIfJBTwIxZU66/M6tswyEK+2Ar25YYwKiONqj/fHNoMIW9bza9ToB3qVr eE2CBP4bTsOHu6yHWoht7nTwyUhDbpJrCW+Y/YM2RyHKg2EsyXwH37LRnwV7RzF7GKm2 VieQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UQr8kaFtkKHjNsqPDIfOc4xydqUkeOljrAgRZRmh7bo=; b=bypHPFpPApQTgWE0ofIYIZeOqTq8RcnbOtINaIVt+HYJdxdzxNUmYhM6kZJPSjFHUH 8QMnRZgE1AGRVYL71pC6y0xrRCHmx0GJtNvHJEIQv04I7EqrH17fnAZcERPbDZoTtMj/ 04RTn6N8MwXUlSn9AybZP6JIvD0qG2sPZcbsD0AwOvSv9TzkQTlrtYgicPs+/t1M1Ctg v4535orbXFS73X/ELQlQsauJv272LEY0gwd4JMxsxUZw9BMEb/X1zqrcR40979VFWa+9 dOb4VHvbzAQfBbWEOrsUx4+7tFDeD/Irf8Dz1+8AlZlfLw/34crA+27e3SckXCUNA0PC /o7A== X-Gm-Message-State: AD7BkJJo88h66TpuReokqHpYMhSyLtNo7nz2ugdu2CpUB6PR0OS5uaFLu6pQhbLSQTNBfA== X-Received: by 10.50.109.196 with SMTP id hu4mr13498169igb.24.1457373438991; Mon, 07 Mar 2016 09:57:18 -0800 (PST) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com. [209.85.213.181]) by smtp.gmail.com with ESMTPSA id m9sm5097594igj.1.2016.03.07.09.57.17 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 09:57:17 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id vs8so29917407igb.1 for ; Mon, 07 Mar 2016 09:57:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.18.113 with SMTP id v17mr3973249igd.2.1457373436721; Mon, 07 Mar 2016 09:57:16 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 7 Mar 2016 09:57:16 -0800 (PST) In-Reply-To: <56DDBB10.6050909@alum.mit.edu> References: <56DDBB10.6050909@alum.mit.edu> Date: Mon, 7 Mar 2016 12:57:16 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01494ff2004529052d793246 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP TLS issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 17:57:34 -0000 --089e01494ff2004529052d793246 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 12:32 PM, Paul Kyzivat wrote: > Inline. > > On 3/4/16 5:02 PM, Roman Shpount wrote: > >> On Thu, 3 Mar 2016 17:11:53 -0500, Paul Kyzivat > > wrote: >> >> On 3/3/16 3:28 PM, Roman Shpount wrote: >> > 2. Fail-over is much harder: For TLS/Outbound you either need to >> put >> > edge proxy on VM that you can migrate to a different server >> (still had >> > to deal with software failure). To deal with software failures, >> you need >> > to design the mechanism for the client to recover the connection >> to a >> > different edge proxy. If call is in progress this involves for the >> > client detecting the flow failure based on keep alive failure, >> > re-registering to get the gruu, and re-INVITE with new gruu in the >> > contact. If server needs to send a message on the client call >> while this >> > is happening, it needs to queue this message or implement some >> sort of >> > non-standard re-transmit timer. This typically means call gets >> dropped. >> > There is no mechanism at all to recover the transaction which is in >> > progress while outbound proxy fails. For UDP you can move the IP >> address >> > for the edge proxy to a different server. If registration and >> flow state >> > is in some sort of shared DB, the fail-over occurs naturally for >> both >> > the client and server. >> >> Isn't that the point of multiple flows in outbound? >> (Of course that multiplies the number of registrations and TLS >> connections.) >> >> >> Multiple flows somewhat mitigate the problem of edge proxy failure at >> the cost of multiplying the cost of connection management. There is >> still and issue of temporary network failure between the end point and >> the proxy. In case of TLS this terminates all flows from the client to >> all proxies and typically terminates the call. And then there is a use >> case of end point migrating from one IP to another. Here the quicker >> flow recovery with UDP increases the chances of keeping the call running >> vs 7 or 8 round trips required to recover the TLS flow (TCP connection >> setup, TLS connection setup, registration with response and then >> re-invite with new GRUU). And then there is a use case when client used >> a temporary GRUU which was flow specific. And there is still no way to >> recover the transaction since, I believe, transactions are flow bound. >> >> > I went through couple of large scale deployments of Outbound with >> SIPS >> > for large number of consumer devices. In all of them SIP >> registrations >> > were scrapped and replaced with something proprietary. >> > >> > So, if we are talking about SIP for server to server >> communications, >> > SIPS is great but it does not need Happy Eyeballs since >> everything can >> > be provisioned in advance. >> >> If we assume every end device has an outbound proxy, does that mean >> you >> are saying there is no problem for SIP Happy Eyeballs to solve? >> >> I meant that if SIP is used for server to server interconnects. These >> are interconnects between devices with capabilities well known in >> advance located on well known addresses. When you are interconnecting >> two service providers you typically know in advance if IPv6 is used, so >> there is no need for Happy Eyeballs. >> > > Do you mean interconnect of service providers that have individual peering > relationships? > > What about interconnections between arbitrary enterprises? (Possibly big > ones.) It seems like there are likely cases there they won't have > individual agreements. > I meant most of the federation type interconnects, including service provider to service provider, SIP trunks from service provider to enterprise, and SIP trunks between enterprises. These as well as SIP IP phones in enterprise are the main deployment scenarios for SIP. > If we are dealing with deployments that deal with large end user >> devices >> > (which is where you need Happy Eyeballs) then a lot of things >> need to be >> > fixed in SIP Outbound before UDP can be discarded. >> >> What do you mean by "large end user devices"? Do you mean enterprise >> SIP >> servers, such as for IVR or call center? Or enterprise SIP PBXs? >> >> >> It was a typing mistake. I meant "deployments that deal with large >> numbers of end user devices" >> >> Happy Eyeballs is needed to address situation where you have large >> number of end user devices located on multiple customer networks with >> different capabilities trying to connect to a central public service >> which is accessible over both IPv4 and IPv6. The point I am trying to >> make that all of such SIP services primarily use UDP so it is too early >> to discard it. >> > > The obvious problems here are: > > 1) security > 2) large sip messages and UDP message fragmentation > > If only (1) were a problem, then maybe the answer would be SIP over DTLS. > > But that has never happened. My impression is that it was deemed to not be > worthwhile because of (2). That it people should jump right to TLS to solve > both problems at once. > DTLS is not an answer either since encryption state will need to be failed over with the edge proxy. What you need is a protocol where client can recover a flow to the server, including encryption, using a single round trip. I think deployments of large numbers of SIP devices connected to the public service (like SIP based Skype) never happened and will never happen because of the complexity and design issues of SIP Outbound in combination with TLS. I think this is why none of the large scale consumer VoIP applications used SIP. The companies that built these products used RTP, ICE and media components, but SIP was ignored. I do not think all these companies spent all the design effort to build something completely new just because they wanted to build something different. From my experience with couple of similar projects the issues of scaling the deployment and handling redundancy were the main driving factors. Putting aside all the problems with SIP Outbound, there are still a lot of companies which offer SIP over UDP to the end users. I am talking about all the hosted PBX solutions. Most of these deployments do not use ICE and use host based NAT traversal for signaling and media to keep the message size small. This is not a solution you would design if you have started the design from scratch, but these installations definitely need a migration path from IPv4 to IPv6. Telling them to switch to SIPS with SIP Outbound is unrealistic, so I believe Happy Eyeballs must provide the solution for UDP. Regards, _____________ Roman Shpount --089e01494ff2004529052d793246 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 7, 2016 at 12:32 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
Inline.

On 3/4/16 5:02 PM, Roman Shpount wrote:
On Thu, 3 Mar 2016 17:11:53 -0500, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 On 3/3/16 3:28 PM, Roman Shpount wrote:
=C2=A0 =C2=A0 =C2=A0> 2. Fail-over is much harder: For TLS/Outbound you = either need to put
=C2=A0 =C2=A0 =C2=A0> edge proxy on VM that you can migrate to a differe= nt server
=C2=A0 =C2=A0 (still had
=C2=A0 =C2=A0 =C2=A0> to deal with software failure). To deal with softw= are failures,
=C2=A0 =C2=A0 you need
=C2=A0 =C2=A0 =C2=A0> to design the mechanism for the client to recover = the connection to a
=C2=A0 =C2=A0 =C2=A0> different edge proxy. If call is in progress this = involves for the
=C2=A0 =C2=A0 =C2=A0> client detecting the flow failure based on keep al= ive failure,
=C2=A0 =C2=A0 =C2=A0> re-registering to get the gruu, and re-INVITE with= new gruu in the
=C2=A0 =C2=A0 =C2=A0> contact. If server needs to send a message on the = client call
=C2=A0 =C2=A0 while this
=C2=A0 =C2=A0 =C2=A0> is happening, it needs to queue this message or im= plement some
=C2=A0 =C2=A0 sort of
=C2=A0 =C2=A0 =C2=A0> non-standard re-transmit timer. This typically mea= ns call gets
=C2=A0 =C2=A0 dropped.
=C2=A0 =C2=A0 =C2=A0> There is no mechanism at all to recover the transa= ction which is in
=C2=A0 =C2=A0 =C2=A0> progress while outbound proxy fails. For UDP you c= an move the IP
=C2=A0 =C2=A0 address
=C2=A0 =C2=A0 =C2=A0> for the edge proxy to a different server. If regis= tration and
=C2=A0 =C2=A0 flow state
=C2=A0 =C2=A0 =C2=A0> is in some sort of shared DB, the fail-over occurs= naturally for both
=C2=A0 =C2=A0 =C2=A0> the client and server.

=C2=A0 =C2=A0 Isn't that the point of multiple flows in outbound?
=C2=A0 =C2=A0 (Of course that multiplies the number of registrations and TL= S
=C2=A0 =C2=A0 connections.)


Multiple flows somewhat mitigate the problem of edge proxy failure at
the cost of multiplying the cost of connection management. There is
still and issue of temporary network failure between the end point and
the proxy. In case of TLS this terminates all flows from the client to
all proxies and typically terminates the call. And then there is a use
case of end point migrating from one IP to another. Here the quicker
flow recovery with UDP increases the chances of keeping the call running vs 7 or 8 round trips required to recover the TLS flow (TCP connection
setup, TLS connection setup, registration with response and then
re-invite with new GRUU). And then there is a use case when client used
a temporary GRUU which was flow specific. And there is still no way to
recover the transaction since, I believe, transactions are flow bound.

=C2=A0 =C2=A0 =C2=A0> I went through couple of large scale deployments o= f Outbound with
=C2=A0 =C2=A0 SIPS
=C2=A0 =C2=A0 =C2=A0> for large number of consumer devices. In all of th= em SIP
=C2=A0 =C2=A0 registrations
=C2=A0 =C2=A0 =C2=A0> were scrapped and replaced with something propriet= ary.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> So, if we are talking about SIP for server to serv= er communications,
=C2=A0 =C2=A0 =C2=A0> SIPS is great but it does not need Happy Eyeballs = since
=C2=A0 =C2=A0 everything can
=C2=A0 =C2=A0 =C2=A0> be provisioned in advance.

=C2=A0 =C2=A0 If we assume every end device has an outbound proxy, does tha= t mean you
=C2=A0 =C2=A0 are saying there is no problem for SIP Happy Eyeballs to solv= e?

I meant that if SIP is used for server to server interconnects. These
are interconnects between devices with capabilities well known in
advance located on well known addresses. When you are interconnecting
two service providers you typically know in advance if IPv6 is used, so
there is no need for Happy Eyeballs.

Do you mean interconnect of service providers that have individual peering = relationships?

What about interconnections between arbitrary enterprises? (Possibly big on= es.) It seems like there are likely cases there they won't have individ= ual agreements.

I meant most of the fed= eration type interconnects, including service provider to service provider,= SIP trunks from service provider to enterprise, and SIP trunks between ent= erprises. These as well as SIP IP phones in enterprise are the main deploym= ent scenarios for SIP.=C2=A0

=C2=A0 =C2=A0 =C2=A0> If we are dealing with deployments that de= al with large end user
=C2=A0 =C2=A0 devices
=C2=A0 =C2=A0 =C2=A0> (which is where you need Happy Eyeballs) then a lo= t of things
=C2=A0 =C2=A0 need to be
=C2=A0 =C2=A0 =C2=A0> fixed in SIP Outbound before UDP can be discarded.=

=C2=A0 =C2=A0 What do you mean by "large end user devices"? Do yo= u mean enterprise SIP
=C2=A0 =C2=A0 servers, such as for IVR or call center? Or enterprise SIP PB= Xs?


It was a typing mistake. I meant "deployments that deal with large
numbers of end user devices"

Happy Eyeballs is needed to address situation where you have large
number of end user devices located on multiple customer networks with
different capabilities trying to connect to a central public service
which is accessible over both IPv4 and IPv6. The point I am trying to
make that all of such SIP services primarily use UDP so it is too early
to discard it.

The obvious problems here are:

1) security
2) large sip messages and UDP message fragmentation

If only (1) were a problem, then maybe the answer would be SIP over DTLS.
But that has never happened. My impression is that it was deemed to not be = worthwhile because of (2). That it people should jump right to TLS to solve= both problems at once.

DTLS is not an = answer either since encryption state will need to be failed over with the e= dge proxy. What you need is a protocol where client can recover a flow to t= he server, including encryption, using a single round trip.=C2=A0

I think deployments of large numbers of SIP devices connect= ed to the public service (like SIP based Skype) never happened and will nev= er happen because of the complexity and design issues of SIP Outbound in co= mbination with TLS. I think this is why none of the large scale consumer Vo= IP applications used SIP. The companies that built these products used RTP,= ICE and media components, but SIP was ignored. I do not think all these co= mpanies spent all the design effort to build something completely new just = because they wanted to build something different. From my experience with c= ouple of similar projects the issues of scaling the deployment and handling= redundancy were the main driving factors.

Putting= aside all the problems with SIP Outbound, there are still a lot of compani= es which offer SIP over UDP to the end users. I am talking about all the ho= sted PBX solutions. Most of these deployments do not use ICE and use host b= ased NAT traversal for signaling and media to keep the message size small. = This is not a solution you would design if you have started the design from= scratch, but these installations definitely need a migration path from IPv= 4 to IPv6. Telling them to switch to SIPS with SIP Outbound is unrealistic,= so I believe Happy Eyeballs must provide the solution for UDP.
<= br>
Regards,
___________= __
Roman Shpount
=C2=A0
--089e01494ff2004529052d793246-- From nobody Tue Mar 8 08:08:55 2016 Return-Path: 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 4E4BB12D7DA for ; Tue, 8 Mar 2016 08:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvmDC33bdlR7 for ; Tue, 8 Mar 2016 08:08:53 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEB912D533 for ; Tue, 8 Mar 2016 08:08:47 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with comcast id TU5l1s00E2TL4Rh01U8m77; Tue, 08 Mar 2016 16:08:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id TU8m1s00M3KdFy101U8mGr; Tue, 08 Mar 2016 16:08:46 +0000 To: Roman Shpount References: <56DDBB10.6050909@alum.mit.edu> From: Paul Kyzivat Message-ID: <56DEF90C.80105@alum.mit.edu> Date: Tue, 8 Mar 2016 11:08:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457453327; bh=zRpeDTvv7PW3gY0x2ktBiqwWISaY9RdMFLjTLVfA/1w=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bTOmkoqiHX1yulCbngJVVKAZDjxEcr7CjQKqIQtlkuAnhuLgU5m2u6OcmEIldgxNv ziIvvvcltXCOOGp047JzE3s8u9XRVhyIfFJsTcnWcF6KlFLZkb5rUlTaCVu4xnF6Ca t58MG/lZMBtQikc46muxmiCYGzcMraDogxbG4kZXGxGMM2J0H2jVMfbewDCfhU5aGX 101CfNzlyy3Gad1VF+3Q/x+r6whSPISYHT4Uf4n6r7xMuuRJekXWomdjx73b7Zxbcw boUnLDl8uW7l+pKdCBbSi7XBaH9uH33BWUQgqJIkq4r6KX4C7E/NBTBtPZ+MZI4gNX LWt0FUFzqQH4g== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP TLS issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:08:54 -0000 On 3/7/16 12:57 PM, Roman Shpount wrote: > Putting aside all the problems with SIP Outbound, there are still a lot > of companies which offer SIP over UDP to the end users. I am talking > about all the hosted PBX solutions. Most of these deployments do not use > ICE and use host based NAT traversal for signaling and media to keep the > message size small. This is not a solution you would design if you have > started the design from scratch, but these installations definitely need > a migration path from IPv4 to IPv6. Telling them to switch to SIPS with > SIP Outbound is unrealistic, so I believe Happy Eyeballs must provide > the solution for UDP. Then what is the solution for security. ISTM that people are finally realizing that it is important. Is this for the stupid people market? Thanks, Paul From nobody Tue Mar 8 10:41:18 2016 Return-Path: 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 9C1D612D95E for ; Tue, 8 Mar 2016 10:41:17 -0800 (PST) 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_40=-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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGaK208dmvNw for ; Tue, 8 Mar 2016 10:41:16 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A51012D97B for ; Tue, 8 Mar 2016 10:41:16 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-02v.sys.comcast.net with comcast id TWhC1s00457bBgG01WhGn2; Tue, 08 Mar 2016 18:41:16 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-13v.sys.comcast.net with comcast id TWhE1s00J1nMCLR01WhFJa; Tue, 08 Mar 2016 18:41:15 +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 u28IfEUE015610; Tue, 8 Mar 2016 13:41:14 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u28IfEcl015607; Tue, 8 Mar 2016 13:41:14 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 08 Mar 2016 13:41:13 -0500 Message-ID: <878u1slsmu.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457462476; bh=8c2xgJpomrBbPV4WsBNLTu6Ml1EWpdZ1S0Dt7RIj49A=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ulH+Gx7Y+y3f/aHuodbcpZm6ZSmMSwnnXb/D++TWs5F3XJeJa5465QEd8S/5+s9CY qNUuZ+sjfZJPEamIqQzn7r8V5V8TH2hp1vQ/F+udHohpEdSLIt60/322q25tJEx6iV +pdkR0hgUjFjX+Mie6oai2eduXM7r1cwitjoL11/u8McLubJoyDbBKA1ECT3rlSc1D ivKPrigySGUlc5Px5TiuF2Y5Cld1DTUVsGmYz2q1Vajc3idoRhCWEZ8KblxHeIYhE0 lq8ScWGS5WoCwpakhNb1rvMIy6zrjYB5yvjnryoiOo6lP7KyvCcC6RUaYsYcu0Fi0S A4JNdTsZsKGbQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP TLS issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 18:41:17 -0000 Roman Shpount writes: > DTLS is not an answer either since encryption state will need to be failed > over with the edge proxy. What you need is a protocol where client can > recover a flow to the server, including encryption, using a single round > trip. > > I think deployments of large numbers of SIP devices connected to the public > service (like SIP based Skype) never happened and will never happen because > of the complexity and design issues of SIP Outbound in combination with > TLS. I think this is why none of the large scale consumer VoIP applications > used SIP. The companies that built these products used RTP, ICE and media > components, but SIP was ignored. I do not think all these companies spent > all the design effort to build something completely new just because they > wanted to build something different. From my experience with couple of > similar projects the issues of scaling the deployment and handling > redundancy were the main driving factors. That sounds to me like the requirements for a useful work item. Dale From nobody Tue Mar 8 10:57:51 2016 Return-Path: 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 154CE12D9E4 for ; Tue, 8 Mar 2016 10:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6GtvQJFEFdw for ; Tue, 8 Mar 2016 10:57:49 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5403312D9E1 for ; Tue, 8 Mar 2016 10:57:49 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-05v.sys.comcast.net with comcast id TWxo1s0045E3ZMc01WxoEe; Tue, 08 Mar 2016 18:57:48 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-18v.sys.comcast.net with comcast id TWxn1s00L1nMCLR01Wxoxg; Tue, 08 Mar 2016 18:57:48 +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 u28IvlQh017345; Tue, 8 Mar 2016 13:57:47 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u28IvkiK017342; Tue, 8 Mar 2016 13:57:46 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: worley@ariadne.com (Dale R. Worley) In-Reply-To: <874mcobp0s.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 08 Mar 2016 13:57:46 -0500 Message-ID: <8737s0lrv9.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457463468; bh=/sokNfF0YcZb/NJ2rabLQ7uW7Zu4C2xZ5DpldaUqeag=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=YAo/8zsd3SJg3IfrxMxe3UhN05zEVCOzRlb6EmsNNm29XXxnu20uZ603986z3JLk3 OubXAprWPUTrZEGf0gw2+qU4B9zy1e2sPREb7pwyVn6V27VkgNvszXN59e0EwWwYJH qLb4JYzLp6H0PEt5sQ6q7u90JiwRJQxR1S1CQ/VZQkt6aH5okvtvqBIoUjxY+o+01f 5TDSepkZxRKJT2zN/7Hwq/9Eqsr4bnhZdRCjDbGyCgpFdMmvDg7y/kUoTJL9cgyGRC G9kh47ZTQECdcI8n1vhsxnWv8KMoo3H3iVaGwMw3ZH/EGeh8nKs5q/NR6wVbWcmtzz upYukN1GAR47g== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 18:57:50 -0000 worley@ariadne.com (Dale R. Worley) writes: > Happy Eyeballs has a mess of issues surrounding UDP. > [etc.] What I'm looking for here is some feedback: Is adding one or two RTT of delay to SIP signaling a problem or not? If two RTT of additional delay is not a problem, we can be much more restrictive regarding what mechanisms we define. Dale From nobody Tue Mar 8 11:11:13 2016 Return-Path: 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 38CC812D813 for ; Tue, 8 Mar 2016 11:11:12 -0800 (PST) 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DXOhypb642i for ; Tue, 8 Mar 2016 11:11:06 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C5612D9F8 for ; Tue, 8 Mar 2016 11:11:06 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-02v.sys.comcast.net with comcast id TXAZ1s00826dK1R01XB5yg; Tue, 08 Mar 2016 19:11:05 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-01v.sys.comcast.net with comcast id TXB41s00P1nMCLR01XB57G; Tue, 08 Mar 2016 19:11:05 +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 u28JB45R018746; Tue, 8 Mar 2016 14:11:04 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u28JB41q018743; Tue, 8 Mar 2016 14:11:04 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: worley@ariadne.com (Dale R. Worley) In-Reply-To: <87twknpjqp.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 08 Mar 2016 14:11:04 -0500 Message-ID: <87ziu8kcon.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457464265; bh=hrPYxrnWLv+ah7whVldwNpe0v75G1FUotKVEFVMLBsA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=b/fjwxBca+M8wpU58JDernTT3LcbjazeAugbttSDs20z90RGmnHg0SZDt2HLR3pWv UWQks1Hy8rlNdA+XkfkgycBka7V4PkeT0DtVcBaLOJSVoG3WbxsqH7PxBhw2HoeBrQ 0swxUVBt2Ypps4fgxwpSLnZLI/WLq++Wmf5So3XsjYYk7f3Rr1Z4A9sHTTrmVbHYKO EoHhU53wBKwGqsICB0JbOq6d/Qx8Q1xVIR9qfyWNLxGy36EIMDOLpmfUsZo5Y5jcS8 JAS0m028ocH6N9MBUlrUEg78jJ18MIqk1nmpTwktv9SGLBJgw8vFkuY3QNh17G16Ul z7jl7HC83Ib4Q== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 19:11:12 -0000 worley@ariadne.com (Dale R. Worley) writes: > INVITE sip:biloxi.example.com SIP/2.0 > Route: > Route: ;group=2 > Route: > Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.2;group > Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983 > Max-Forwards: 19 > To: Bob > From: Alice ;tag=1928301774 > Call-ID: a84b4c76e66710 > CSeq: 314159 INVITE > Contact: > > In this version of the mechanism, when either request arrives at C, it > sees the group parameter on its Route header, which notifies it to > examine the indicated Via headers. If C does not support the group > mechanism, it does not know to ignore and delete the "Route: > " header, so that copy of the request will error out. > If C does support the group mechanism, it deletes "Route: > " and either responds 495 or routes the request to > bilozi.example.com. It looks like the proper thing to do is use a different address than 0.0.0.0. I think we would want to allocate an address from the 192.0.0.0/24 special-purpose block (RFC 5735, http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1). The next available address seems to be 192.0.0.10. That changes the example message to: Probably the 10.0.0.0/24 addresses should be changed to one of the documentation blocks, e.g., 192.0.2.0/24. INVITE sip:biloxi.example.com SIP/2.0 Route: Route: ;group=2 Route: Via: SIP/2.0/UDP 192.0.2.10;branch=z9hG4bKnashds8.2;group Via: SIP/2.0/UDP 192.0.2.123;branch=z9hG4bK77ef4c2312983 Max-Forwards: 19 To: Bob From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Dale From nobody Tue Mar 8 11:28:21 2016 Return-Path: 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 88E4912DA1E for ; Tue, 8 Mar 2016 11:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at6ycQMXrwdz for ; Tue, 8 Mar 2016 11:28:17 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C42E12DA1C for ; Tue, 8 Mar 2016 11:28:17 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id ig19so26125456igb.1 for ; Tue, 08 Mar 2016 11:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=W3BPRIg4AXbmygjYeoL7zkMCCb9P5dgeI/PzS6Lo5Bs=; b=qtlkXhu+8j58HkZeta9HApjaMc0W949nPnSawg2ktDhFrChiq4GPX9DZJMc7aupS8f lXqt8oaKm9wSCZpgwZCEMEbc/h1E9XXpnQer3HX6VXrftIb4fotwRGhAEz3iWx8KigtW FkjuhO1zvZu/LFh9eZoZJSuEtBOjudx07egN86E1zoBXrPCsow4Mrzlx7by9tJj4wYSd Ogzrej9duU0dupSJt8unSSNh8aE26voqxkLhZq0VipElhCTXLfZ/ZEumiSP5praQ5P4n DX21xg1J51U1tPKQ8H9ikHkx2zhhLWUG7qsIAZBJhKm94BV+n7fTXXp7bWHM7SfwUy9O rTZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=W3BPRIg4AXbmygjYeoL7zkMCCb9P5dgeI/PzS6Lo5Bs=; b=RsloSe6dXBSXz2M9sbPgj9JcSXkoJaGrk6+K8QAq7+y//tBl5FeXLR4d9JTMRU3reo 2ySj+bEs7BsjDcjtZVLlzCZWjKFKdAR5Xq+sI9W3CJV7mTSTOZsw3ZaVrqRyBqonvXFg UM8SbE2aIE14EPQIYVMKFCOmDLa2tGebvUtnIlnFPZKuXiVlgNz1T+GDtZWWfJnm8LbX +S9o/8qj+g3SDNS2NoEg76QstgqJu89K5Zn+pLiWiC9Z1W9rUr8Tc/5TPIlVUeq/tFb8 01L2RS+DVJokTIoK3Prms3D/Se1asyX8yff9gcgpwv/Nj55P/KsCmh+VAFx1oCX1mmXs 18Cw== X-Gm-Message-State: AD7BkJLEXLVt8/zlv5/WhexRh8lapwPmComEOfpvd/n3yKtNVu3bGiP5SFZmCdmyK7dtOQ== X-Received: by 10.50.155.1 with SMTP id vs1mr15255630igb.14.1457465296914; Tue, 08 Mar 2016 11:28:16 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id m9sm1689555igj.1.2016.03.08.11.28.15 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2016 11:28:15 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id vs8so55846811igb.1 for ; Tue, 08 Mar 2016 11:28:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.18.113 with SMTP id v17mr10894132igd.2.1457465294991; Tue, 08 Mar 2016 11:28:14 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 8 Mar 2016 11:28:14 -0800 (PST) In-Reply-To: <8737s0lrv9.fsf@hobgoblin.ariadne.com> References: <874mcobp0s.fsf@hobgoblin.ariadne.com> <8737s0lrv9.fsf@hobgoblin.ariadne.com> Date: Tue, 8 Mar 2016 14:28:14 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=089e01494ff22e4eab052d8e9521 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 19:28:19 -0000 --089e01494ff22e4eab052d8e9521 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 1:57 PM, Dale R. Worley wrote: > worley@ariadne.com (Dale R. Worley) writes: > > Happy Eyeballs has a mess of issues surrounding UDP. > > [etc.] > > What I'm looking for here is some feedback: Is adding one or two RTT of > delay to SIP signaling a problem or not? If two RTT of additional delay > is not a problem, we can be much more restrictive regarding what > mechanisms we define. > I have mentioned in my earlier email if UDP is replaced by TLS or TCP, then it needs to be used in conjunction with SIP Outbound. For SIP Outbound the initial flow setup or flow recovery adds more then two RTT. One of the common application flows would be to wait for a new call notification which is sent using a push notification such as Apple Push or Android Push to a mobile device. Once push notification is received, mobile device needs to place a call and pick up the inbound call from the proxy. For this, mobile device needs to establish a TLS connection to the edge proxy (3.5 RTT), send a registration message to get GRUU (2RTT, first to get nonce, second to register and get GRUU), and then place the call over the flow (0.5 RTT). Same delay applies to call recovery if flow gets disconnected for any reason such as edge proxy failure or local IP address loss. Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT depending on device having a recent nonce for authentication. Regards, _____________ Roman Shpount --089e01494ff22e4eab052d8e9521 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2016 at 1:57 PM, Dale R. Worley <<= a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
worley@ariadne.com (Dale R. = Worley) writes:
> Happy Eyeballs has a mess of issues surrounding UDP.
> [etc.]

What I'm looking for here is some feedback:=C2=A0 Is adding one or two = RTT of
delay to SIP signaling a problem or not?=C2=A0 If two RTT of additional del= ay
is not a problem, we can be much more restrictive regarding what
mechanisms we define.

I have mentioned = in my earlier email if UDP is replaced by TLS or TCP, then it needs to be u= sed in conjunction with SIP Outbound. For SIP Outbound the initial flow set= up or flow recovery adds more then two RTT.

One of= the common application flows would be to wait for a new call notification = which is sent using a push notification such as Apple Push or Android Push = to a mobile device. Once push notification is received, mobile device needs= to place a call and pick up the inbound call from the proxy. For this, mob= ile device needs to establish a TLS connection to the edge proxy (3.5 RTT),= send a registration message to get GRUU (2RTT, first to get nonce, second = to register and get GRUU), and then place the call over the flow (0.5 RTT).= Same delay applies to call recovery if flow gets disconnected for any reas= on such as edge proxy failure or local IP address loss.

Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT depe= nding on device having a recent nonce for authentication.

Regards,
_____________
= Roman Shpount
=C2=A0
--089e01494ff22e4eab052d8e9521-- From nobody Tue Mar 8 12:06:58 2016 Return-Path: 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 AA8B312DA5A for ; Tue, 8 Mar 2016 12:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRY2dwsxij15 for ; Tue, 8 Mar 2016 12:06:56 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0D012DA4E for ; Tue, 8 Mar 2016 12:06:56 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id ig19so61076011igb.0 for ; Tue, 08 Mar 2016 12:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=y4E0gAEHlwe9excEHIzZYMSWUlAgiNnFotwWNo6bV9Y=; b=1IV2Tpjrc1jB670g4d3zj7OkQzMwewGRHx8BPyF2mKWPjZ7DcaYROdkpqepJENNeCd Eii3t19GPjgd5ivAyivhrxJ2ZfK4jlhO0V/GAUYoIGT0/AZUMTS2YGtP9ucyV0FAPflE GphwhXV/Xhzrr8g0ojDolmP750C8aPrh7jmH1LiulNg10NDlVQ2J0cUd09I5Wh3CoMBJ 06fU88DericA4BUfxFo52IYxLxmTZnN74qOlZK+P2tSyFCxP5yjDwguCnMf1bF73O9tA mTBAonBlPGw+HpItbHw6uADzyIQ+mz8ZCNPsvCFGwm3NHKnywWlhGu7e/Xrp4Ck5m8zJ TyBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=y4E0gAEHlwe9excEHIzZYMSWUlAgiNnFotwWNo6bV9Y=; b=f2q9w33oTHMv5RIWKpxkN7stiXvtnFf5+jjmhtjbHapK4bZbsscRjlBMCzNBcm0es6 mUUkTsa8E8jPDO+8PFls81YwxRJD/rqLnDquKMebwFlE3z7P9Nmk2tetvEmHmItixVG8 RWJzi3GdOh9YsLuoz8yv8VimVOjg8BsLycmN4RSbkV9/DXF0xH5FWyWO8vYwhX8vssWY fwojEJsyt1B45mTIi1JzYvpBt91HmMthin0WsAbxchKvvnp64OFyO8CFLFkw52ptMi59 Fx7MjeSDfoKqo0gyA7VRXjGE/ZZdtuLs46xoDO4Vn2tOBIiJFxHfHe+KKvERMQk4QTyw aGzw== X-Gm-Message-State: AD7BkJJ7Q1bfCoCAzogcjbb7SPFMcBYTzH6OgbcgeWmdlLLEDdwPFD/d1kuraJ16AKlcuA== X-Received: by 10.50.70.39 with SMTP id j7mr20172143igu.40.1457467615333; Tue, 08 Mar 2016 12:06:55 -0800 (PST) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com. [209.85.213.175]) by smtp.gmail.com with ESMTPSA id x9sm1730121igg.17.2016.03.08.12.06.53 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2016 12:06:53 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id vs8so56650985igb.1 for ; Tue, 08 Mar 2016 12:06:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.43.194 with SMTP id y2mr20294518igl.96.1457467613053; Tue, 08 Mar 2016 12:06:53 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 8 Mar 2016 12:06:52 -0800 (PST) In-Reply-To: <56DEF90C.80105@alum.mit.edu> References: <56DDBB10.6050909@alum.mit.edu> <56DEF90C.80105@alum.mit.edu> Date: Tue, 8 Mar 2016 15:06:52 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bfea0b65914da052d8f1f5e Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP TLS issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 20:06:57 -0000 --047d7bfea0b65914da052d8f1f5e Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 11:08 AM, Paul Kyzivat wrote: > Then what is the solution for security. ISTM that people are finally > realizing that it is important. > You would be surprised -- most of the hosted PBX users do not care or understand the security related issues. Most of them run their IP phones with default passwords. > Is this for the stupid people market? > You might think that but I couldn't possibly comment. I would suggest you lookup SIP configuration settings for any large Hosted PBX provider and draw your own conclusion. I cannot think of one of them using SIPS. The question we need to ask is should we help there providers to transition to IPv6 or should we try to force them to solve their security issues first? Keep in mind that current solutions for security related issues will cost those providers substantial amounts of money and their customer do not care enough about security to pay extra for it. _____________ Roman Shpount --047d7bfea0b65914da052d8f1f5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2016 at 11:08 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
Then what is the solution for security. ISTM that people are fina= lly realizing that it is important.

You= would be surprised -- most of the hosted PBX users do not care or understa= nd the security related issues. Most of them run their IP phones with defau= lt passwords.
=C2=A0=C2=A0
Is this for the = stupid people market?

You might think t= hat but I couldn't possibly comment. I would suggest you lookup SIP con= figuration settings for any large Hosted PBX provider and draw your own con= clusion. I cannot think of one of them using SIPS.

The question we need to ask is should we help there providers to transitio= n to IPv6 or should we try to force them to solve their security issues fir= st? Keep in mind that current solutions for security related issues will co= st those providers substantial amounts of money and their customer do not c= are enough about security to pay extra for it.
_____________
Roman Shpount
=C2=A0
--047d7bfea0b65914da052d8f1f5e-- From nobody Tue Mar 8 13:52:09 2016 Return-Path: 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 6B09012DB26 for ; Tue, 8 Mar 2016 13:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUWsoEMCA-eE for ; Tue, 8 Mar 2016 13:52:07 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32E612DB25 for ; Tue, 8 Mar 2016 13:52:06 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-11v.sys.comcast.net with comcast id TZqw1s0012Fh1PH01Zs6PT; Tue, 08 Mar 2016 21:52:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id TZs51s00B3KdFy101Zs5FE; Tue, 08 Mar 2016 21:52:06 +0000 To: Roman Shpount References: <56DDBB10.6050909@alum.mit.edu> <56DEF90C.80105@alum.mit.edu> From: Paul Kyzivat Message-ID: <56DF4985.3010102@alum.mit.edu> Date: Tue, 8 Mar 2016 16:52:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457473926; bh=0yGFIb+JzvXwun2KH9w9++ZS3P4biyT5ozsufb8xp+A=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=iDoTQkg2jeYpYhXlcX5sBB6gy26J73GF9DbWsXXIjJFroyislsNhsTRa5ocrv12oe LW0btVYa6h7tDjkwxVSj0rAgf711Wk56w9VBGA2mBGsZUTz3nZukuy8SgZotVcU6QC PtXlZFIqmv0IcaV9YRwPDcMTkLY2POIeTJHO3eym0ppYt8ezgaMGdbq/YorhZeXe3V o0eDLSzDUxImHCOB+3azTQgi0rC5cQIS5/c9lrO4tBagj9THRwWcupcqW65QnbA284 TikCclJPkxQ8f0grionCKloTUbDLwaVFE3wK9jlEYh2IgOq+Vg/mKvKiqxP0xzAJBl wvqRABNSKCXfw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP TLS issues X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 21:52:08 -0000 On 3/8/16 3:06 PM, Roman Shpount wrote: > On Tue, Mar 8, 2016 at 11:08 AM, Paul Kyzivat > wrote: > > Then what is the solution for security. ISTM that people are finally > realizing that it is important. > > > You would be surprised -- most of the hosted PBX users do not care or > understand the security related issues. Most of them run their IP phones > with default passwords. I can "sort of" understand doing this behind a corporate firewall. I guess that would extend to hosted, if that was over a VPN. Otherwise this is dubious at best. > Is this for the stupid people market? > > > You might think that but I couldn't possibly comment. I would suggest > you lookup SIP configuration settings for any large Hosted PBX provider > and draw your own conclusion. I cannot think of one of them using SIPS. Sorry for sounding disrespectful. (I didn't mean you. I was intending to pass comment on all who don't seem to care.) SIPS is another story. It is kind of a mess. But TLS without SIPS is possible. > The question we need to ask is should we help there providers to > transition to IPv6 or should we try to force them to solve their > security issues first? Keep in mind that current solutions for security > related issues will cost those providers substantial amounts of money > and their customer do not care enough about security to pay extra for it. I suppose that is fair. OTOH, we are losing an opportunity to bundle stuff that people should do if they weren't so cheap with other stuff they are more motivated to do. A lot of work went into outbound. It is complicated, but was the best anybody could find that could provide security for the last hop for those who don't have a certificate. If we knew an easier way we would have specified it. Thanks, Paul From nobody Tue Mar 8 16:48:47 2016 Return-Path: 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 5950C12DCCF for ; Tue, 8 Mar 2016 16:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE4I6Fj1Fpkh for ; Tue, 8 Mar 2016 16:48:44 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2B212DCD5 for ; Tue, 8 Mar 2016 16:48:44 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e6so38253435vkh.2 for ; Tue, 08 Mar 2016 16:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=JCS4RYKDGBIZ+oEtrNW5mZRYiE66G7bOGHUvF7+uaCE=; b=z6O9EMJpQPs+9BE2fEcro3bGbZmsadU7zrVhFWw+77vdzhoL+bVf0jCsr7O2wCBSTG j1lFJDGWXwGoObyV8ADCIAdhc+GMn89eXL5bp09eXmQc1pxnN1zD1fBaao5n87KgGDdm MwmOa7CzM4ttWW3S3+Cv9rcDT3S4Ix62fWqDwpl1z6y7wZw/wWz0VL/aGRAileF+EGr1 LfQChSiSddRj03AM8vR3ahZTI+dt2LR3YuiAU9vANozI5jyvtEroE0Xd6R7vCwLhvJqm gacUe+g/2gYJ+SUNA2wF3aeJaKoo6uNjGaub5UBM1venC3/7F5JYiILp3wdAu1M4B4Su 9f+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=JCS4RYKDGBIZ+oEtrNW5mZRYiE66G7bOGHUvF7+uaCE=; b=MnisTUTd4E4i0IfNsS3xLMRKXzbudPsM6E7xMCQkAG4+RDuad8FOVHqACFQK3us4Xo 06pQZWJ8C5DO440JD/t00MO3ZBrOs2uKCdpUpiYFPlPS/LCqmZT1ryFZeIUSiqOnYROI 8somqakLjJoOCF18vZCoYXtKKZIalWyIn7W+/qKki5T/2dHzu6Kkl9s4dCqzIclY6FBc TnqanChw1bk4uois3sQhZ8w/lSWJWZPL5+aXV/Gr5bbZiYi31VbhKxXI7GTpIoI41ory Ad8f1Oep6xfSqyeae7h3xukj6PFMJJArnE8ku79+J1RLRkxtiQZg5QNcKHLBbIKvRUaE a/nA== X-Gm-Message-State: AD7BkJL7vYTYYvN/B3UdFTgLOxVZIOtZdr3clz8GE/RQ4NQzXX9/wpxL0Ym9kXo8jbZAkNiQBvygfsUQeAut5w== MIME-Version: 1.0 X-Received: by 10.31.155.131 with SMTP id d125mr24508920vke.146.1457484523627; Tue, 08 Mar 2016 16:48:43 -0800 (PST) Received: by 10.159.38.38 with HTTP; Tue, 8 Mar 2016 16:48:43 -0800 (PST) Date: Tue, 8 Mar 2016 19:48:43 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a113d391c4bec05052d930f61 Archived-At: Subject: [sipcore] SIP OAuth - Use Cases X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 00:48:46 -0000 --001a113d391c4bec05052d930f61 Content-Type: text/plain; charset=UTF-8 Hi, We have submitted a new version of the SIP OAuth document, and added few more use cases as described in section 1.3. http://www.ietf.org/id/draft-yusef-sipcore-sip-oauth-03.txt We would appreciate any feedback on these use cases. Regards, Rifaat --001a113d391c4bec05052d930f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We have submitted a new version of = the SIP OAuth document, and added few more use cases as described in sectio= n 1.3.


We would a= ppreciate any feedback on these use cases.

Regards= ,
=C2=A0Rifaat
=C2=A0
--001a113d391c4bec05052d930f61-- From nobody Wed Mar 9 09:37:31 2016 Return-Path: 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 8867A12E0AC for ; Wed, 9 Mar 2016 09:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqzw8bLKo5Uo for ; Wed, 9 Mar 2016 09:22:01 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485CD12DFED for ; Wed, 9 Mar 2016 09:19:14 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-12v.sys.comcast.net with comcast id TtJ41s0022LrikM01tKDP4; Wed, 09 Mar 2016 17:19:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id TtKD1s0013KdFy101tKDRM; Wed, 09 Mar 2016 17:19:13 +0000 To: sipcore@ietf.org References: <874mcobp0s.fsf@hobgoblin.ariadne.com> <8737s0lrv9.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <56E05B10.70109@alum.mit.edu> Date: Wed, 9 Mar 2016 12:19:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457543953; bh=xckquNKngHCVsI805eRV/OPE/BtZKiNhTMPWru6v0Z8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=F6TFBl4g/7OPFxx2chI5L3loI5WalZhzGnXLDKRLV6uTngwvOPM48igjwaEdn6i2Y 6HFQtkYVZ5i9SaLosJZk1r1DCTbkYd0nUw5YE2CcUnnzhLWWvh71Zyo4H+UpaIm8Jh CKLJTlQIy4kFKzLkrspwBz+bpfBeVsZBJXe7vpBX6gmruBvMUCZtVW3lNlXt8zwheu TxI6XfTcoRHAv0Sm6JkwqnxBzSqlAZ3v+8/MEEvxeUqC+t+cSIfTy7AHab19A8dJaO LV7SFGFKlO6lXJ7E5Yhm8XVS8OHMu0dfUGX1S5tH+mv3UmeQ28G2U8rwsKWoyOEm5r rn6vocSmUNqwQ== Archived-At: Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:22:10 -0000 On 3/8/16 2:28 PM, Roman Shpount wrote: > On Tue, Mar 8, 2016 at 1:57 PM, Dale R. Worley > wrote: > > worley@ariadne.com (Dale R. Worley) writes: > > Happy Eyeballs has a mess of issues surrounding UDP. > > [etc.] > > What I'm looking for here is some feedback: Is adding one or two RTT of > delay to SIP signaling a problem or not? If two RTT of additional delay > is not a problem, we can be much more restrictive regarding what > mechanisms we define. > > > I have mentioned in my earlier email if UDP is replaced by TLS or TCP, > then it needs to be used in conjunction with SIP Outbound. For SIP > Outbound the initial flow setup or flow recovery adds more then two RTT. > > One of the common application flows would be to wait for a new call > notification which is sent using a push notification such as Apple Push > or Android Push to a mobile device. Once push notification is received, > mobile device needs to place a call and pick up the inbound call from > the proxy. This is a common application flow? I'm not aware of this being a standard usage of sip. > For this, mobile device needs to establish a TLS connection > to the edge proxy (3.5 RTT), send a registration message to get GRUU > (2RTT, first to get nonce, second to register and get GRUU), and then > place the call over the flow (0.5 RTT). Same delay applies to call > recovery if flow gets disconnected for any reason such as edge proxy > failure or local IP address loss. > > Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT > depending on device having a recent nonce for authentication. I understand that this is very "traditional". It would also never get past a security review these days. If we have no secure solution that is deployable in practice, then I guess we ought to be setting up an effort to come up with one. Maybe the answer is "use webrtc". Thanks, Paul From nobody Wed Mar 9 10:35:18 2016 Return-Path: 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 C8E7512D8D3 for ; Wed, 9 Mar 2016 10:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35MPkg8fKzpD for ; Wed, 9 Mar 2016 10:35:14 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E025812D8E9 for ; Wed, 9 Mar 2016 10:27:50 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id m184so76640353iof.1 for ; Wed, 09 Mar 2016 10:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8L5vP2OnVwGLhvG226RsMGJkaCCdUE27nNsYRgHMl8I=; b=CwqY1aYSUWnHN7LFdwKcCQRpoH3OuI74fwrrTo3jyBXUIY9X4rAuIvlIOTnZY2ckbW A5Cc1HEbANhoiy1UtFBe1skJsvaCY6kabLu7KjssytBVapOw8CA0zRalkQn0o7IAmnr7 W/L9rD4fVuu34WDCoNDAQ0cMirBHkXyF0Pp1EYcAq5737e56FB6ydQBjAyA3oy/JC7F5 il6T2e7P/enm8lsZXKIIG27vioxdQPZxLXDE8E8dEvr9iHM0mizvJUw3OgMVkHi3EehH KgYGbaREErwjdyvjalgEjz6Z5qVjQu/Q3PhoYg9Da86c2otvQM8KOhUax/cR+Or76B3d 03KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8L5vP2OnVwGLhvG226RsMGJkaCCdUE27nNsYRgHMl8I=; b=gcaeu/3PAKral8g0dIUI7gMXwTNMYqIDM22vfA5UqoDHVvw9DE713H+3tANdI9G9vh NcP+CXjs9TWo/YFjIecUAgohQLnRmirFsP5JGAEvl2XUjZgMBNBA6Vr9ZTkSPbVX07+7 LkYfjR/93z6DcwlDB0yH50npxu8KN3YpcQYtxoC/LC07BrpxUq4+RjKvXynFaqp4g/KG Ln9jKTAQAi5wwIXLRa6/5gNcyzPDcp6/1EEpegB507JtGfnbTRgltQkxCpECkh3fnrSs krUcIj0H07O6pTv0cQXcf1KfFer5huFpfbmVYLINyPVhi0sE0BXrsoU3w+eo1fJT8Gjk UnIg== X-Gm-Message-State: AD7BkJJuoRbpKxSsnSTwhyPzQxvu3vFjVhQTOhTklgF9+EX1ZVTY4tAE8h8bH/9hC0S04Q== X-Received: by 10.107.5.149 with SMTP id 143mr596579iof.129.1457548070123; Wed, 09 Mar 2016 10:27:50 -0800 (PST) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id z18sm3476766igp.20.2016.03.09.10.27.48 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 10:27:49 -0800 (PST) Received: by mail-io0-f181.google.com with SMTP id m184so76639340iof.1 for ; Wed, 09 Mar 2016 10:27:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr569746ioe.38.1457548068522; Wed, 09 Mar 2016 10:27:48 -0800 (PST) Received: by 10.36.106.194 with HTTP; Wed, 9 Mar 2016 10:27:48 -0800 (PST) In-Reply-To: <56E05B10.70109@alum.mit.edu> References: <874mcobp0s.fsf@hobgoblin.ariadne.com> <8737s0lrv9.fsf@hobgoblin.ariadne.com> <56E05B10.70109@alum.mit.edu> Date: Wed, 9 Mar 2016 13:27:48 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140b472de1ed7052da1da40 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 18:35:16 -0000 --001a1140b472de1ed7052da1da40 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 9, 2016 at 12:19 PM, Paul Kyzivat wrote: > On 3/8/16 2:28 PM, Roman Shpount wrote: > >> One of the common application flows would be to wait for a new call >> notification which is sent using a push notification such as Apple Push >> or Android Push to a mobile device. Once push notification is received, >> mobile device needs to place a call and pick up the inbound call from >> the proxy. >> > > This is a common application flow? > > I'm not aware of this being a standard usage of sip. This is not completely non-standard either. SIP here is only used to actually place the call. SIP registration is replaced by the platform native push functionality. This flow has an upside of reducing the server load on the provider side (no idle registration connection waiting for inbound calls) and reducing power usage on the client side (no idle registration connection waiting for inbound calls or and CPU does not need to periodically wake up to send a keep alive). For this, mobile device needs to establish a TLS connection >> to the edge proxy (3.5 RTT), send a registration message to get GRUU >> (2RTT, first to get nonce, second to register and get GRUU), and then >> place the call over the flow (0.5 RTT). Same delay applies to call >> recovery if flow gets disconnected for any reason such as edge proxy >> failure or local IP address loss. >> >> Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT >> depending on device having a recent nonce for authentication. >> > > I understand that this is very "traditional". > > It would also never get past a security review these days. > > If we have no secure solution that is deployable in practice, then I guess > we ought to be setting up an effort to come up with one. > > Maybe the answer is "use webrtc". > WebRTC might be the answer. Since there is a lot of effort is already being spent to optimize HTTP request processing and to reduce the number of round trips required to get HTTP response, there is no reason not to reuse this work. Unfortunately this still leaves the question of what to do with all the existing IP phones deployed with hosted PBXs. They would need to be migrated to IPv6 sooner rather then later. _____________ Roman Shpount --001a1140b472de1ed7052da1da40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2016 at 12:19 PM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 3/8/16 2:28 PM, Roman Shpount wrote:
One of the common application flow= s would be to wait for a new call
notification which is sent using a push notification such as Apple Push
or Android Push to a mobile device. Once push notification is received,
mobile device needs to place a call and pick up the inbound call from
the proxy.

This is a common application flow?

I'm not aware of this being a standard usage of sip.
<= br>
This is not completely non-standard either. SIP here is only = used to actually place the call. SIP registration is replaced by the platfo= rm native push functionality. This flow has an upside of reducing the serve= r load on the provider side (no idle registration connection waiting for in= bound calls) and reducing power usage on the client side (no =C2=A0idle reg= istration connection waiting for inbound calls or and CPU does not need to = periodically wake up to send a keep alive).

For this, mobile device needs to es= tablish a TLS connection
to the edge proxy (3.5 RTT), send a registration message to get GRUU
(2RTT, first to get nonce, second to register and get GRUU), and then
place the call over the flow (0.5 RTT). Same delay applies to call
recovery if flow gets disconnected for any reason such as edge proxy
failure or local IP address loss.

Without SIP Outbound with UDP both scenarios take 0.5 or 1.5 RTT
depending on device having a recent nonce for authentication.

 I understand that this is very "traditional".

It would also never get past a security review these days.

If we have no secure solution that is deployable in practice, then I guess = we ought to be setting up an effort to come up with one.

Maybe the answer is "use webrtc".

=
WebRTC might be the answer. Since there is a lot of effort is already = being spent to optimize HTTP request processing and to reduce the number of= round trips required to get HTTP response, there is no reason not to reuse= this work.

Unfortunately this still leaves the qu= estion of what to do with all the existing IP phones deployed with hosted P= BXs. They would need to be migrated to IPv6 sooner rather then later.
=
_____________
Roman Shpount
=C2=A0
--001a1140b472de1ed7052da1da40-- From nobody Thu Mar 10 06:20:48 2016 Return-Path: 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 B1C3E12D963 for ; Thu, 10 Mar 2016 06:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 n63UU1UCsEgm for ; Thu, 10 Mar 2016 06:20:46 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2878412D977 for ; Thu, 10 Mar 2016 06:12:56 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id z8so18965999ige.0 for ; Thu, 10 Mar 2016 06:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=LPSgXQMdvTl3yHzFO7qfArgDDOKjdilmDMl4c3WTxMo=; b=THv4PfmW2DT5fwjDZg5y73TAAmkeme4h75nZCKfvwaCvL7QrZXjkBCpxmO/s9xtVq3 lifiCjBhr1VeIUZELucLvHjMevSI+6f8iITlItd9KMy/JV1J5kz9aEfvjGVtAodgJ0H7 HtwRZpkxf38fcPQq7CcLMv3q7EYXwmd4TpjCgtqMD9UWQOhJ0UIZOJF1UuEH6cav+On9 al75aMHpiKAREallXUJRnx43M5LEdrWcYhPvowHtXmA9fhs35usF4R9xR+L7nJSH84tl Tv0NUin1wU2Ll14XFKXZjn+Inp1lAvFwdijyd46IpGvmO9TX7CKQ0kGN1/EA166xZcfN 2qgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=LPSgXQMdvTl3yHzFO7qfArgDDOKjdilmDMl4c3WTxMo=; b=VE21HbC3ODbUcAbycLP3/xvEt36MCSmkxL1qa/Dt+qz4GwXkm6x/wPyCjaTH9rQ46K aZyuUMYBGaacZiO4gfJvFQUxN8WmiL1pwx5/OId5ngthyQzDK4Pa9nq7AgU4qGMEMuNQ Y1xTb4MtXYYH0FN7JPMjvDF+9BkAzovePLBB3X2MYsQTbY4XoNMaNm803Tc3+uR7ePIr ep3QNCYgJBy1jJH5FnHayaZAzyJIyLREhpr+39PGLMYOdmTmKpH4YFQd0A2Idj+ZGo2L 5WKSdDh0RoLK4845rqM4WnZ9ojv4ibXXwpPx2nqWt4AA0ivnGOIZ+/NI36NPYpfulQDi Dv1A== X-Gm-Message-State: AD7BkJJnZ/woIf/snUt4yQmt7AyIPE+6MEX5iaRmn98tdLzrjw6Rrh5s4KTciNie6rRpTy1bcCNGiXEgxi/emMNe X-Received: by 10.50.43.133 with SMTP id w5mr3767979igl.80.1457619175453; Thu, 10 Mar 2016 06:12:55 -0800 (PST) From: Brett Tate References: <874mcobp0s.fsf@hobgoblin.ariadne.com> In-Reply-To: <874mcobp0s.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF94OISMYiLYwWW+iGuSJQeawijM5/55zZA Date: Thu, 10 Mar 2016 09:12:54 -0500 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 14:20:47 -0000 > BTW, looking at RFC 6555 section 4, I see: > Am I misunderstanding this? Item (1) says that there is > a delay between initiating an IPv6 connection and > initiating an IPv4 connection, but the text at the end > says that they are initiated simultaneously. I agree that the text is contradictory. Section 5.5 indicates that stateful algorithms can more aggressive than the recommended 150-250 ms delay; however it still recommends "connection attempts be paced to give connections a chance to complete". From nobody Thu Mar 10 11:17:02 2016 Return-Path: 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 AB7E512DB80 for ; Thu, 10 Mar 2016 11:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 NIDSc-tA3D_T for ; Thu, 10 Mar 2016 11:17:00 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D2C12DABB for ; Thu, 10 Mar 2016 11:16:59 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id vs8so329163igb.1 for ; Thu, 10 Mar 2016 11:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=AYQkrISee8xVuE8Db5Lywh2jNA4ilZizxmTq33VE9E0=; b=h7WhGkuO1hmODW2xHCzWwicDB1RX7MaORvGlUgoP2MFQdMhcQUxfZ/jTbyLRvKSqC3 fB8UL/Zp2AqmJbiBPZQcIDGrDyqer9bv+5lZG1VH8JffKTx2Ki6IPmeFRxLzOQekK32r uCpBde1B37oDRMhacmHZGJzOUj70S+/hdPxqZM5vIfH/HFFUmptB/TU8reycsT+cBIr0 VzBAgxjQ59h4J3RbvMl8/JogKpQodk59kvoeF3upGqRhp2JVCWlFtRaVOmKcZO7Djag+ 8N2P4FA/qIy9w/04sgUBj8/0Gozy1nz/NVjcfbto/k64ofxeaZfrDZ9PD/+6xKcLASmX Nv+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=AYQkrISee8xVuE8Db5Lywh2jNA4ilZizxmTq33VE9E0=; b=jMpu62u6jQ6jpGAt7xqk7i5+sux6WLEAPIfvJF2Yfmrp5yljozwtqEX1/WToSnJy61 OW4TuH8yZGtxq6xbyRgx48q/vwushq0rpEG8llhmIv7Wf/W5NV82kGXL72cXtOzdgqWE D8YsLderJtLU2uF82TCqUVuxmdSnE4TY7sUJjWRo2R3kozaSJ4W5lHW/bcy52GPYiEQc uOwkEXDLzSWkN6tUXmSgQhKbSeMc5cj6ybDNFVsmfYm3ADaOqlT4qidkJusG6M3GKnkQ RJob4Y+Bh31/IpwMYtfgFPD20zhuzSUG0Uo1jGplaixv1IwHsWmO9f68FBpa8lbPikKZ HgPw== X-Gm-Message-State: AD7BkJJUjAWDHSG8sVA232wOBkHhJtG3gs71h/Yq0F+r6H3A2DaDK93q+C1tUrybo3eu0+cvn/ZPy4aH1rPW/P7z X-Received: by 10.50.61.232 with SMTP id t8mr5707766igr.83.1457637419247; Thu, 10 Mar 2016 11:16:59 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdF7AWE/2ZqSVk/zTg2Jb/qyGLeJ+w== Date: Thu, 10 Mar 2016 14:16:58 -0500 Message-ID: To: "Dale R. Worley" , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:17:01 -0000 > > Happy Eyeballs has a mess of issues surrounding UDP. > > [etc.] I agree. In addition to the issues that have already been raised, the solution potentially would need to update RFC 4320 concerning sending 100 over UDP for non-INVITE. > What I'm looking for here is some feedback: Is adding > one or two RTT of delay to SIP signaling a problem or not? > If two RTT of additional delay is not a problem, we can be > much more restrictive regarding what mechanisms we define. It likely depends upon the reason and frequency. The draft-ietf-sipcore-dns-dual-stack recommendation already has the potential to double the amount of time it takes to advance from primary to secondary when primary is down. For example, trying primary AAAA and A before advancing to SRV record for secondary which also has AAAA and A. Hopefully, the Happy Eyeballs resolution allows hitting the forth location (secondary A record) within an acceptable amount of time. And hopefully the Happy Eyeballs resolution doesn't introduce too much extra traffic. From nobody Fri Mar 11 15:06:15 2016 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0E12DDCB; Fri, 11 Mar 2016 15:05:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230529.15028.93012.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:29 -0800 Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org Subject: [sipcore] sipcore - Requested session has been scheduled for IETF 95 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:29 -0000 Dear Adam Roach, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. sipcore Session 1 (1:00:00) Friday, Afternoon Session I 1220-1320 Room Name: Buen Ayre C size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: netvc xrblock webpush stir mmusic rtcweb avtext perc avtcore dispatch Special Requests: --------------------------------------------------------- From nobody Wed Mar 16 10:40:24 2016 Return-Path: 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 345E512D544 for ; Wed, 16 Mar 2016 10:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NC1fS9rntA8M for ; Wed, 16 Mar 2016 10:40:20 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FE512D596 for ; Wed, 16 Mar 2016 10:40:18 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-03v.sys.comcast.net with comcast id WhfL1s0032AWL2D01hgHEj; Wed, 16 Mar 2016 17:40:17 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-04v.sys.comcast.net with comcast id WhgG1s00P1nMCLR01hgGyY; Wed, 16 Mar 2016 17:40:17 +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 u2GHeF31016216 for ; Wed, 16 Mar 2016 13:40:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2GHeFGb016213; Wed, 16 Mar 2016 13:40:15 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 16 Mar 2016 13:40:15 -0400 Message-ID: <87y49i9v9c.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458150017; bh=lFx/a8fmMLu0jlDPGJ5tao0Cp0i3Y7r/iob5m4TdDIA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=J6C+G2PgkgKz1lx5blP++GXUgBY6SSov9SZGTQRtJ3rkWC0ZWKWsTvVMoTpZ6rViv AHYvqMIQ2UJrS6PMwPxieP4jm9JivEqdEiKqBmie5OYg5El1PPoBw9as3j5WLzM5v3 AjDlpb6WhhtvkF6OrDrN6xSPv0jK3FdxD18p7LellYwCxwk1a4umEfdJlc/dMmIlqX Qpg6Ig9N50SeuGdnqhCVagoNXHd4y//YoOUc8nzwj3BZkIoxu+2kZC2RaVCl6mzwIG HWo5f2EHNYKGk30jBZkuP03LdSqRqDt9kO/vP1SUtRKpYpUb7MK7+a1TKqudRfSOmq KJLT1tC1ysbPg== Archived-At: Subject: [sipcore] "Roman's problem" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 17:40:22 -0000 Going over Roman's messages regarding hosted PBX systems, I want to isolate that usage situation from the rest of Happy Eyeballs. It seems like the problems there are seperable from what Happy Eyeballs needs to solve. No doubt SIP endpoints in a hosted PBX situation need Happy Eyeballs also, but rapid failover does not involve the endpoint trying alternative transport destinations. (Happy Eyeballs is involved in the endpoint selecting a transport destination to contact initially, but presumably H.E. will allow the endpoint to continue to use that one destination as long as it is responding.) I've extracted parts of a number of messages that characterize the situation and put them at the end of this message. The summary of the situation seems to be: ---------- Failover is done by moving the edge-proxy IP address to the backup endge proxy and using a protocol without connection state, i.e., UDP without DTLS. The registration state is stored in a database shared by all edge proxy instances. There need be no dialog state in the edge proxies, and transaction failure during failover is acceptable. Digest authentication nonces can be constructed to be verifiable by any edge proxy. NAT traversal is handled by NAT compensation done by the edge proxy rather than ICE (thus keeping messages small enough for UDP). The unsolved problem is security: - message integrity - message privacy without requiring connection state. ---------- Nonces can be constructed by the edge proxies in a way that doesn't require connection state to check their validity. E.g., nonce = T || R || H(T || R || PK) where T = timestamp R = random value PK = private key known by all the edge proxies Security seems to be more of a problem in that all of the security protocols I know of require connection state. However, it shouldn't be difficult to construct an adequate security protocol. E.g., assuming the phone and the proxies have a shared key SK for a user identity U, one could encrypt a message via: encrypted message = "@" || U || MD || E(MK, message) where message digest (MD) = H(message) message key (MK) = H(U || MD || SK) U = fixed-length user identity "@" is chosen as a flag because no SIP message can begin with "@" That should provide sufficient message integrity and privacy. Or more likely, a considerably better scheme could be devised by someone who knows encryption algorithms. But we only need a stateless security mechanism that's much better than Digest authentication. Dale ---------------------------------------------------------------------- I know a lot of implementations for UDP which handle 1M+ of concurrent registrations. For UDP you can move the IP address for the edge proxy to a different server. If registration and flow state is in some sort of shared DB, the fail-over occurs naturally for both the client and server. Happy Eyeballs is needed to address situation where you have large number of end user devices located on multiple customer networks with different capabilities trying to connect to a central public service which is accessible over both IPv4 and IPv6. The point I am trying to make that all of such SIP services primarily use UDP so it is too early to discard it. The obvious problems here are: 1) security 2) large sip messages and UDP message fragmentation DTLS is not an answer either since encryption state will need to be failed over with the edge proxy. What you need is a protocol where client can recover a flow to the server, including encryption, using a single round trip. I think deployments of large numbers of SIP devices connected to the public service (like SIP based Skype) never happened and will never happen because of the complexity and design issues of SIP Outbound in combination with TLS. I think this is why none of the large scale consumer VoIP applications used SIP. The companies that built these products used RTP, ICE and media components, but SIP was ignored. I do not think all these companies spent all the design effort to build something completely new just because they wanted to build something different. From my experience with couple of similar projects the issues of scaling the deployment and handling redundancy were the main driving factors. Putting aside all the problems with SIP Outbound, there are still a lot of companies which offer SIP over UDP to the end users. I am talking about all the hosted PBX solutions. Most of these deployments do not use ICE and use host based NAT traversal for signaling and media to keep the message size small. This is not a solution you would design if you have started the design from scratch, but these installations definitely need a migration path from IPv4 to IPv6. Telling them to switch to SIPS with SIP Outbound is unrealistic, so I believe Happy Eyeballs must provide the solution for UDP. From nobody Wed Mar 16 11:09:04 2016 Return-Path: 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 3C32312D63E for ; Wed, 16 Mar 2016 11:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 T6CnfIImmWhd for ; Wed, 16 Mar 2016 11:08:51 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0584412D53C for ; Wed, 16 Mar 2016 11:08:51 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g203so69272878iof.2 for ; Wed, 16 Mar 2016 11:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sc5jDAdDr6h2CXTEZCs89rUuP/RfIM3LB15v5aHkQng=; b=HxF88qLibHrAWPWRMO/0O8gpORQUUFikqQ4Y77MwfFbNYQ4EBx7ZBju+Myl78YUMor mEJwdh8yZCcy7umMvWEzDfOc0Ija4Liy0WCkjzLmzOwd5bJL59cRzZjhuWIZ5Oae8qoC HOyR3lt71T5+gVEzb3UyN314mpbzuRwQYtjAxaX0Yqd77SgvGVAPzmaqAzTe9q4NRkA/ WX8DmK8INOFqKOaLxdQN8cMQmtYwNSfo53CZSBJARLYbvSzVYYsRsU2MnhnUKwWgKu37 xS5P0rjRJ9qz+RISh+ACsby/GioEsH07dNOEgg0YJfhkD8ecPAn+l9o0hTNePtffzzwm q5hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sc5jDAdDr6h2CXTEZCs89rUuP/RfIM3LB15v5aHkQng=; b=eQkgldOaDm8C0ca5xQslLjrS0HIjeIjdtbRmyS4jAa7Zp2cfBNkBVulkoNsT53ZQsx QuLUJ85r/yadWKhnvhNuD0FKzGWnbzCn2vjFnbsjZMZR2xMX/iU3BUPMU/wLIwovO9bZ 7w/nTKgHxRIWZFiQNECj+PUkNY7BWQHq2pweXYZiSsfHirLHPIyv0QLlFfsTbZxQc7Xj hT1I6IaMEAdbiWCHtHd+xk1XPAIlswzJozi0sl+pctDjnFeZrfhzdDgGSvBAJbwP/5E7 wbw1/ZDuANak3SlVduMbh/M/C+4ikvjnTqX+WsQH7Xfd4NxQOPRTPhkm2Wba35AARaSX SQeg== X-Gm-Message-State: AD7BkJKEEvFwpf+W7t+jQf86YPN3xZ3Anrs7UIn9x2+fKF2Iv0cnS+5sv09DmmKxfxd8Iw== X-Received: by 10.107.154.80 with SMTP id c77mr5339175ioe.162.1458151730256; Wed, 16 Mar 2016 11:08:50 -0700 (PDT) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id qt3sm2092356igb.2.2016.03.16.11.08.48 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 11:08:48 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id mh10so50907666igb.0 for ; Wed, 16 Mar 2016 11:08:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.4.73 with SMTP id i9mr7210851igi.24.1458151727922; Wed, 16 Mar 2016 11:08:47 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Wed, 16 Mar 2016 11:08:47 -0700 (PDT) In-Reply-To: <87y49i9v9c.fsf@hobgoblin.ariadne.com> References: <87y49i9v9c.fsf@hobgoblin.ariadne.com> Date: Wed, 16 Mar 2016 14:08:47 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c3165ec5886e052e2e6757 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:09:03 -0000 --001a11c3165ec5886e052e2e6757 Content-Type: text/plain; charset=UTF-8 This looks correct. The reason I brought this scenario up in relationship with Happy Eyeballs is to make sure that Happy Eyeballs works with UDP for initial call setup. There was a discussion of dropping UDP support in Happy Eyeballs compliant end points. You are correct, that once the initial registration is established, Happy Eyeballs does not need to be involved, but this entire scenario relies on using UDP based SIP. One small correction: In such a setup scenario, if edge proxies are stateless and proxy fail-over takes less then 32 sec (Timer B), event SIP transactions would normally survive an edge-proxy fail-over. Regards, _____________ Roman Shpount On Wed, Mar 16, 2016 at 1:40 PM, Dale R. Worley wrote: > Going over Roman's messages regarding hosted PBX systems, I want to > isolate that usage situation from the rest of Happy Eyeballs. It seems > like the problems there are seperable from what Happy Eyeballs needs to > solve. No doubt SIP endpoints in a hosted PBX situation need Happy > Eyeballs also, but rapid failover does not involve the endpoint trying > alternative transport destinations. (Happy Eyeballs is involved in the > endpoint selecting a transport destination to contact initially, but > presumably H.E. will allow the endpoint to continue to use that one > destination as long as it is responding.) > > I've extracted parts of a number of messages that characterize the > situation and put them at the end of this message. The summary of the > situation seems to be: > > ---------- > Failover is done by moving the edge-proxy IP address to the backup endge > proxy and using a protocol without connection state, i.e., UDP > without DTLS. > > The registration state is stored in a database shared by all edge > proxy instances. There need be no dialog state in the edge proxies, > and transaction failure during failover is acceptable. > > Digest authentication nonces can be constructed to be verifiable by > any edge proxy. > > NAT traversal is handled by NAT compensation done by the edge proxy > rather than ICE (thus keeping messages small enough for UDP). > > The unsolved problem is security: > - message integrity > - message privacy > without requiring connection state. > ---------- > > Nonces can be constructed by the edge proxies in a way that doesn't > require connection state to check their validity. E.g., > > nonce = T || R || H(T || R || PK) > > where > > T = timestamp > R = random value > PK = private key known by all the edge proxies > > Security seems to be more of a problem in that all of the security > protocols I know of require connection state. However, it shouldn't be > difficult to construct an adequate security protocol. E.g., assuming > the phone and the proxies have a shared key SK for a user identity U, > one could encrypt a message via: > > encrypted message = "@" || U || MD || E(MK, message) > > where > > message digest (MD) = H(message) > message key (MK) = H(U || MD || SK) > U = fixed-length user identity > "@" is chosen as a flag because no SIP message can begin with "@" > > That should provide sufficient message integrity and privacy. Or more > likely, a considerably better scheme could be devised by someone who > knows encryption algorithms. But we only need a stateless security > mechanism that's much better than Digest authentication. > > Dale > ---------------------------------------------------------------------- > I know a lot of implementations for UDP which handle 1M+ of concurrent > registrations. > > For UDP you can move the IP address for the edge proxy to a different > server. If registration and flow state is in some sort of shared DB, > the fail-over occurs naturally for both the client and server. > > Happy Eyeballs is needed to address situation where you have large > number of end user devices located on multiple customer networks with > different capabilities trying to connect to a central public service > which is accessible over both IPv4 and IPv6. The point I am trying to > make that all of such SIP services primarily use UDP so it is too > early to discard it. > > The obvious problems here are: > > 1) security > 2) large sip messages and UDP message fragmentation > > DTLS is not an answer either since encryption state will need to be > failed over with the edge proxy. What you need is a protocol where > client can recover a flow to the server, including encryption, using a > single round trip. > > I think deployments of large numbers of SIP devices connected to the > public service (like SIP based Skype) never happened and will never > happen because of the complexity and design issues of SIP Outbound in > combination with TLS. I think this is why none of the large scale > consumer VoIP applications used SIP. The companies that built these > products used RTP, ICE and media components, but SIP was ignored. I do > not think all these companies spent all the design effort to build > something completely new just because they wanted to build something > different. From my experience with couple of similar projects the > issues of scaling the deployment and handling redundancy were the main > driving factors. > > Putting aside all the problems with SIP Outbound, there are still a > lot of companies which offer SIP over UDP to the end users. I am > talking about all the hosted PBX solutions. Most of these deployments > do not use ICE and use host based NAT traversal for signaling and > media to keep the message size small. This is not a solution you would > design if you have started the design from scratch, but these > installations definitely need a migration path from IPv4 to > IPv6. Telling them to switch to SIPS with SIP Outbound is unrealistic, > so I believe Happy Eyeballs must provide the solution for UDP. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c3165ec5886e052e2e6757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks correct. The reason I brought this scenario up = in relationship with Happy=C2=A0Eyeballs=C2=A0is to make sure that=C2=A0Hap= py=C2=A0Eyeballs works with UDP for initial call setup. There was a discuss= ion of dropping UDP support in Happy Eyeballs compliant end points. You are= correct, that once the initial registration is established, Happy Eyeballs= does not need to be involved, but this entire scenario relies on using UDP= based SIP.

One small correction: In such a setup scenar= io, if edge proxies are stateless and proxy fail-over takes less then 32 se= c (Timer B), event SIP transactions would normally survive an edge-proxy fa= il-over.

Regards,
<= div>
_____________
Roman Shpount

On Wed, Mar 16, 2016 at 1:40 PM, Dale R. Wor= ley <worley@ariadne.com> wrote:
Going o= ver Roman's messages regarding hosted PBX systems, I want to
isolate that usage situation from the rest of Happy Eyeballs.=C2=A0 It seem= s
like the problems there are seperable from what Happy Eyeballs needs to
solve.=C2=A0 No doubt SIP endpoints in a hosted PBX situation need Happy Eyeballs also, but rapid failover does not involve the endpoint trying
alternative transport destinations.=C2=A0 (Happy Eyeballs is involved in th= e
endpoint selecting a transport destination to contact initially, but
presumably H.E. will allow the endpoint to continue to use that one
destination as long as it is responding.)

I've extracted parts of a number of messages that characterize the
situation and put them at the end of this message.=C2=A0 The summary of the=
situation seems to be:

----------
Failover is done by moving the edge-proxy IP address to the backup endge proxy and using a protocol without connection state, i.e., UDP
without DTLS.

The registration state is stored in a database shared by all edge
proxy instances.=C2=A0 There need be no dialog state in the edge proxies, and transaction failure during failover is acceptable.

Digest authentication nonces can be constructed to be verifiable by
any edge proxy.

NAT traversal is handled by NAT compensation done by the edge proxy
rather than ICE (thus keeping messages small enough for UDP).

The unsolved problem is security:
- message integrity
- message privacy
without requiring connection state.
----------

Nonces can be constructed by the edge proxies in a way that doesn't
require connection state to check their validity.=C2=A0 E.g.,

=C2=A0 =C2=A0 nonce =3D T || R || H(T || R || PK)

where

=C2=A0 =C2=A0 T =3D timestamp
=C2=A0 =C2=A0 R =3D random value
=C2=A0 =C2=A0 PK =3D private key known by all the edge proxies

Security seems to be more of a problem in that all of the security
protocols I know of require connection state.=C2=A0 However, it shouldn'= ;t be
difficult to construct an adequate security protocol.=C2=A0 E.g., assuming<= br> the phone and the proxies have a shared key SK for a user identity U,
one could encrypt a message via:

=C2=A0 =C2=A0 encrypted message =3D "@" || U || MD || E(MK, messa= ge)

where

=C2=A0 =C2=A0 message digest (MD) =3D H(message)
=C2=A0 =C2=A0 message key (MK) =3D H(U || MD || SK)
=C2=A0 =C2=A0 U =3D fixed-length user identity
=C2=A0 =C2=A0 "@" is chosen as a flag because no SIP message can = begin with "@"

That should provide sufficient message integrity and privacy.=C2=A0 Or more=
likely, a considerably better scheme could be devised by someone who
knows encryption algorithms.=C2=A0 But we only need a stateless security mechanism that's much better than Digest authentication.

Dale
----------------------------------------------------------------------
I know a lot of implementations for UDP which handle 1M+ of concurrent
registrations.

For UDP you can move the IP address for the edge proxy to a different
server. If registration and flow state is in some sort of shared DB,
the fail-over occurs naturally for both the client and server.

Happy Eyeballs is needed to address situation where you have large
number of end user devices located on multiple customer networks with
different capabilities trying to connect to a central public service
which is accessible over both IPv4 and IPv6. The point I am trying to
make that all of such SIP services primarily use UDP so it is too
early to discard it.

The obvious problems here are:

1) security
2) large sip messages and UDP message fragmentation

DTLS is not an answer either since encryption state will need to be
failed over with the edge proxy. What you need is a protocol where
client can recover a flow to the server, including encryption, using a
single round trip.

I think deployments of large numbers of SIP devices connected to the
public service (like SIP based Skype) never happened and will never
happen because of the complexity and design issues of SIP Outbound in
combination with TLS. I think this is why none of the large scale
consumer VoIP applications used SIP. The companies that built these
products used RTP, ICE and media components, but SIP was ignored. I do
not think all these companies spent all the design effort to build
something completely new just because they wanted to build something
different. From my experience with couple of similar projects the
issues of scaling the deployment and handling redundancy were the main
driving factors.

Putting aside all the problems with SIP Outbound, there are still a
lot of companies which offer SIP over UDP to the end users. I am
talking about all the hosted PBX solutions. Most of these deployments
do not use ICE and use host based NAT traversal for signaling and
media to keep the message size small. This is not a solution you would
design if you have started the design from scratch, but these
installations definitely need a migration path from IPv4 to
IPv6. Telling them to switch to SIPS with SIP Outbound is unrealistic,
so I believe Happy Eyeballs must provide the solution for UDP.

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

--001a11c3165ec5886e052e2e6757-- From nobody Wed Mar 16 11:48:15 2016 Return-Path: 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 F1C6B12D673 for ; Wed, 16 Mar 2016 11:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 u3ZiggVxP-JT for ; Wed, 16 Mar 2016 11:48:12 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2130A12D610 for ; Wed, 16 Mar 2016 11:48:12 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id m184so70692932iof.1 for ; Wed, 16 Mar 2016 11:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rCsvmU/134VSJ04XM+pPUTBQ6k4hc8u+0DxSDGdOtA0=; b=wdRrzhX7Dfg/oPtJwUsm0vb9A9N5UnIY9/PDyq2zN2aXBahi9MpKTD6kCzYAEgwDoM n7p9xyZ7nELBqoigi3RZ8xADzR1NramMAhjUdeE2PwwET9qvevZ92KI5DdNiKi0biEgx QmMuo0cNY2hZ9mv/iLNAlN6ZsXPI+LGWfJaR95p+ixMcFRXagMGfqcDR/jQd70umb1WT BPw0/m54Q2Cscid+YqRftSqan7fL0Wddws7Ds0BKcw6pHdaucQM3+qFoZq15fd94OIEn WuZvj8+6vkOgDu006XZ4IyMqgmwaR3F+/c6Ru0xRLyW7xzwIJ4SBGl1X/N5yQp35zrNT Zk6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rCsvmU/134VSJ04XM+pPUTBQ6k4hc8u+0DxSDGdOtA0=; b=ARIrenWS19ZWZwkj2f6EjNuFp0W4Tvj+gqAMXVzfHQAgBwvab66hjL77ukj7xmNsKr tFtf8L4yWwS3rHkwGYw/ZD5qBCYM1l7K9ZtQmygQ1/bTzu5Rm28RJo/iA6Uv6C8IhB82 i0XAOZBcm/iTm07iezyPPqUSe+OfMY04Cgw52uE0j9JaFGZX6B7HxcrNYCnP2zJpYjor kuK4/EzIsNrGWgcPI/lPJeWdOLUcTo5lpy8I+SfL6G/x0sEVxjNi6VyLxqjZSV+FyTro MXcmAcN0X/XX8gtVy+iiSFDEY+miI/g3DwVJTfPGtjwXC+zIrCvQYn85eNU/0CCDGq5Q ijcQ== X-Gm-Message-State: AD7BkJJw+UeWnFWOe3wRB06joQFQypaxyzbwOwfa0AMNt9e/WMtMgWQpLFVzCiecMlgQFQ== X-Received: by 10.107.165.140 with SMTP id o134mr6240718ioe.62.1458154091404; Wed, 16 Mar 2016 11:48:11 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com. [209.85.223.173]) by smtp.gmail.com with ESMTPSA id b13sm10741175ign.0.2016.03.16.11.48.09 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 11:48:10 -0700 (PDT) Received: by mail-io0-f173.google.com with SMTP id n190so70749390iof.0 for ; Wed, 16 Mar 2016 11:48:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr5061848ioe.38.1458154089076; Wed, 16 Mar 2016 11:48:09 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Wed, 16 Mar 2016 11:48:09 -0700 (PDT) In-Reply-To: References: <87y49i9v9c.fsf@hobgoblin.ariadne.com> Date: Wed, 16 Mar 2016 14:48:09 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a1140b47281ebaa052e2ef4e4 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:48:14 -0000 --001a1140b47281ebaa052e2ef4e4 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 2:08 PM, Roman Shpount wrote: > On Wed, Mar 16, 2016 at 1:40 PM, Dale R. Worley > wrote: > >> Going over Roman's messages regarding hosted PBX systems, I want to >> isolate that usage situation from the rest of Happy Eyeballs. It seems >> like the problems there are seperable from what Happy Eyeballs needs to >> solve. No doubt SIP endpoints in a hosted PBX situation need Happy >> Eyeballs also, but rapid failover does not involve the endpoint trying >> alternative transport destinations. (Happy Eyeballs is involved in the >> endpoint selecting a transport destination to contact initially, but >> presumably H.E. will allow the endpoint to continue to use that one >> destination as long as it is responding.) >> >> I've extracted parts of a number of messages that characterize the >> situation and put them at the end of this message. The summary of the >> situation seems to be: >> >> ---------- >> Failover is done by moving the edge-proxy IP address to the backup endge >> proxy and using a protocol without connection state, i.e., UDP >> without DTLS. >> >> The registration state is stored in a database shared by all edge >> proxy instances. There need be no dialog state in the edge proxies, >> and transaction failure during failover is acceptable. >> >> Digest authentication nonces can be constructed to be verifiable by >> any edge proxy. >> >> NAT traversal is handled by NAT compensation done by the edge proxy >> rather than ICE (thus keeping messages small enough for UDP). >> >> The unsolved problem is security: >> - message integrity >> - message privacy >> without requiring connection state. >> ---------- >> >> Nonces can be constructed by the edge proxies in a way that doesn't >> require connection state to check their validity. E.g., >> >> nonce = T || R || H(T || R || PK) >> >> where >> >> T = timestamp >> R = random value >> PK = private key known by all the edge proxies >> >> Security seems to be more of a problem in that all of the security >> protocols I know of require connection state. However, it shouldn't be >> difficult to construct an adequate security protocol. E.g., assuming >> the phone and the proxies have a shared key SK for a user identity U, >> one could encrypt a message via: >> >> encrypted message = "@" || U || MD || E(MK, message) >> >> where >> >> message digest (MD) = H(message) >> message key (MK) = H(U || MD || SK) >> U = fixed-length user identity >> "@" is chosen as a flag because no SIP message can begin with "@" >> >> That should provide sufficient message integrity and privacy. Or more >> likely, a considerably better scheme could be devised by someone who >> knows encryption algorithms. But we only need a stateless security >> mechanism that's much better than Digest authentication. >> >> As far as encryption is concerned, do you expect it to replace Digest or to be used concurrently with it? i would assume there is no reason to run digest in parallel with encryption. If you want to use it to replace Digest (there is no reason why it should not), encrypted message should include nonce. Presence of nonce will allow to prevent message replay. How would responses or messages from the server to the client going to be encrypted? My suggestion would be a bit more complex: 1. Client starts by sending a setup message with crypto capabilities 2. Server sends a response with server crypto capabilities, nonce and connection specific server public key (nonce can contain information regarding which specific server key is used for this connection). This message should be signed using server public certificate 3. Send the registration message from the client to the server encrypted with server public key. Include user identity, nonce, client public key and message digest signed with user shared key. 4. On the proxy side store connection specific server private key, client public key and crypto capabilities in the same DB as registration information. This protocol should provide sufficient security including server certificate validation, replay protection, forward secrecy one registration is torn down. On the other hand it will have the same connection recovery properties. Regards, _____________ Roman Shpount --001a1140b47281ebaa052e2ef4e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 16, 2016 at 2:08 PM, Roman Shpount <<= a href=3D"mailto:roman@telurix.com" target=3D"_blank">roman@telurix.com= > wrote:
On Wed, Mar 16, 2016 at 1:40 PM, Dale R. Wo= rley <worley@ariadne.com> wrote:
Going = over Roman's messages regarding hosted PBX systems, I want to
isolate that usage situation from the rest of Happy Eyeballs.=C2=A0 It seem= s
like the problems there are seperable from what Happy Eyeballs needs to
solve.=C2=A0 No doubt SIP endpoints in a hosted PBX situation need Happy Eyeballs also, but rapid failover does not involve the endpoint trying
alternative transport destinations.=C2=A0 (Happy Eyeballs is involved in th= e
endpoint selecting a transport destination to contact initially, but
presumably H.E. will allow the endpoint to continue to use that one
destination as long as it is responding.)

I've extracted parts of a number of messages that characterize the
situation and put them at the end of this message.=C2=A0 The summary of the=
situation seems to be:

----------
Failover is done by moving the edge-proxy IP address to the backup endge proxy and using a protocol without connection state, i.e., UDP
without DTLS.

The registration state is stored in a database shared by all edge
proxy instances.=C2=A0 There need be no dialog state in the edge proxies, and transaction failure during failover is acceptable.

Digest authentication nonces can be constructed to be verifiable by
any edge proxy.

NAT traversal is handled by NAT compensation done by the edge proxy
rather than ICE (thus keeping messages small enough for UDP).

The unsolved problem is security:
- message integrity
- message privacy
without requiring connection state.
----------

Nonces can be constructed by the edge proxies in a way that doesn't
require connection state to check their validity.=C2=A0 E.g.,

=C2=A0 =C2=A0 nonce =3D T || R || H(T || R || PK)

where

=C2=A0 =C2=A0 T =3D timestamp
=C2=A0 =C2=A0 R =3D random value
=C2=A0 =C2=A0 PK =3D private key known by all the edge proxies

Security seems to be more of a problem in that all of the security
protocols I know of require connection state.=C2=A0 However, it shouldn'= ;t be
difficult to construct an adequate security protocol.=C2=A0 E.g., assuming<= br> the phone and the proxies have a shared key SK for a user identity U,
one could encrypt a message via:

=C2=A0 =C2=A0 encrypted message =3D "@" || U || MD || E(MK, messa= ge)

where

=C2=A0 =C2=A0 message digest (MD) =3D H(message)
=C2=A0 =C2=A0 message key (MK) =3D H(U || MD || SK)
=C2=A0 =C2=A0 U =3D fixed-length user identity
=C2=A0 =C2=A0 "@" is chosen as a flag because no SIP message can = begin with "@"

That should provide sufficient message integrity and privacy.=C2=A0 Or more=
likely, a considerably better scheme could be devised by someone who
knows encryption algorithms.=C2=A0 But we only need a stateless security mechanism that's much better than Digest authentication.


As far as encryption is concerned, do you expect it to rep= lace Digest or to be used concurrently with it? i would assume there is no = reason to run digest in parallel with encryption.

= If you want to use it to replace Digest (there is no reason why it should n= ot), encrypted message should include nonce. Presence of nonce will allow t= o prevent message replay.

How would responses or m= essages from the server to the client going to be encrypted?

=
My suggestion would be a bit more complex:

<= div>1. Client starts by sending a setup message with crypto capabilities

2. Server sends a response with server crypto capabi= lities, nonce and connection specific server public key (nonce can contain = information regarding which specific server key is used for this connection= ). This message should be signed using server public certificate
=
3. Send the registration message from the client to the serv= er encrypted with server public key. Include user identity, nonce, client p= ublic key and message digest signed with user shared key.

4. On the proxy side store connection specific server private key, = client public key and crypto capabilities in the same DB as registration in= formation.

This protocol should provide sufficient= security including server certificate validation, replay protection, forwa= rd secrecy one registration is torn down. On the other hand it will have th= e same connection recovery properties.

Regards,=C2= =A0
_____________
Roman Shpount=
=C2=A0
--001a1140b47281ebaa052e2ef4e4-- From nobody Wed Mar 16 13:32:07 2016 Return-Path: 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 1D8F112DA60 for ; Wed, 16 Mar 2016 13:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W2cwfj53NWhc for ; Wed, 16 Mar 2016 13:32:04 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241FE12DA86 for ; Wed, 16 Mar 2016 13:32:02 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-03v.sys.comcast.net with comcast id WkXk1s0075Clt1L01kY1e8; Wed, 16 Mar 2016 20:32:01 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-17v.sys.comcast.net with comcast id WkY01s00X1nMCLR01kY1By; Wed, 16 Mar 2016 20:32:01 +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 u2GKW0Co002211; Wed, 16 Mar 2016 16:32:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2GKVxoL002207; Wed, 16 Mar 2016 16:31:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 16 Mar 2016 16:31:59 -0400 Message-ID: <87lh5i9nb4.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458160321; bh=6Ardv24uv5qWEgQ/X3dR8lpKyPnqX1QSxg6qn5qZWvk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=wG6UZOeh+R3WqD5GRmG8oR9JAqMWSEl/8iEm+zglr0nZ9z2nbWLYK5w6m0kdj6mMD QbrNUvHkIHArlXyoHwM07g8qlOcpB5G47IRZkHMChTyUadhAbJvKqAxb3egwe4V0cb z3N7SOJJTbsRijxVVFGZmWfz+qEdKOvQXlOl7oMAIezco2ONRU7P7PyiCSXex1p7IZ ltjgdMAb4FijXoPPd+iSAJvaqTf3aOBlQsQ0hytNURvEltdmVV6envj1/h9HCB2k/1 yVul1FdzSsym3YVbhFP2WZcH6PJpZ0o1s1Q5pUmLVduvAUK0/aq1SmQFyb5XmbTgu+ yMcUgumu9tk8Q== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Happy Eyeballs -- UDP and RTT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:32:06 -0000 Brett Tate writes: > Section 5.5 indicates that stateful algorithms can more aggressive than > the recommended 150-250 ms delay; however it still recommends "connection > attempts be paced to give connections a chance to complete". Thanks! Yet another point regarding revising timeouts. Dale From nobody Thu Mar 17 09:11:42 2016 Return-Path: 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 CBEB812D9E6 for ; Thu, 17 Mar 2016 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UH2xpuwnCOXb for ; Thu, 17 Mar 2016 09:11:39 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615DD12DC23 for ; Thu, 17 Mar 2016 09:11:24 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-08v.sys.comcast.net with comcast id X4BL1s00626dK1R014BPYW; Thu, 17 Mar 2016 16:11:23 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-01v.sys.comcast.net with comcast id X4BN1s00T1nMCLR014BPPq; Thu, 17 Mar 2016 16:11:23 +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 u2HGBM8s027398; Thu, 17 Mar 2016 12:11:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2HGBMRM027395; Thu, 17 Mar 2016 12:11:22 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 17 Mar 2016 12:11:22 -0400 Message-ID: <87r3f984ph.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458231083; bh=xgekL/trs9AH6PTo2y7s7mzQmX7TCqVr0CdZiKTgz+M=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZPi5LGyh1qzX86e7QDrSqMit6iGER9CC8IoAeA6omxMw7jLa0BtYHoSZA7xd5fX+d PIt+CxgJEQ9OBVyJ1JyxhzBmbDRS0/l9kMvJJLm+GllNNsEPXSV9Gm7lrkgOTKGsf7 j8Y0xes5qvRvBZl/69mFzX4huJesEuSUBHBaU5pi3UrwZtTxTbm98+jDNxGsOXoMrv RQSKJzL054ANGOEIqZEF3s5Pclk5CWzRSqSGKRpRlxifhDskaS3gbjwpb9qyPJRGN7 b8OQvBtKk8juU8EEKTzdzBm5g35s0vtXzLknN6ifEJ92xUNF+0Kubk7sJ9TQ3qGGnR CgOT0M1IFEivg== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:11:41 -0000 Roman Shpount writes: > 4. On the proxy side store connection specific server private key, client > public key and crypto capabilities in the same DB as registration > information. It struck me that the central problem was encryption without maintaining connection-specific encryption information. If we're willing to maintain that, presumably DTLS would work. I don't know much about DTLS, though -- do you think that UDP/DTLS would be a sufficient solution to the use cases we are discussing? Dale From nobody Thu Mar 17 09:18:35 2016 Return-Path: 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 3402012DC23 for ; Thu, 17 Mar 2016 09:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kt_bELCOlwII for ; Thu, 17 Mar 2016 09:18:33 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E781B12DC10 for ; Thu, 17 Mar 2016 09:18:32 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-05v.sys.comcast.net with comcast id X4JJ1s0032JGN3p014JYHN; Thu, 17 Mar 2016 16:18:32 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-10v.sys.comcast.net with comcast id X4JX1s0041nMCLR014JXuc; Thu, 17 Mar 2016 16:18:31 +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 u2HGIUoH028141; Thu, 17 Mar 2016 12:18:30 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2HGIUXP028138; Thu, 17 Mar 2016 12:18:30 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 17 Mar 2016 12:18:30 -0400 Message-ID: <87oaad84dl.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458231512; bh=wVKvmet1hNIypEGe3431bTFfdbJYYcCq2hdiXXmndV4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FyYW9epfsgDQd4Job6FkwyQOf8e8YSraQnOKwYNFp/uTkvvey4ZySZ2/vE03N+1nr T/9dNmc3l94b9SXrIAtPkmI0fBqEVUlyejhIZU+ie3alPBEBIwwsT59mHLarQIFbxV TODWKgtIqzWzoU02triebQ7QLx9xYaRc1ntZPiwZfGVOP8J6FHo3Tz+TvsxPb392Q4 F/L7/M70mXz9je3kNe0cA8j7fsYjAuGrSAkTK/BGTYmXrsZ3RcmZ2j5zD/BRfLfTLg uiDima23sBaW0XfIR8KLhaoFeK1kat0tdKETOjCVILp/G1TAFruxxIu+bbKCxQFetx f8cz1mpAB+LnQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:18:34 -0000 Roman Shpount writes: > One small correction: In such a setup scenario, if edge proxies are > stateless and proxy fail-over takes less then 32 sec (Timer B), event SIP > transactions would normally survive an edge-proxy fail-over. My concern about transaction failure is this: UAC sends request edge-proxy 1 forwards request to UAS, retaining transaction state edge-proxy 1 fails edge-proxy 2 replaces edge-proxy 1 UAS sends response to edge-proxy 2 edge-proxy 2 has no transaction state to match the response and discards it UAS resends response to edge-proxy 2 ... I'm sure that the real scenario is more complicated than that, but there's a general problem if the edge-proxy, or any proxy in the chain, is transaction-stateful, and you generally want proxies to be transaction-stateful. But I think we're OK in practice, in that real UAs are resistant to transaction failure, transaction failures degrade the user experience but the user can easily recover from it. And transaction failure will be quite uncommon. Dale From nobody Thu Mar 17 09:23:10 2016 Return-Path: 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 282A412DC43 for ; Thu, 17 Mar 2016 09:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 qV2PuJEloA2z for ; Thu, 17 Mar 2016 09:23:02 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8966112DC3C for ; Thu, 17 Mar 2016 09:22:50 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id o5so21243519iod.2 for ; Thu, 17 Mar 2016 09:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=C7a7dCjRmMLNLLFiUwiH8+91xH9MTcrGLKvsr+V2sXs=; b=pSBkjkYMIa7X2vOhAp+uQ2W0ekHr/wN2nXKR9YTPsEK0sNoXjC/rdGLKNzWTBTYyku +0hIAiZjXMCBE4s3Eve2PPfteiVMvw0d200syBNqbXDgO5iWEy45QVEqMwx+HlbazXXs Nfqi/7FvD2e/QX0dR6bJnOBiTQa3ykp1WAjIbBfQYRrmoPrOkA26PnPdNHVu9ROQ5RQu zV+NrmHn1qZ1rn52doQ/LBvNdAtdI1v+Tug3NFERnjvNqDm8CrimfJRNgkRKMjWDpnaG 2VXeUmZ86gxjSxiwcUpdVY/GqcIC923LMh5TyfZdi08EBEE/7GnU0IHmtAjoZpD0tm2N dAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=C7a7dCjRmMLNLLFiUwiH8+91xH9MTcrGLKvsr+V2sXs=; b=JrvynpoV5nToCbnERKfjK7JvYnFPzhkAooCN7AYHz65Ub9Gtdaz5zyPr4b/D3dHorY SnnDnjZj00MqyIoeqfQ8ZDPvZ7F+JLSPgSX9KReAFh5BNd03EPaGbqw5GPsSB5nhs3zc C1Lrrg6P2P2Lqrnz3oypTBRtJcLrHkg+Mf2bIS6oQswRygy3R6URu045x0gDsMjuitT+ j0lvexpUHIxg62e/o807TWdde6z4iWMpoUklkFN/06uDrOv2PA4UhLOQjTEB8SrLiPGu hp7nUEH+GLl9t6Ha6+ooDd7B3t7SzX644e0iBsn4Zsxt4gizcy6KYi0gtI4+Kaak76Ok ShtQ== X-Gm-Message-State: AD7BkJKx6oTKj9YQwbyIMsZJLEHUMFNeCfLtG2V8P2dFdNR+Hv4Nq/2kno1OWIMjBITbmw== X-Received: by 10.107.16.230 with SMTP id 99mr10509761ioq.187.1458231769942; Thu, 17 Mar 2016 09:22:49 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id uh4sm12973641igb.15.2016.03.17.09.22.48 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 09:22:49 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id n190so105521636iof.0 for ; Thu, 17 Mar 2016 09:22:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.12.207 with SMTP id 76mr11165106iom.70.1458231767561; Thu, 17 Mar 2016 09:22:47 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 17 Mar 2016 09:22:47 -0700 (PDT) In-Reply-To: <87oaad84dl.fsf@hobgoblin.ariadne.com> References: <87oaad84dl.fsf@hobgoblin.ariadne.com> Date: Thu, 17 Mar 2016 12:22:47 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a113eca0681a1b4052e410a72 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:23:07 -0000 --001a113eca0681a1b4052e410a72 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 12:18 PM, Dale R. Worley wrote: > Roman Shpount writes: > > One small correction: In such a setup scenario, if edge proxies are > > stateless and proxy fail-over takes less then 32 sec (Timer B), event SIP > > transactions would normally survive an edge-proxy fail-over. > > My concern about transaction failure is this: > > UAC sends request > edge-proxy 1 forwards request to UAS, retaining transaction state > edge-proxy 1 fails > edge-proxy 2 replaces edge-proxy 1 > UAS sends response to edge-proxy 2 > edge-proxy 2 has no transaction state to match the response and discards it > UAS resends response to edge-proxy 2 > ... > > I'm sure that the real scenario is more complicated than that, but > there's a general problem if the edge-proxy, or any proxy in the chain, > is transaction-stateful, and you generally want proxies to be > transaction-stateful. > It is quite common (especially when solutions are designed for scale) that entire proxy stack is stateless or carries relevant state in via or route headers. But I think we're OK in practice, in that real UAs are resistant to > transaction failure, transaction failures degrade the user experience > but the user can easily recover from it. And transaction failure will > be quite uncommon. > The main transaction failure recovery issue is recovery of initial INVITE transaction. This transaction is often long (waiting for remote party to pick up) and user experience can be inconvenient (call was picked up and dropped), especially if early media is used (started to talk to the person and got dropped). _____________ Roman Shpount --001a113eca0681a1b4052e410a72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 17, 2016 at 12:18 PM, Dale R. Worley <= ;worley@ariadne.com= > wrote:
Roman Shpount <roman@telurix.com> writes:
> One small correction: In such a setup scenario, if edge proxies are > stateless and proxy fail-over takes less then 32 sec (Timer B), event = SIP
> transactions would normally survive an edge-proxy fail-over.

My concern about transaction failure is this:

UAC sends request
edge-proxy 1 forwards request to UAS, retaining transaction state
edge-proxy 1 fails
edge-proxy 2 replaces edge-proxy 1
UAS sends response to edge-proxy 2
edge-proxy 2 has no transaction state to match the response and discards it=
UAS resends response to edge-proxy 2
...

I'm sure that the real scenario is more complicated than that, but
there's a general problem if the edge-proxy, or any proxy in the chain,=
is transaction-stateful, and you generally want proxies to be
transaction-stateful.

It is quite commo= n (especially when solutions are designed for scale) that entire proxy stac= k is stateless or carries relevant state in via or route headers.

But I think we're OK in practice, in that r= eal UAs are resistant to
transaction failure, transaction failures degrade the user experience
but the user can easily recover from it.=C2=A0 And transaction failure will=
be quite uncommon.

The main transaction= failure recovery issue is recovery of initial INVITE transaction. This tra= nsaction is often long (waiting for remote party to pick up) and user exper= ience can be inconvenient (call was picked up and dropped), especially if e= arly media is used (started to talk to the person and got dropped).
_____________
Roman Shpount
=C2=A0
--001a113eca0681a1b4052e410a72-- From nobody Thu Mar 17 09:28:42 2016 Return-Path: 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 26C4012DC34 for ; Thu, 17 Mar 2016 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 qldp296Nyjxw for ; Thu, 17 Mar 2016 09:28:39 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F8012DC2E for ; Thu, 17 Mar 2016 09:28:39 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id kc10so937543igb.0 for ; Thu, 17 Mar 2016 09:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0DrJnO35QulvC0j7fHXrnPBRJquN1Y0NpzmnfVHqX5M=; b=Q8UVoz/DtSqCAfEnrscdjStO4P/kFs7cc6WJXp+GQ1pbJkT9mLHpebsLUiUpIqT83Q CEcz/IaxJWaaEBp9vTyesaHuhdeJfaL6I7/G4vt0u+nyf+frmB6OGv7U7jKi30o+Wiru gJZG1rVHnnvofuW7HRv2jWKiD4G/M6LaXmAMal33HM1lsobqpm9EqqQ5ydBJSJFZUieS 65UkrdfwCJ/yxpGbmdFHUTkAU2ypWCtLcCVVjCzUEwQ+CN0Ac+E1WsO08k1FN2JR55c9 NsTL9T9F6MM00lMeLAqUGP+697hXyOrWcTIK1TC9ICZ2pzaGOmbMHhEBUQVVHOIYdENU HdfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0DrJnO35QulvC0j7fHXrnPBRJquN1Y0NpzmnfVHqX5M=; b=UyAOUSN2BEwjnsIp0ioSQowbu8Ze/0OSxpbQ10aU4vEEK5bDSlODGWY0hw53EOLCh9 XhN5+Gt0uy5g4Q9GwbipsM/nkmh6/uGsgPGVsDbKlhTqIihgc5N393DhCE8Aet6mJgtk 0M8cyxg5e32uu/hPF+23EVMMl05jYIHvAISdrNJAQYylqs13sckoNKgXwnO0vzQz3Ujx zw+bS80/40HweMoRVNYmdyONBuwM3/FEKUA+rkiT0bi6wjEr3uvprS6xJBul/tJC5G7C iZmJx17ZMqgGWlEZfbI4oym+g0qpOK2iJx5nncUv97bBKyM9WMlJRzLz9QoVqPSHZ3EM KZpA== X-Gm-Message-State: AD7BkJJNxQwly3YitZdHqXDqxQOM4dJhJ2eqXpwnkJ3Rg1M5ujCzEcD9nScxruQJPI9asg== X-Received: by 10.50.1.6 with SMTP id 6mr12816486igi.28.1458232118372; Thu, 17 Mar 2016 09:28:38 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id 99sm3945733ior.16.2016.03.17.09.28.36 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 09:28:37 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id g184so48299558ioa.3 for ; Thu, 17 Mar 2016 09:28:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.12.207 with SMTP id 76mr11198786iom.70.1458232116513; Thu, 17 Mar 2016 09:28:36 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 17 Mar 2016 09:28:36 -0700 (PDT) In-Reply-To: <87r3f984ph.fsf@hobgoblin.ariadne.com> References: <87r3f984ph.fsf@hobgoblin.ariadne.com> Date: Thu, 17 Mar 2016 12:28:36 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a113eca064e13b6052e411f27 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:28:41 -0000 --001a113eca064e13b6052e411f27 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 12:11 PM, Dale R. Worley wrote: > Roman Shpount writes: > > 4. On the proxy side store connection specific server private key, client > > public key and crypto capabilities in the same DB as registration > > information. > > It struck me that the central problem was encryption without maintaining > connection-specific encryption information. If we're willing to > maintain that, presumably DTLS would work. I don't know much about > DTLS, though -- do you think that UDP/DTLS would be a sufficient > solution to the use cases we are discussing? > There is some shared state which would be inherently present and shared between the edge-proxies. Typically it is client user ID and specific IP:port on which they are registered. As long as client specific state is clearly identified and can be easily shared without too many shared DB updates (you do want to avoid updating shared DB on each UDP message sent or received), UDP based solution can be implemented. I think DTLS definitely needs to be investigated regarding state sharing. Part of the problem is that DTLS is fairly complex all inclusive protocol with multiple key negotiation, encryption and handshake schemes. It might need to be restricted to allow state sharing. Also, none of the common DTLS implementations, such as OpenSSL, provide support for such state sharing. Also, the amount of stored state can be reduced if signed nonce is used with each transaction. For instance server can provide client with encryption key ID in the nonce and sign it, instead of keeping this ID in the per connection storage. This is something not supported with DTLS. 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. _____________ Roman Shpount --001a113eca064e13b6052e411f27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 17, 2016 = at 12:11 PM, Dale R. Worley <worley@ariadne.com> wrote:
=
Roman Shpount= <roman@telurix.c= om> writes:
> 4. On the proxy side store connection specific server private key, cli= ent
> public key and crypto capabilities in the same DB as registration
> information.

It struck me that the central problem was encryption without maintai= ning
connection-specific encryption information.=C2=A0 If we're willing to maintain that, presumably DTLS would work.=C2=A0 I don't know much abou= t
DTLS, though -- do you think that UDP/DTLS would be a sufficient
solution to the use cases we are discussing?

There is some shared state which would be inherently present and shar= ed between the edge-proxies. Typically it is client user ID and specific IP= :port on which they are registered. As long as client specific state is cle= arly identified and can be easily shared without too many shared DB updates= (you do want to avoid updating shared DB on each UDP message sent or recei= ved), UDP based solution can be implemented. I think DTLS definitely needs = to be investigated regarding state sharing. Part of the problem is that DTL= S is fairly complex all inclusive protocol with multiple key negotiation, e= ncryption and handshake schemes. It might need to be restricted to allow st= ate sharing. Also, none of the common DTLS implementations, such as OpenSSL= , provide support for such state sharing.

Also, th= e amount of stored state can be reduced if signed nonce is used with each t= ransaction. For instance server can provide client with encryption key ID i= n the nonce and sign it, instead of keeping this ID in the per connection s= torage. This is something not supported with DTLS.

This is definitely something that requires further investigation, but I th= ink the right way to do this is to start with DTLS and see if it can be ada= pted or improved for connection fail-over scenario.
________= _____
Roman Shpount
=C2=A0
--001a113eca064e13b6052e411f27-- From nobody Fri Mar 18 13:23:43 2016 Return-Path: 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 ; 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 ; 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 ; 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 (Dale R. Worley) To: Roman Shpount In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 20:23:42 -0000 Roman Shpount 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 From nobody Mon Mar 21 12:55:58 2016 Return-Path: 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 D4F0012DB08 for ; Mon, 21 Mar 2016 12:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 uQqBkSoF54k9 for ; Mon, 21 Mar 2016 12:55:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE93112DAFD for ; Mon, 21 Mar 2016 12:55:15 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2LG8VEw047442 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 21 Mar 2016 11:08:32 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: <56F01C7F.5000507@nostrum.com> Date: Mon, 21 Mar 2016 11:08:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:55:35 -0000 [as chair] Today marks the start of a three-week Working Group Last Call for the following document: https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ The end of this last call is specifically intended to end on the Friday of the upcoming face-to-face meeting in Buenos Aires. Our plan is to ask the authors to incorporate any feedback received during these final weeks as well as comments from the face-to-face meeting into a version of the document that will be ready to send to the IESG. All Working Group participants are requested to review the document and send comments to the SIPCORE mailing list. /a From nobody Mon Mar 21 15:12:12 2016 Return-Path: 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 9DC0112D0C6 for ; Mon, 21 Mar 2016 15:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 1lm26GGlZIU1 for ; Mon, 21 Mar 2016 15:12:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2268B12D10C for ; Mon, 21 Mar 2016 15:12:08 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2LMC6EK068691 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 21 Mar 2016 17:12:07 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: <56F071B6.90405@nostrum.com> Date: Mon, 21 Mar 2016 17:12:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Proposed SIPCORE Agenda X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:12:10 -0000 [as chair] We have uploaded a preliminary agenda for the upcoming SIPCORE meeting in Buenos Aires: https://www.ietf.org/proceedings/95/agenda/agenda-95-sipcore Any comments on the proposed agenda should be made to the chairs before the end of this week. Thanks! /a From nobody Tue Mar 22 06:39:29 2016 Return-Path: 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 B45EA12D8C0 for ; Tue, 22 Mar 2016 06:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 N0s1YE6ARtiy for ; Tue, 22 Mar 2016 06:39:21 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E6F12D8E0 for ; Tue, 22 Mar 2016 06:38:22 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id r187so175029560oih.3 for ; Tue, 22 Mar 2016 06:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=TRTp9fbRuboRIncSVSsCU2seI2Px11JsrjzURFwUFiA=; b=MA0V19QP0bN4zPZWyforjQYzhBfEiU4U5Sy9btdjvIzyCqESdoV0o3tx7E/+CZnkF1 hcYHhWzzQXLIsSWOPvGgza0t8jxdhcOiPRap3Fp8PmQl3Qq4EZUzwVpmAa9v85+EWaJ6 8qVaFsx5gBKapGovEB0p8PRce1q5k+FZ/DXTFS2sqONQWJd3cHT7tMkHFC4uZbKuYh/u mB+dfws/bo9GVBkazaS+TmPXvFc369+V4Ple+lC86hYdAHVeDYej96bGlepT+09YjzRS b6zjmCh37RUauzfBJdbEU2JAi1eftDsEcmOU/bnxJE+yt02uBl2UrEPb9e7XG/MG/gx9 ONxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=TRTp9fbRuboRIncSVSsCU2seI2Px11JsrjzURFwUFiA=; b=U2Vkh/kXeiT2469sTF9uXr9m6Tb/aua10LoZH9eGtmffaT3bIKjQ7zBP6CWPGFXfc0 fF68NqWUcutAzSZM6/ZxsVvsUSz69vjy7CsMZypmAx5o7TV0VXNb9qP0ZmEuzZSd2dVX 90/6G9nWNOo/p2Y0XvnZkxTnsc4yTa9+S+UJSpaNeT1ksS2wRZg7AdFPlFjXILOq9+X4 uHLP3stEXY/x9HXXUsLrNy6CG4dq91PSKlIGBAhc4rqu94pMUcoKxxjcM92rPye8VcmW xOnycXHC5ohkDYcQIcfPw2NIJwdwlKZC67drPdzvIc5LcwsW5Eh9H70H2ZQLkM1ggcOF qjeA== X-Gm-Message-State: AD7BkJKLbT6j3LkRPjgAucTZcI4/vbH06C9rfVavZ/MbzEfam/QJuMr6N6JLxv/NC8l5fjHn5gza1Myy7Wwj5Q== MIME-Version: 1.0 X-Received: by 10.157.38.65 with SMTP id a59mr497082otb.90.1458653901539; Tue, 22 Mar 2016 06:38:21 -0700 (PDT) Received: by 10.157.38.37 with HTTP; Tue, 22 Mar 2016 06:38:21 -0700 (PDT) Date: Tue, 22 Mar 2016 08:38:21 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: multipart/alternative; boundary=94eb2c04fa58a6d0b7052ea35332 Archived-At: Subject: [sipcore] SIPNOC 2016 Early-Bird Extended till March 31 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 13:39:27 -0000 --94eb2c04fa58a6d0b7052ea35332 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I think this is quite relevant to folks on this mailing list, in particular given that a number of recent WG documents have been a result of SIP Forum task groups. While it's a bit past the CFP deadline, if you are interested in submitting something, please contact Marc Robins: http://www.sipforum.org/content/view/374/275/ Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Thu, Mar 17, 2016 at 12:23 PM Subject: [SIPForum-fullmembers] SIPNOC 2016 Early-Bird Extended till March 31 To: fullmembers@sipforum.org SIP Forum Full Members, Stop dragging your feet and register for SIPNOC 2016 today! To help grease your wheels, we=E2=80=99ve extended the early bird rate till= March 31=E2=80=A6take advantage of the savings and click your way to a conference= pass today. ------------------------------ *SIPNOC 2016 General Info* The SIPNOC 2016 event website is located at www.sipnoc.org. Special pricing for SIPNOC 2016 is now in effect! Take advantage of special early-bird pricing now through March 31, 2016. The regular SIPNOC 2016 conference registration fee is $995, but for a limited time *individuals from SIP Forum Full Member companies save $220 off the regular price with special early-bird pricing. *This "all-inclusive" rate includes one full day of SIP Training and two days of conference proceedings, including all meals (breakfasts, lunches and dinners) and break refreshments. *Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at http://www.regonline.com/sipnoc2016. ------------------------------ *SIPNOC 2016 Sponsorship Information* For information about corporate sponsorship opportunities at SIPNOC 2016, please contact Marc Robins at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ _______________________________________________ fullmembers mailing list fullmembers@sipforum.org http://sipforum.org/mailman/listinfo/fullmembers --94eb2c04fa58a6d0b7052ea35332 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I think this is quite relevan= t to folks on this mailing list, in particular given that a number of recen= t WG documents have been a result of SIP Forum task groups.=C2=A0 While it&= #39;s a bit past the CFP deadline, if you are interested in submitting some= thing, please contact Marc Robins: =C2=A0http://www.sipforum.org/content/view/374/275/

Regards= ,
Mary.


---------- Forwarded message ----------
From: Marc Robins <marc.robins@sipforum.org>
Date: Thu, Mar 17, 2016 at 12:23 PM
Subject: [SIPForum-= fullmembers] SIPNOC 2016 Early-Bird Extended till March 31
To: fullmembers@sipforum= .org


SIP Forum Full= Members,

=C2=A0

<= span style=3D"font-size:12pt">Stop dragging your feet and register for SIPN= OC 2016 today!

=C2=A0

<= span style=3D"font-size:12pt">To help grease your wheels, we=E2=80=99ve ext= ended the early bird rate till March 31=E2=80=A6take advantage of the savin= gs and click your way to a conference pass today.

<= div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">

SIPNOC 2016 General Info

The SIPNOC 2016= event website is located at www.sipnoc.org.

Special pricing for SIPNOC 2016 is now in effect! = Take advantage of special early-bird pricing now through March 31, 2016. Th= e regular SIPNOC 2016 conference registration fee is $995, but for a limite= d time individuals from SIP Forum Full Member companies save $220 off the= regular price with special early-bird pricing. This "all-i= nclusive" rate includes one full day of SIP Training and two days of c= onference proceedings, including all meals (breakfasts, lunches and dinners= ) and break refreshments.

Please contact Marc Robins, SIP Fo= rum President and Managing Director, at marc.robins@sipforum.org to obtain the exclu= sive Full Member discount code.

Register today at http://www.regonline.com/sipno= c2016.=C2=A0

SIPNOC 2016 Sponsorship Information=

For in= formation about corporate sponsorship opportunities at SIPNOC 2016, please = contact Marc Robins at 203-829-6307= or marc.= robins@sipforum.org.

=

=C2=A0


___________________________= ____________________
fullmembers mailing list
fullmembers@s= ipforum.org
http://sipforum.org/mailman/listinfo/fullmembers=



--94eb2c04fa58a6d0b7052ea35332-- From nobody Sun Mar 27 14:27:53 2016 Return-Path: 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 ACFDD12D13C for ; Sun, 27 Mar 2016 14:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 koeYOPaNGXWd for ; Sun, 27 Mar 2016 14:27:50 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C8712D10C for ; Sun, 27 Mar 2016 14:27:49 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by comcast with SMTP id kIDaaVdtLyrPukIDtat28p; Sun, 27 Mar 2016 21:27:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459114069; bh=PqqvN+kSuNvfZbt6ZsrI4YjR5SqNRPojYL4FJY+7Uj8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=FMYXkRW3rUTzIRGOkK4IiLo/rn4vwtO7IUufEIm8M8B+WDrVUYI+XbhOVmf3/Z2Zs NipxboTQO3am2QURHAgHOSad9mlR0m5tHVzhFAY9v059z6VcTd5TPrEGZdrEhjP/lx R3lKZoyKUdVdvCH32tk8KnJmemOgrHBK6R8gNFoZwumVdc4/hAPmAQRNtSngTloACv A9GLizRMt51e70QI04ssF8+wzcaBknqJ0IT5G1RVWDytWSvsNTtKX3fwc4zRqBC/nF VMPgCEsVPFcqLKIsObrGP4PfiA6u5Xqg4iDtPmUDfPSurokF6nJv7AhnWeuB3Za7lr i61DTkspeOs9w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id b9To1s00K1nMCLR019Tom3; Sun, 27 Mar 2016 21:27:49 +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 u2RLRmXI022952 for ; Sun, 27 Mar 2016 17:27:48 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2RLRlfc022948; Sun, 27 Mar 2016 17:27:47 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 27 Mar 2016 17:27:47 -0400 Message-ID: <87fuvb1ui4.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [sipcore] Outline of a SIP-DTLS document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 21:27:52 -0000 I've written a draft that would be the start of the process of producing a version of DTLS for edge access in SIP, assembling a set of requirements. Do people think this is worth pursuing? If so, please speak up. We can do a preliminary job of assembling requirements, and then send this to Dispatch for consideration there. Dale ---------------------------------------------------------------------- [version of 27 March 2016] A lightweight, secure, scalable edge access protocol for SIP Introduction This document describes the requirements for a lightweight, secure, scalable edge access protocol for SIP. It is intended for large-scale SIP networks, where a constellation of redundant edge proxies maintains flows with hundreds of thousands or millions of user agents. "Edge access" means that the protocol is a transport protocol intended primarily for use between user agents and edge proxies. "Lightweight" means that the protocol maintains minimal state for each flow between a user agent and a proxy, thus easing the load on the edge proxies and minimizing the amount of state that needs to transferred upon proxy failover. "Secure" means a level of security similar to that provided by TLS. In addition, we require logical structure of the protocol to be fairly simple, so that it will be broadly implemented. It is expected that these requirements will be used to design an adaptation of DTLS for use as a transport for SIP. Terminology: Client: the role of one endpoint of the transport connection, typically a SIP user agent Server: the role of the other endpoint of the transport connection, typically a SIP edge proxy for a SIP domain Flow: an logically-associated series of SIP messages (requests and responses) between a client and a server Requirements and non-requirements REQ: The protocol is a transport protocol for use in the hop between a client and server. Non-REQ: The protocol need not be symmetric between the client and server roles. REQ: The protocol must have a fairly simple logical structure. REQ: The protocol must allow over 1 million flows to be supported by a single server with current commercial technology. REQ: The amount of state the server must maintain for a single flow must be small, of the size of the state that must be maintained for a SIP registration. This allows the flow state for a server to be held in a failover database of reasonable size. REQ: Once a flow is established, passing messages in either direction must typically require no update to the flow state. This keeps the update rate of the database proportionate to the rate of creating and destroying flows, rather than proportional to the message volume. Non-REQ: If a client loses its flow state, reestablishing the flow may require multiple round trip times. We assume that if a client loses its flow state, it will also lose any current dialogs and sessions. Thus, it does not need to recover flow state quickly in order to keep current calls alive. REQ: The protocol must provide message privacy and integrity. Non-REQ: The protocol does not need to provide replay protection. The use of SIP digest authentication with time-stamped nonces can provide a substantial degree of replay protection. REQ: The protocol must allow authentication of the client to the server and/or authentication of the server to the client. REQ: Authentication credentials (in a single direction) can be either a certificate or a realm, username, and shared secret. REQ: The protocol must allow the client to present a SIP domain to the server, so that the server can select an appropriate realm to present to the client. REQ: The protocol must allow the server to present a realm to the client, so that the client can select appropriate credentials to present to the server, and which the client can use to validate the credentials presented by the server. These requirements mirror the dataflow of digest authentication. REQ: The protocol's security mechanism must be independent of any SIP authentication (other than that SIP credentials can be reused for realm/username/secret authentication, if the devices are configured to do so). Non-REQ: A flow's protocol state may be bound to the client's transport address as seen by the server (inter alia). REQ: If a client's flow becomes invalidated at the server (e.g., due to a change in the client's public address), the client must be able to detect this fact quickly (within a few RTTs), so that it can reestablish a flow quickly to prevent outstanding transactions from failing. *** Is this needed? Is this possible? REQ: If a client's flow becomes invalidated at the server due to a change in the client's public address, the client must be able to recover in a way that does not invalidate the route set of existing dialogs. *** Presumably this requires using GRUUs, which would be specified in the document. Is it possible to make this work? Motivations In the most recent SIPit interoperability event, SIPit 31 of October 2014, 86% of user agents supported TCP, and 81% supported TLS. This is 12 years after RFC 3261 envisioned universal support for both TCP and TLS in SIP devices. >From draft-jennings-sip-dtls-01 There has been considerable discussion of why SIP needs DTLS when we have TLS. This is the wrong question. The right question is why SIP has UDP and TCP (not to mention SCTP). There are two reasons for believing that UDP is likely to be an important protocol in SIP for the foreseeable future. o In theory, there is no problem building systems that terminate a million TCP connections on a single host. In practice, the common operating systems used for building SIP aggregation devices make this impossible. To date, no one has demonstrated terminating over 100k SIP TCP connections to a single host. Doing that many connections with UDP has not been difficult. o If we want to talk about "running code" for SIP, it's UDP. Unless UDP is deprecated for SIP, it is important to provide a reasonable level of security for it. >From Roman Shpount http://mailarchive.ietf.org/arch/msg/sipcore/jjALFjeefA1WjwmVSkv_jAsqsNQ Since everyone is talking about how desirable TLS is and how easy it is to deprecate UDP, can anybody point me to large scale implementations of TLS+Outbound? I know a lot of implementations for UDP which handle 1M+ of concurrent registrations. When someone tries to implement the same using TLS and Outbound it much harder: 1. Maintaining large number of TLS connections is resource intensive. If you have 1M concurrent registrations you need edge proxies which will terminate 1M concurrent TLS connections and respond to keep alive messages. This requires 10x number the servers then UDP registrations. This also exposes you to more risk of DOS attacks 2. Fail-over is much harder: For TLS/Outbound you either need to put edge proxy on VM that you can migrate to a different server (still had to deal with software failure). To deal with software failures, you need to design the mechanism for the client to recover the connection to a different edge proxy. If call is in progress this involves for the client detecting the flow failure based on keep alive failure, re-registering to get the gruu, and re-INVITE with new gruu in the contact. If server needs to send a message on the client call while this is happening, it needs to queue this message or implement some sort of non-standard re-transmit timer. This typically means call gets dropped. There is no mechanism at all to recover the transaction which is in progress while outbound proxy fails. For UDP you can move the IP address for the edge proxy to a different server. If registration and flow state is in some sort of shared DB, the fail-over occurs naturally for both the client and server. I went through couple of large scale deployments of Outbound with SIPS for large number of consumer devices. In all of them SIP registrations were scrapped and replaced with something proprietary. >From Roman Shpount: http://mailarchive.ietf.org/arch/msg/sipcore/y4E8MTU4tUVHjw7MlZnaMAzuRK8 Multiple flows somewhat mitigate the problem of edge proxy failure at the cost of multiplying the cost of connection management. There is still and issue of temporary network failure between the end point and the proxy. In case of TLS this terminates all flows from the client to all proxies and typically terminates the call. And then there is a use case of end point migrating from one IP to another. Here the quicker flow recovery with UDP increases the chances of keeping the call running vs 7 or 8 round trips required to recover the TLS flow (TCP connection setup, TLS connection setup, registration with response and then re-invite with new GRUU). And then there is a use case when client used a temporary GRUU which was flow specific. And there is still no way to recover the transaction since, I believe, transactions are flow bound. >From Roman Shpount: http://mailarchive.ietf.org/arch/msg/sipcore/Oq5xEUlOJ5eM3Mn9HeHxNUUJX5Y DTLS is not an answer either since encryption state will need to be failed over with the edge proxy. What you need is a protocol where client can recover a flow to the server, including encryption, using a single round trip. I think deployments of large numbers of SIP devices connected to the public service (like SIP based Skype) never happened and will never happen because of the complexity and design issues of SIP Outbound in combination with TLS. I think this is why none of the large scale consumer VoIP applications used SIP. The companies that built these products used RTP, ICE and media components, but SIP was ignored. I do not think all these companies spent all the design effort to build something completely new just because they wanted to build something different. From my experience with couple of similar projects the issues of scaling the deployment and handling redundancy were the main driving factors. Putting aside all the problems with SIP Outbound, there are still a lot of companies which offer SIP over UDP to the end users. I am talking about all the hosted PBX solutions. Most of these deployments do not use ICE and use host based NAT traversal for signaling and media to keep the message size small. This is not a solution you would design if you have started the design from scratch, but these installations definitely need a migration path from IPv4 to IPv6. Telling them to switch to SIPS with SIP Outbound is unrealistic, so I believe Happy Eyeballs must provide the solution for UDP. References draft-jennings-sip-dtls-01, "Using DTLS as a Transport for SIP", C. Jennings, N. Modadugu Messages from Roman Shpount to the Sipcore mailing list. RFC 3261 [END] From nobody Sun Mar 27 14:51:46 2016 Return-Path: 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 535D812D5A3 for ; Sun, 27 Mar 2016 14:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 uDQ0n-62Jrkq for ; Sun, 27 Mar 2016 14:51:41 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D138812D5B6 for ; Sun, 27 Mar 2016 14:51:41 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id l20so44560539igf.0 for ; Sun, 27 Mar 2016 14:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=13WF7i7VCMnlYDu8ZOmzBFYErxZbK+meJJNK4B+S0Zo=; b=MRlJDF2T7a4W+dYCSL8Nuc686KBXEd30cEWxyZ48qVf2X7L5Lbvzo8B3C/sjCscOWT YK400YwAVErEvSIwGyqjTSSDK5jFR7WA1WTtePJCusw8PnZGVjvRax6VMjrD2sKmIvaG vzUarpAH3GS0Q9k9PztQMKWd42c/HyGxhL83b344k7YCjrNVs6aRVAT/UAXeSKN73d4g C4uDrjhpFV0Mzrsw2yVl1rBAL24aNzOtVVaNpS6cjMW1L9fg7buZ9OWUJrZbVdC2tm19 cTNElxHKoo7yA4EdKJqy+7zSQU6E8a1jlJUYwMdK2ex3IigTPswLSTBc7fgv2isZmQxt hv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=13WF7i7VCMnlYDu8ZOmzBFYErxZbK+meJJNK4B+S0Zo=; b=Z3zjqSvEmbumUE/wzAGVS230MVZ0eQu8YTTmT5Ik4+nKlseFBB5u9GyoHKEcc5UTF/ efePYhx4SFkM9/pD9zKDgryPuCttYniawaNZivWgSy5nbQttQRysoWEJFWeqfDsCnDge OL42vGAvUB02Y3Am5UfK/+yVt1A8Iebrv7LTyNx+891PCq8Poraj3+03s6rn3MuOI2lN vrnEMnsxCUeNTOFbEd/kWHaHn/4YL3Ce74lBfZnToEgndTfXNIxnPvC23XM1i5crHOux bKSMgh08oi3j/5JjchiYdDQVmZx2/0x70LvdilL4UPuSgfe2rn9jwiDngfoB0gU/ZmAi dj5w== X-Gm-Message-State: AD7BkJKRDyNNSmMos2DxVO0rJHcHJSAm6bvT2KKob9ApivwhPoW9dxetuiHnJQfK7h9muA== X-Received: by 10.50.67.113 with SMTP id m17mr6259950igt.52.1459115501109; Sun, 27 Mar 2016 14:51:41 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id oq8sm2889744igb.7.2016.03.27.14.51.39 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 14:51:39 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id i19so6056129igt.0 for ; Sun, 27 Mar 2016 14:51:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.20.161 with SMTP id o1mr6700151ige.2.1459115498845; Sun, 27 Mar 2016 14:51:38 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Sun, 27 Mar 2016 14:51:38 -0700 (PDT) In-Reply-To: <87fuvb1ui4.fsf@hobgoblin.ariadne.com> References: <87fuvb1ui4.fsf@hobgoblin.ariadne.com> Date: Sun, 27 Mar 2016 17:51:38 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7bd75708ff093f052f0ecc48 Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outline of a SIP-DTLS document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 21:51:44 -0000 --047d7bd75708ff093f052f0ecc48 Content-Type: text/plain; charset=UTF-8 I obviously do this think this is worth pursuing. Few more comments inline. On Sun, Mar 27, 2016 at 5:27 PM, Dale R. Worley wrote: > REQ: If a client's flow becomes invalidated at the server (e.g., due > to a change in the client's public address), the client must be able > to detect this fact quickly (within a few RTTs), so that it can > reestablish a flow quickly to prevent outstanding transactions from > failing. > > *** Is this needed? Is this possible? > Typically using STUN keep alive messages ( https://tools.ietf.org/html/rfc5626#section-3.5.2) allows UDP client detect that it's public address changed and re-register. To prevent call dialogs from being torn down by SIP session timer this requires flow failure detection that is faster then typical transaction timeout (32 sec) which is possible with keep alive messages sent every 10-15 sec vs recommended 24-29 sec. REQ: If a client's flow becomes invalidated at the server due to a > change in the client's public address, the client must be able to > recover in a way that does not invalidate the route set of existing > dialogs. > > *** Presumably this requires using GRUUs, which would be specified in > the document. Is it possible to make this work? > It should be possible to indicate that this is the same device being registered and allow to preserve the same GRUU. Once more benefit to consider -- DTLS provides message fragmentation support which will allow using such DTLS based protocol with larger sized SIP messages that do not fit into a single UDP packet. Regards, _____________ Roman Shpount --047d7bd75708ff093f052f0ecc48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I obviously do this think this is worth=C2=A0pursuing.

Few more comments inline.

On Sun, Mar 27, 2016 at 5:27 PM, Dale R. Worley <worley= @ariadne.com> wrote:
REQ:=C2=A0 If a clie= nt's flow becomes invalidated at the server (e.g., due
to a change in the client's public address), the client must be able to detect this fact quickly (within a few RTTs), so that it can
reestablish a flow quickly to prevent outstanding transactions from
failing.

*** Is this needed?=C2=A0 Is this possible?

=
Typically using STUN keep alive messages (https://tools.ietf.org/html/rfc5626#secti= on-3.5.2) allows UDP client detect that it's public address changed= and re-register. To prevent call dialogs from being torn down by SIP sessi= on timer this requires flow failure detection that is faster then typical t= ransaction timeout (32 sec) which is possible with keep alive messages sent= every 10-15 sec vs recommended 24-29 sec.

REQ:=C2=A0 If a client's flow becomes invalidated at the server du= e to a
change in the client's public address, the client must be able to
recover in a way that does not invalidate the route set of existing
dialogs.

*** Presumably this requires using GRUUs, which would be specified in
the document.=C2=A0 Is it possible to make this work?
= =C2=A0
It should be possible to indicate that this is the same de= vice being registered and allow to preserve the same GRUU.

Once more benefit to consider -- DTLS provides message fragmentati= on support which will allow using such DTLS based protocol with larger size= d SIP messages that do not fit into a single UDP packet.

Regards,
_____________=
Roman Shpount

--047d7bd75708ff093f052f0ecc48-- From nobody Sun Mar 27 18:01:07 2016 Return-Path: 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 F337412D1EA for ; Sun, 27 Mar 2016 18:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 4WmtHCgxqCtD for ; Sun, 27 Mar 2016 18:01:03 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8252712D507 for ; Sun, 27 Mar 2016 17:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6181; q=dns/txt; s=iport; t=1459126311; x=1460335911; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qFe8q9Aa6AfyC4TJPmiS4OTBL+mSY8yrRbTuRUw7UAo=; b=IVeTERafUsmWQdyX0L4KdJwCvYF18dRBw/wXPuL5WOP3HuP8ZHEufbn/ jmAhyzSf1MAfCgBvPxJ94wKPQEZcGFE4DldchUbYQInG8Knov3YUwu1xv +m3xyomHTzPmvw34JyqScDtdxLEbvuW/RX9ZegDU/C3APq55NuxS2S+JR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgDffvhW/4oNJK1cgmJMU32FQ7A5h?= =?us-ascii?q?G4BDYFwFwEJhBWBDUoCgR84FAEBAQEBAQFkJ4RCAQEEAQEBawsQAgEIPwcnCxQ?= =?us-ascii?q?RAgQOBYgnDsAZAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGHoFzglGEJEWCfoIrB?= =?us-ascii?q?ZMGhFsBhXCIFY8LjwoBHgEBQoFMghlsAQGIVAEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,403,1454976000"; d="scan'208,217";a="254331738" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2016 00:51:50 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2S0poAL024989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Mar 2016 00:51:50 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 27 Mar 2016 19:51:49 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Sun, 27 Mar 2016 19:51:49 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Roman Shpount Thread-Topic: [sipcore] Outline of a SIP-DTLS document Thread-Index: AQHRiG+IThrlCZCJGEy2Md9stmtXEJ9uKJ8A///eh8s= Date: Mon, 28 Mar 2016 00:51:49 +0000 Message-ID: <61244F12-BD4F-4A5D-9DFA-7FD875AFE777@cisco.com> References: <87fuvb1ui4.fsf@hobgoblin.ariadne.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_61244F12BD4F4A5D9DFA7FD875AFE777ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Outline of a SIP-DTLS document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 01:01:05 -0000 --_000_61244F12BD4F4A5D9DFA7FD875AFE777ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 As I've told Dale privately, I'm interested in pursuing this and willing to= contribute to it. Regards, Gonzalo On Mar 27, 2016, at 6:51 PM, Roman Shpount > wrote: I obviously do this think this is worth pursuing. Few more comments inline. On Sun, Mar 27, 2016 at 5:27 PM, Dale R. Worley > wrote: REQ: If a client's flow becomes invalidated at the server (e.g., due to a change in the client's public address), the client must be able to detect this fact quickly (within a few RTTs), so that it can reestablish a flow quickly to prevent outstanding transactions from failing. *** Is this needed? Is this possible? Typically using STUN keep alive messages (https://tools.ietf.org/html/rfc56= 26#section-3.5.2) allows UDP client detect that it's public address changed= and re-register. To prevent call dialogs from being torn down by SIP sessi= on timer this requires flow failure detection that is faster then typical t= ransaction timeout (32 sec) which is possible with keep alive messages sent= every 10-15 sec vs recommended 24-29 sec. REQ: If a client's flow becomes invalidated at the server due to a change in the client's public address, the client must be able to recover in a way that does not invalidate the route set of existing dialogs. *** Presumably this requires using GRUUs, which would be specified in the document. Is it possible to make this work? It should be possible to indicate that this is the same device being regist= ered and allow to preserve the same GRUU. Once more benefit to consider -- DTLS provides message fragmentation suppor= t which will allow using such DTLS based protocol with larger sized SIP mes= sages that do not fit into a single UDP packet. Regards, _____________ Roman Shpount _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_61244F12BD4F4A5D9DFA7FD875AFE777ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

As I've told Dale privately, I'm interested = in pursuing this and willing to contribute to it.

Regards,

Gonzalo



On Mar 27, 2016, at 6:51 PM, Roman Shpount <roman@telurix.com> wrote:

I obviously do this think this is worth pursuing.

Few more comments inline.

On Sun, Mar 27, 2016 at 5:27 PM, Dale R. Worley = <worley@ariadne.= com> wrote:
REQ:  If a client's flow becomes invalidated at the server (e.g., due<= br> to a change in the client's public address), the client must be able
to detect this fact quickly (within a few RTTs), so that it can
reestablish a flow quickly to prevent outstanding transactions from
failing.

*** Is this needed?  Is this possible?

Typically using STUN keep alive messages (https://tools.ietf.org/html/rfc5626#secti= on-3.5.2) allows UDP client detect that it's public address changed and= re-register. To prevent call dialogs from being torn down by SIP session timer this requires flow failure detec= tion that is faster then typical transaction timeout (32 sec) which is poss= ible with keep alive messages sent every 10-15 sec vs recommended 24-29 sec= .

REQ:  If a client's flow becomes invalidated at the server due to a change in the client's public address, the client must be able to
recover in a way that does not invalidate the route set of existing
dialogs.

*** Presumably this requires using GRUUs, which would be specified in
the document.  Is it possible to make this work?
 
It should be possible to indicate that this is the same device being r= egistered and allow to preserve the same GRUU.

Once more benefit to consider -- DTLS provides message fragmentation s= upport which will allow using such DTLS based protocol with larger sized SI= P messages that do not fit into a single UDP packet.

Regards,
_____________
Roman Shpount

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_61244F12BD4F4A5D9DFA7FD875AFE777ciscocom_-- From nobody Mon Mar 28 01:37:43 2016 Return-Path: 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 31D4112D105 for ; Mon, 28 Mar 2016 01:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 2zD1m4fCZ1Pz for ; Mon, 28 Mar 2016 01:37:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0687.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:687]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F5B12D0F9 for ; Mon, 28 Mar 2016 01:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3dpmqDfd3BccF2NZ1TAaBdJg1MBkjPUao/kpKqy4tzA=; b=jPeIEGTXVrvczeWfg9u0g0d8ewAX+R7d/ZAhVCNNXIk4J0cBdp3455+jCIi+aIgilsJvHAG+mMYdyndCVznBzCcyxmgz6Qnu+4quhsFWXInlBBoW+Rh0AiySiXvB+lkpWp/UNws5stH3teV2l4VRlZiNQpVbw1GlUU8oujG7S98= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.443.12; Mon, 28 Mar 2016 08:37:18 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0443.016; Mon, 28 Mar 2016 08:37:18 +0000 From: "Asveren, Tolga" To: "Gonzalo Salgueiro (gsalguei)" , Roman Shpount Thread-Topic: [sipcore] Outline of a SIP-DTLS document Thread-Index: AQHRiG+IG3jvQ7CeXEuEksCuHMJLCp9t1M4AgAAyWICAAIEYsA== Date: Mon, 28 Mar 2016 08:37:18 +0000 Message-ID: References: <87fuvb1ui4.fsf@hobgoblin.ariadne.com>, <61244F12-BD4F-4A5D-9DFA-7FD875AFE777@cisco.com> In-Reply-To: <61244F12-BD4F-4A5D-9DFA-7FD875AFE777@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 429017ef-57a7-407a-24f5-08d356e42c20 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:B0f3iIuHKJ3V0seF0iCgj4cSIRsyZt9qLbYSjsK+esrycb3gitDK8bVw+7W7rf5lFkXBJzM4a3osqkoE/0+sdvi5GkjPbCGJFx9CGd+kGHiJ2p0YsixQVH/93cdS1GlKyMVzmKMyU2nFWa9uXwhzPA==; 24:7+W5rq9UdyPPG/G9tA+Nq2JqgF2OsAnia/IxUBa9gVcpIFBLvDdXRmsmfyeTCjVHP9KLzvSZmCjLOzPxRgAqmTZ/jowojz39p0dhs1UCpow= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0895DF8FFD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(164054003)(377454003)(24454002)(76576001)(74316001)(66066001)(81166005)(790700001)(6116002)(586003)(19609705001)(86362001)(3846002)(19580405001)(19580395003)(5003600100002)(122556002)(551934003)(189998001)(1220700001)(99286002)(33656002)(19617315012)(92566002)(87936001)(5004730100002)(5001770100001)(1096002)(2950100001)(19625215002)(15975445007)(77096005)(3660700001)(11100500001)(2900100001)(16236675004)(3280700002)(106116001)(5008740100001)(2906002)(54356999)(76176999)(19300405004)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155139FD1586CDAAA8096109B2860SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2016 08:37:18.0489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Outline of a SIP-DTLS document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 08:37:42 -0000 --_000_SN1PR0301MB155139FD1586CDAAA8096109B2860SN1PR0301MB1551_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, certainly interesting/valuable work. And the same here as far as contributing is concerned. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Salgue= iro (gsalguei) Sent: Sunday, March 27, 2016 8:52 PM To: Roman Shpount Cc: Dale R. Worley ; sipcore@ietf.org Subject: Re: [sipcore] Outline of a SIP-DTLS document +1 As I've told Dale privately, I'm interested in pursuing this and willing to= contribute to it. Regards, Gonzalo On Mar 27, 2016, at 6:51 PM, Roman Shpount > wrote: I obviously do this think this is worth pursuing. Few more comments inline. On Sun, Mar 27, 2016 at 5:27 PM, Dale R. Worley > wrote: REQ: If a client's flow becomes invalidated at the server (e.g., due to a change in the client's public address), the client must be able to detect this fact quickly (within a few RTTs), so that it can reestablish a flow quickly to prevent outstanding transactions from failing. *** Is this needed? Is this possible? Typically using STUN keep alive messages (https://tools.ietf.org/html/rfc56= 26#section-3.5.2) allows UDP client detect that it's public address changed= and re-register. To prevent call dialogs from being torn down by SIP sessi= on timer this requires flow failure detection that is faster then typical t= ransaction timeout (32 sec) which is possible with keep alive messages sent= every 10-15 sec vs recommended 24-29 sec. REQ: If a client's flow becomes invalidated at the server due to a change in the client's public address, the client must be able to recover in a way that does not invalidate the route set of existing dialogs. *** Presumably this requires using GRUUs, which would be specified in the document. Is it possible to make this work? It should be possible to indicate that this is the same device being regist= ered and allow to preserve the same GRUU. Once more benefit to consider -- DTLS provides message fragmentation suppor= t which will allow using such DTLS based protocol with larger sized SIP mes= sages that do not fit into a single UDP packet. Regards, _____________ Roman Shpount _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_SN1PR0301MB155139FD1586CDAAA8096109B2860SN1PR0301MB1551_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, certainly interesting/valuable w= ork.

 

And the same here as far as contribut= ing is concerned.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Sunday, March 27, 2016 8:52 PM
To: Roman Shpount <roman@telurix.com>
Cc: Dale R. Worley <worley@ariadne.com>; sipcore@ietf.org
Subject: Re: [sipcore] Outline of a SIP-DTLS document

 

+1

 

As I've told Dale pri= vately, I'm interested in pursuing this and willing to contribute to it.

Regards,

 

Gonzalo

 

 


On Mar 27, 2016, at 6:51 PM, Roman Shpount <roman@telurix.com> wrote:

I obviously do this think this is worth pursuing.

 

Few more comments inline.

 

On Sun, Mar 27, 2016 at 5:27 PM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:

REQ:  If a client's flow becomes invalidated at= the server (e.g., due
to a change in the client's public address), the client must be able
to detect this fact quickly (within a few RTTs), so that it can
reestablish a flow quickly to prevent outstanding transactions from
failing.

*** Is this needed?  Is this possible?

 

Typically using STUN keep alive messages (https://tools.ietf.org/= html/rfc5626#section-3.5.2) allows UDP client detect that it's public a= ddress changed and re-register. To prevent call dialogs from being torn down by SIP session timer this requires flow = failure detection that is faster then typical transaction timeout (32 sec) = which is possible with keep alive messages sent every 10-15 sec vs recommen= ded 24-29 sec.

 

REQ:  If a client's flow becomes invalidated at= the server due to a
change in the client's public address, the client must be able to
recover in a way that does not invalidate the route set of existing
dialogs.

*** Presumably this requires using GRUUs, which would be specified in
the document.  Is it possible to make this work?

 

It should be possible to indicate that this is the s= ame device being registered and allow to preserve the same GRUU.=

 

Once more benefit to consider -- DTLS provides messa= ge fragmentation support which will allow using such DTLS based protocol wi= th larger sized SIP messages that do not fit into a single UDP packet.=

 

Regards,

_____________
Roman Shpount

 

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

--_000_SN1PR0301MB155139FD1586CDAAA8096109B2860SN1PR0301MB1551_-- From nobody Mon Mar 28 14:41:22 2016 Return-Path: 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 F02B812D116 for ; Mon, 28 Mar 2016 14:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 B9h7f67SgjyH for ; Mon, 28 Mar 2016 14:41:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2B512D196 for ; Mon, 28 Mar 2016 14:41:11 -0700 (PDT) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2SLfAsV000343 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 28 Mar 2016 16:41:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: sipcore@ietf.org References: <56F01C7F.5000507@nostrum.com> From: Robert Sparks Message-ID: <56F9A4F7.1020709@nostrum.com> Date: Mon, 28 Mar 2016 16:41:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F01C7F.5000507@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 21:41:21 -0000 I have one comment that should be addressed before requesting publication of this document. I find the formulation of section 5 confusing, and possibly misleading. I think it is too terse, and it unnecessarily trips up on some provenance pointers. 6157 doesn't defer to 6724 - it points out implementers should rely on a new system function call and that the function call is expected to implement an algorithm specified in 3484. The description of that algorithm is updated in 6724. But why are you pointing here anyhow? How is it going to help the implementer? If you're saying the implementer needs to make sure their _own code_ implements what 6724 describes (as opposed to relying on a system call), the words in this document need to be very different. If you're saying, instead, that they should just rely on getaddrinfo() after having done the SRV work and ordering to resolve A or AAAA records (and trust the order it returns the in), just say that. It's really not clear _what_ in 6157 this is clarifying. RjS On 3/21/16 11:08 AM, Adam Roach wrote: > [as chair] > > Today marks the start of a three-week Working Group Last Call for the > following document: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-dns-dual-stack/ > > The end of this last call is specifically intended to end on the > Friday of the upcoming face-to-face meeting in Buenos Aires. Our plan > is to ask the authors to incorporate any feedback received during > these final weeks as well as comments from the face-to-face meeting > into a version of the document that will be ready to send to the IESG. > > All Working Group participants are requested to review the document > and send comments to the SIPCORE mailing list. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Mar 29 11:53:42 2016 Return-Path: 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 BC6AC12DCB3 for ; Tue, 29 Mar 2016 11:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZtH0MHJ5LTNi for ; Tue, 29 Mar 2016 11:53:40 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A75D12E254 for ; Tue, 29 Mar 2016 11:19:23 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by comcast with SMTP id kyB2aXtg6WYeakyEcaEhbx; Tue, 29 Mar 2016 18:19:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459275562; bh=u+uEFzSLlsr7UrI9AtmeWR4N0pybiNFoKpbqF97vNwg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=pJHc/3sKBb7YhzeYwUYwQlrTyA4+4sk1/FX0kaTtUuIsc1HOxc6VCCrCngUDoS3a8 IRm0Fx3LSLQ6LPDpyOyo3d7xQR2jiSqxNmOSSrwS/v7ysOUvhchCX+MFaFzh7D4d7q MTJ0dgHTFdNaXmso2mLSZr0FwOSnTk6p+eDwqqW/6daTt6gvT8Bm0j67Rh8cajbw/R ei3FTjZCUF2fiC4r30ZYEl/XWJkik5loVqYqK/tO6e5Qj4YrhtV6l8QL3Yq3S0qajq ZcD4h/inNNl+6y6hT0BEoucBPABixn4xtAPzHcZlaapepEjVhC4zxrQ01PRdBTfDuk DFmo2y8z+tBCQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-19v.sys.comcast.net with comcast id buKM1s00b1nMCLR01uKNkn; Tue, 29 Mar 2016 18:19:22 +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 u2TIJL18023529; Tue, 29 Mar 2016 14:19:21 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2TIJKP9023523; Tue, 29 Mar 2016 14:19:20 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Robert Sparks In-Reply-To: <56F9A4F7.1020709@nostrum.com> (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 29 Mar 2016 14:19:20 -0400 Message-ID: <87poudw3iv.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 18:53:42 -0000 Robert Sparks writes: > It's really not clear _what_ in 6157 [section 5 of this draft] is clarifying. You're right. The current section 5 is my revision of the section 5 in the -02 draft, which is 5. Update to RFC 6157 [RFC6157] defers to the Source and Destination Address Selection algorithms defined in [RFC6724] (the successor of [RFC3484]) when allowing a client to choose a specific server (c.f. Section 5 in [RFC6157]). This document modifies the behavior of Section 5 in [RFC6157] to allow for an additional (and preferred) way to contact servers, as outlined in Section Section 4.2. Implementations MUST use the DNS SRV records as described in Section Section 4.2 of this document first before resorting to the Source and Destination Address Selection algorithms defined in [RFC6724]. As far as I can tell, the goal of this section is to make it clear that if SRV records translate a SIP domain into (e.g.) two SRV records with different priorities, and one SRV record's target name only has IPv4 addresses and the other SRV record's target name only has IPv6 addresses, then which family of addresses is attempted first is to be determined by priorities of the SRV records. This being the process described in section 4.2 of this draft. The alternative that the implementor seems to be being warned to avoid seems to be to put both the IPv4 and IPv6 addresses together into the algorithm of 3484/6724 and having it order the destination addresses. I don't think this is an update of 6157 (as the section title suggests), as following 3263 as written gives the behavior described in section 4.2 of this draft. And that seems to be the behavior that 6157 will result in as well, as 6157 seems to describe putting each SRV's target into getaddrinfo() separately to obtain the target's destination addresses. So I would say that eliminating this section entirely would not change the meaning of the draft. But that leaves open what this section was intended to accomplish. I'll ask the other authors. Dale From nobody Wed Mar 30 07:53:40 2016 Return-Path: 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 4678512D769 for ; Wed, 30 Mar 2016 07:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 R0MAu3x787mD for ; Wed, 30 Mar 2016 07:53:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0329B12D76E for ; Wed, 30 Mar 2016 07:53:26 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UErJ4v051489 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Mar 2016 09:53:20 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Dale R. Worley" , Robert Sparks References: <87poudw3iv.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <56FBE85F.6080707@nostrum.com> Date: Wed, 30 Mar 2016 09:53:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <87poudw3iv.fsf@hobgoblin.ariadne.com> Content-Type: multipart/alternative; boundary="------------070606040505000907060809" Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 14:53:39 -0000 This is a multi-part message in MIME format. --------------070606040505000907060809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as individual] On 3/29/16 13:19, Dale R. Worley wrote: > As far as I can tell, the goal of this section is to make it clear that > if SRV records translate a SIP domain into (e.g.) two SRV records with > different priorities, and one SRV record's target name only has IPv4 > addresses and the other SRV record's target name only has IPv6 > addresses, then which family of addresses is attempted first is to be > determined by priorities of the SRV records. This being the process > described in section 4.2 of this draft. I think it's somewhat more general than that, though. if you look up an SRV record and get multiple A and multiple AAAA records, and those records in turn contain multiple literal IP addresses, then you apply the SRV priorities first and the RFC 6724 processes second. I think an example might help. Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries: _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com: sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce sip-1.example.com. 1800 IN A 192.0.2.45 sip-1.example.com. 1800 IN A 203.0.113.109 sip-1.example.com. 1800 IN A 198.51.100.24 sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de sip-2.example.com. 1800 IN A 192.0.2.75 sip-2.example.com. 1800 IN A 203.0.113.38 sip-2.example.com. 1800 IN A 198.51.100.140 What I believe we're saying is that I will process these addresses in a batch, altogether, using RFC6724 section 6 rules: * 2001:0db8:58:c02::face * 2001:0db8:c:a06::2:cafe * 2001:0db8:44:204::d1ce * 192.0.2.45 * 203.0.113.109 * 198.51.100.24 And then (but only then, after I've exhausted that entire batch of addresses), I'll process these addresses in a batch, altogether, using RFC6724 section 6 rules: * 2001:0db8:58:c02::dead * 2001:0db8:c:a06::2:beef * 2001:0db8:44:204::c0de * 192.0.2.75 * 203.0.113.38 * 198.51.100.140 ... and, most importantly, I won't mix the batches together. /a --------------070606040505000907060809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as individual]

On 3/29/16 13:19, Dale R. Worley wrote:
As far as I can tell, the goal of this section is to make it clear that
if SRV records translate a SIP domain into (e.g.) two SRV records with
different priorities, and one SRV record's target name only has IPv4
addresses and the other SRV record's target name only has IPv6
addresses, then which family of addresses is attempted first is to be
determined by priorities of the SRV records.  This being the process
described in section 4.2 of this draft.

I think it's somewhat more general than that, though. if you look up an SRV record and get multiple A and multiple AAAA records, and those records in turn contain multiple literal IP addresses, then you apply the SRV priorities first and the RFC 6724 processes second.

I think an example might help.

Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries:

_sip._tcp.example.com.  300 IN  SRV  10 1 5060 sip-1.example.com.
_sip._tcp.example.com.  300 IN  SRV  20 1 5060 sip-2.example.com.


So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com:

sip-1.example.com.    300  IN  AAAA  2001:0db8:58:c02::face
sip-1.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:cafe
sip-1.example.com.    300  IN  AAAA  2001:0db8:44:204::d1ce

sip-1.example.com.    1800  IN  A  192.0.2.45
sip-1.example.com.    1800  IN  A  203.0.113.109
sip-1.example.com.    1800  IN  A  198.51.100.24

sip-2.example.com.    300  IN  AAAA  2001:0db8:58:c02::dead
sip-2.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:beef
sip-2.example.com.    300  IN  AAAA  2001:0db8:44:204::c0de

sip-2.example.com.    1800  IN  A  192.0.2.75
sip-2.example.com.    1800  IN  A  203.0.113.38
sip-2.example.com.    1800  IN  A  198.51.100.140


What I believe we're saying is that I will process these addresses in a batch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::face
  • 2001:0db8:c:a06::2:cafe
  • 2001:0db8:44:204::d1ce
  • 192.0.2.45
  • 203.0.113.109
  • 198.51.100.24

And then (but only then, after I've exhausted that entire batch of addresses), I'll process these addresses in a batch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::dead
  • 2001:0db8:c:a06::2:beef
  • 2001:0db8:44:204::c0de
  • 192.0.2.75
  • 203.0.113.38
  • 198.51.100.140

... and, most importantly, I won't mix the batches together.

/a
--------------070606040505000907060809-- From nobody Wed Mar 30 08:00:47 2016 Return-Path: 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 17E9012D69A for ; Wed, 30 Mar 2016 08:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 CCxJTyKwM8Lv for ; Wed, 30 Mar 2016 08:00:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE1812D19F for ; Wed, 30 Mar 2016 08:00:43 -0700 (PDT) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UF0dd5052575 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 30 Mar 2016 10:00:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: Adam Roach , "Dale R. Worley" References: <87poudw3iv.fsf@hobgoblin.ariadne.com> <56FBE85F.6080707@nostrum.com> From: Robert Sparks Message-ID: <56FBEA17.2040501@nostrum.com> Date: Wed, 30 Mar 2016 10:00:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FBE85F.6080707@nostrum.com> Content-Type: multipart/alternative; boundary="------------050601020001040302070007" Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 15:00:46 -0000 This is a multi-part message in MIME format. --------------050601020001040302070007 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/30/16 9:53 AM, Adam Roach wrote: > [as individual] > > On 3/29/16 13:19, Dale R. Worley wrote: >> As far as I can tell, the goal of this section is to make it clear that >> if SRV records translate a SIP domain into (e.g.) two SRV records with >> different priorities, and one SRV record's target name only has IPv4 >> addresses and the other SRV record's target name only has IPv6 >> addresses, then which family of addresses is attempted first is to be >> determined by priorities of the SRV records. This being the process >> described in section 4.2 of this draft. > > I think it's somewhat more general than that, though. if you look up > an SRV record and get multiple A and multiple AAAA records, and those > records in turn contain multiple literal IP addresses, then you apply > the SRV priorities first and the RFC 6724 processes second. Nit pick - Your sentence above starts "if you look up an SRV record" (that is _one_ SRV record). There are no SRV priorities to apply (beyond the trivial "take the one I have"). Your example below of showing prioritizing multiple SRV records first using the SRV prioritization rules, then applying the 6724 rules only when looking at a set of A/AAAA for a single SRV record makes sense. > > I think an example might help. > > Let's say I look up an SRV record (_sip._tcp.example.com) and get back > two entries: > > _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. > _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. > > > So then I grab the A and AAAA records for sip-1.example.com and > sip-2.example.com: > > sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face > sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe > sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce > > sip-1.example.com. 1800 IN A 192.0.2.45 > sip-1.example.com. 1800 IN A 203.0.113.109 > sip-1.example.com. 1800 IN A 198.51.100.24 > > sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead > sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef > sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de > > sip-2.example.com. 1800 IN A 192.0.2.75 > sip-2.example.com. 1800 IN A 203.0.113.38 > sip-2.example.com. 1800 IN A 198.51.100.140 > > > What I believe we're saying is that I will process these addresses in > a batch, altogether, using RFC6724 section 6 rules: > > * 2001:0db8:58:c02::face > * 2001:0db8:c:a06::2:cafe > * 2001:0db8:44:204::d1ce > * 192.0.2.45 > * 203.0.113.109 > * 198.51.100.24 > > > And then (but only then, after I've exhausted that entire batch of > addresses), I'll process these addresses in a batch, altogether, using > RFC6724 section 6 rules: > > * 2001:0db8:58:c02::dead > * 2001:0db8:c:a06::2:beef > * 2001:0db8:44:204::c0de > * 192.0.2.75 > * 203.0.113.38 > * 198.51.100.140 > > > ... and, most importantly, I won't mix the batches together. > > /a --------------050601020001040302070007 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 3/30/16 9:53 AM, Adam Roach wrote:
[as individual]

On 3/29/16 13:19, Dale R. Worley wrote:
As far as I can tell, the goal of this section is to make it clear that
if SRV records translate a SIP domain into (e.g.) two SRV records with
different priorities, and one SRV record's target name only has IPv4
addresses and the other SRV record's target name only has IPv6
addresses, then which family of addresses is attempted first is to be
determined by priorities of the SRV records.  This being the process
described in section 4.2 of this draft.

I think it's somewhat more general than that, though. if you look up an SRV record and get multiple A and multiple AAAA records, and those records in turn contain multiple literal IP addresses, then you apply the SRV priorities first and the RFC 6724 processes second.
Nit pick - Your sentence above starts "if you look up an SRV record"  (that is _one_ SRV record).
There are no SRV priorities to apply (beyond the trivial "take the one I have").

Your example below of showing prioritizing multiple SRV records first using the SRV prioritization rules,
then applying the 6724 rules only when looking at a set of A/AAAA for a single SRV record makes sense.

I think an example might help.

Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries:

_sip._tcp.example.com.  300 IN  SRV  10 1 5060 sip-1.example.com.
_sip._tcp.example.com.  300 IN  SRV  20 1 5060 sip-2.example.com.


So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com:

sip-1.example.com.    300  IN  AAAA  2001:0db8:58:c02::face
sip-1.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:cafe
sip-1.example.com.    300  IN  AAAA  2001:0db8:44:204::d1ce

sip-1.example.com.    1800  IN  A  192.0.2.45
sip-1.example.com.    1800  IN  A  203.0.113.109
sip-1.example.com.    1800  IN  A  198.51.100.24

sip-2.example.com.    300  IN  AAAA  2001:0db8:58:c02::dead
sip-2.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:beef
sip-2.example.com.    300  IN  AAAA  2001:0db8:44:204::c0de

sip-2.example.com.    1800  IN  A  192.0.2.75
sip-2.example.com.    1800  IN  A  203.0.113.38
sip-2.example.com.    1800  IN  A  198.51.100.140


What I believe we're saying is that I will process these addresses in a batch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::face
  • 2001:0db8:c:a06::2:cafe
  • 2001:0db8:44:204::d1ce
  • 192.0.2.45
  • 203.0.113.109
  • 198.51.100.24

And then (but only then, after I've exhausted that entire batch of addresses), I'll process these addresses in a batch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::dead
  • 2001:0db8:c:a06::2:beef
  • 2001:0db8:44:204::c0de
  • 192.0.2.75
  • 203.0.113.38
  • 198.51.100.140

... and, most importantly, I won't mix the batches together.

/a

--------------050601020001040302070007-- From nobody Wed Mar 30 08:02:14 2016 Return-Path: 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 D4B0F12D589 for ; Wed, 30 Mar 2016 08:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JLJcHzQic6FJ for ; Wed, 30 Mar 2016 08:01:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id EC00812D75B for ; Wed, 30 Mar 2016 08:01:52 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7D31C93DE4A; Wed, 30 Mar 2016 15:01:04 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_90EA9370-99FD-4F83-8B7B-9EB7DB8C059C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: "Olle E. Johansson" In-Reply-To: <56FBE85F.6080707@nostrum.com> Date: Wed, 30 Mar 2016 17:01:30 +0200 Message-Id: References: <87poudw3iv.fsf@hobgoblin.ariadne.com> <56FBE85F.6080707@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , sipcore@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 15:02:13 -0000 --Apple-Mail=_90EA9370-99FD-4F83-8B7B-9EB7DB8C059C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Mar 2016, at 16:53, Adam Roach wrote: >=20 > [as individual] >=20 > On 3/29/16 13:19, Dale R. Worley wrote: >> As far as I can tell, the goal of this section is to make it clear = that >> if SRV records translate a SIP domain into (e.g.) two SRV records = with >> different priorities, and one SRV record's target name only has IPv4 >> addresses and the other SRV record's target name only has IPv6 >> addresses, then which family of addresses is attempted first is to be >> determined by priorities of the SRV records. This being the process >> described in section 4.2 of this draft. >=20 > I think it's somewhat more general than that, though. if you look up = an SRV record and get multiple A and multiple AAAA records, and those = records in turn contain multiple literal IP addresses, then you apply = the SRV priorities first and the RFC 6724 processes second. >=20 > I think an example might help. >=20 > Let's say I look up an SRV record (_sip._tcp.example.com) and get back = two entries: >=20 > _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. > _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. >=20 >=20 > So then I grab the A and AAAA records for sip-1.example.com and = sip-2.example.com: >=20 > sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face > sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe > sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce >=20 > sip-1.example.com. 1800 IN A 192.0.2.45 > sip-1.example.com. 1800 IN A 203.0.113.109 > sip-1.example.com. 1800 IN A 198.51.100.24 >=20 > sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead > sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef > sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de >=20 > sip-2.example.com. 1800 IN A 192.0.2.75 > sip-2.example.com. 1800 IN A 203.0.113.38 > sip-2.example.com. 1800 IN A 198.51.100.140 >=20 >=20 > What I believe we're saying is that I will process these addresses in = a batch, altogether, using RFC6724 section 6 rules: > 2001:0db8:58:c02::face > 2001:0db8:c:a06::2:cafe > 2001:0db8:44:204::d1ce > 192.0.2.45 > 203.0.113.109 > 198.51.100.24 >=20 > And then (but only then, after I've exhausted that entire batch of = addresses), I'll process these addresses in a batch, altogether, using = RFC6724 section 6 rules: > 2001:0db8:58:c02::dead > 2001:0db8:c:a06::2:beef > 2001:0db8:44:204::c0de > 192.0.2.75 > 203.0.113.38 > 198.51.100.140 >=20 > ... and, most importantly, I won't mix the batches together. I agree. This example is something we need to carry with us to the actual Happy = Eyeballs draft. How do we handle=20 connection setup with dual stacks with all six candidates - i.e. more = than two. RFC 2782 is quite clear that=20 we need to test *ALL* SRV candidates for a selected name (after load = balancing decision) before proceeding to another priority. I need to check the Happy Eyeballs RFC unless Dan Wing reads this and = can comment :-) Cheers /O --Apple-Mail=_90EA9370-99FD-4F83-8B7B-9EB7DB8C059C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 30 Mar 2016, at 16:53, Adam Roach <adam@nostrum.com> wrote:

[as individual]

On 3/29/16 13:19, Dale R. Worley wrote:
As far as I can tell, the goal of this section is to make it clear that
if SRV records translate a SIP domain into (e.g.) two SRV records with
different priorities, and one SRV record's target name only has IPv4
addresses and the other SRV record's target name only has IPv6
addresses, then which family of addresses is attempted first is to be
determined by priorities of the SRV records.  This being the process
described in section 4.2 of this draft.

I think it's somewhat more general than that, though. if you look up an SRV record and get multiple A and multiple AAAA records, and those records in turn contain multiple literal IP addresses, then you apply the SRV priorities first and the RFC 6724 processes second.

I think an example might help.

Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries:

_sip._tcp.example.com.  300 IN  SRV  10 1 5060 sip-1.example.com.
_sip._tcp.example.com.  300 IN  SRV  20 1 5060 sip-2.example.com.


So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com:

sip-1.example.com.    300  IN  AAAA  2001:0db8:58:c02::face
sip-1.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:cafe
sip-1.example.com.    300  IN  AAAA  2001:0db8:44:204::d1ce

sip-1.example.com.    1800  IN  A  192.0.2.45
sip-1.example.com.    1800  IN  A  203.0.113.109
sip-1.example.com.    1800  IN  A  198.51.100.24

sip-2.example.com.    300  IN  AAAA  2001:0db8:58:c02::dead
sip-2.example.com.    300  IN  AAAA  2001:0db8:c:a06::2:beef
sip-2.example.com.    300  IN  AAAA  2001:0db8:44:204::c0de

sip-2.example.com.    1800  IN  A  192.0.2.75
sip-2.example.com.    1800  IN  A  203.0.113.38
sip-2.example.com.    1800  IN  A  198.51.100.140


What I believe we're saying is that I will process these addresses in a batch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::face
  • 2001:0db8:c:a06::2:cafe
  • 2001:0db8:44:204::d1ce
  • 192.0.2.45
  • 203.0.113.109
  • 198.51.100.24

And then (but only then, after I've exhausted that entire batch of addresses), I'll process these addresses in a batch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::dead
  • 2001:0db8:c:a06::2:beef
  • 2001:0db8:44:204::c0de
  • 192.0.2.75
  • 203.0.113.38
  • 198.51.100.140

... and, most importantly, I won't mix the batches together.
I agree.

This example is something we need to carry with us to the actual Happy Eyeballs draft. How do we handle 
connection setup with dual stacks with all six candidates - i.e. more than two. RFC 2782 is quite clear that 
we need to test *ALL* SRV candidates for a selected name (after load balancing decision) before proceeding to another priority.
I need to check the Happy Eyeballs RFC unless Dan Wing reads this and can comment :-)

Cheers
/O

--Apple-Mail=_90EA9370-99FD-4F83-8B7B-9EB7DB8C059C-- From nobody Wed Mar 30 09:10:31 2016 Return-Path: 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 B593012D7C5 for ; Wed, 30 Mar 2016 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 wyd9fj3jSlQ4 for ; Wed, 30 Mar 2016 09:10:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6E412D5E2 for ; Wed, 30 Mar 2016 09:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10030; q=dns/txt; s=iport; t=1459354222; x=1460563822; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XcuozemVw5UexVAM3uGQPRWd0JGZd/HVce7sTmY0/Qo=; b=B4d6lfCb2jwFhvoL7SfFbE5o7zqHG5t+EwE78JVLzv9Kld6WSVc6ePVf XW46H2gbozbwG6E5mlkj4yGdzNXd5oF2J4FNMIn0tzHG8FDh7nwXvEe+k c5mEy0TE+EAcOeNuhZHsB/m6koOw4G/EUPHe5ngdmL9rj+yl0+rQI/bhH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgCk+ftW/4oNJK1dgzNTfYVDsEyEb?= =?us-ascii?q?wENgXAXAQmEFYENSgKBSzgUAQEBAQEBAWQnhEIBAQQBAQFrCxACAQgOMQcnCxQ?= =?us-ascii?q?RAgQOBYgnDsEtAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYegXQIgkmEaxGCbYIrB?= =?us-ascii?q?Y1FhUqEXwGFcYgVgjSMWY8PAQ8PAQFCgUyCG2yIPwEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,417,1454976000"; d="scan'208,217"; a="91750250" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2016 16:10:21 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2UGALIf016355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2016 16:10:21 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Mar 2016 11:10:20 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Wed, 30 Mar 2016 11:10:20 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Robert Sparks Thread-Topic: [sipcore] WGLC: draft-ietf-sip-dual-stack Thread-Index: AQHRieeDbGR3G48gDEunulxvPvm8rJ9yZ86AgAACDID//7+nVA== Date: Wed, 30 Mar 2016 16:10:20 +0000 Message-ID: References: <87poudw3iv.fsf@hobgoblin.ariadne.com> <56FBE85F.6080707@nostrum.com>,<56FBEA17.2040501@nostrum.com> In-Reply-To: <56FBEA17.2040501@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_F0DCC195E98348249FF39AE36B80A4D3ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 16:10:30 -0000 --_000_F0DCC195E98348249FF39AE36B80A4D3ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 30, 2016, at 12:00 PM, Robert Sparks > wrote: On 3/30/16 9:53 AM, Adam Roach wrote: [as individual] On 3/29/16 13:19, Dale R. Worley wrote: As far as I can tell, the goal of this section is to make it clear that if SRV records translate a SIP domain into (e.g.) two SRV records with different priorities, and one SRV record's target name only has IPv4 addresses and the other SRV record's target name only has IPv6 addresses, then which family of addresses is attempted first is to be determined by priorities of the SRV records. This being the process described in section 4.2 of this draft. I think it's somewhat more general than that, though. if you look up an SRV= record and get multiple A and multiple AAAA records, and those records in = turn contain multiple literal IP addresses, then you apply the SRV prioriti= es first and the RFC 6724 processes second. Nit pick - Your sentence above starts "if you look up an SRV record" (that= is _one_ SRV record). There are no SRV priorities to apply (beyond the trivial "take the one I ha= ve"). Your example below of showing prioritizing multiple SRV records first using= the SRV prioritization rules, then applying the 6724 rules only when looking at a set of A/AAAA for a sin= gle SRV record makes sense. I agree and urging it might be tremendously useful to use such an example i= n the draft to unambiguously drive the point home. -G I think an example might help. Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries: _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-= 1.example.com. _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-= 2.example.com. So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com: sip-1.example.com. 300 IN AAAA 2001:0db8:58= :c02::face sip-1.example.com. 300 IN AAAA 2001:0db8:c:= a06::2:cafe sip-1.example.com. 300 IN AAAA 2001:0db8:44= :204::d1ce sip-1.example.com. 1800 IN A 192.0.2.45 sip-1.example.com. 1800 IN A 203.0.113.109 sip-1.example.com. 1800 IN A 198.51.100.24 sip-2.example.com. 300 IN AAAA 2001:0db8:58= :c02::dead sip-2.example.com. 300 IN AAAA 2001:0db8:c:= a06::2:beef sip-2.example.com. 300 IN AAAA 2001:0db8:44= :204::c0de sip-2.example.com. 1800 IN A 192.0.2.75 sip-2.example.com. 1800 IN A 203.0.113.38 sip-2.example.com. 1800 IN A 198.51.100.140 What I believe we're saying is that I will process these addresses in a bat= ch, altogether, using RFC6724 section 6 rules: * 2001:0db8:58:c02::face * 2001:0db8:c:a06::2:cafe * 2001:0db8:44:204::d1ce * 192.0.2.45 * 203.0.113.109 * 198.51.100.24 And then (but only then, after I've exhausted that entire batch of addresse= s), I'll process these addresses in a batch, altogether, using RFC6724 sect= ion 6 rules: * 2001:0db8:58:c02::dead * 2001:0db8:c:a06::2:beef * 2001:0db8:44:204::c0de * 192.0.2.75 * 203.0.113.38 * 198.51.100.140 ... and, most importantly, I won't mix the batches together. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_F0DCC195E98348249FF39AE36B80A4D3ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


On Mar 30, 2016, at 12:00 PM, Robert Sparks <rjsparks@nostrum.com> wrote:



On 3/30/16 9:53 AM, Adam Roach wrote:
[as individual]

On 3/29/16 13:19, Dale R. Worley wrote:
As far as I can tell, the goal of this section is to make it=
 clear that
if SRV records translate a SIP domain into (e.g.) two SRV records with
different priorities, and one SRV record's target name only has IPv4
addresses and the other SRV record's target name only has IPv6
addresses, then which family of addresses is attempted first is to be
determined by priorities of the SRV records.  This being the process
described in section 4.2 of this draft.

I think it's somewhat more general than that, though. if you look up an SRV= record and get multiple A and multiple AAAA records, and those records in = turn contain multiple literal IP addresses, then you apply the SRV prioriti= es first and the RFC 6724 processes second.
Nit pick - Your sentence above starts "if you look up an SRV record&qu= ot;  (that is _one_ SRV record).
There are no SRV priorities to apply (beyond the trivial "take the one= I have").

Your example below of showing prioritizing multiple SRV records first using= the SRV prioritization rules,
then applying the 6724 rules only when looking at a set of A/AAAA for a sin= gle SRV record makes sense.

I agree and urging it might be tremendously useful to use such an example i= n the draft to unambiguously drive the point home.

-G


I think an example might help.

Let's say I look up an SRV record (_sip._tcp.example.com) and get back two entries:

_sip._tcp.example.com.  300 IN&= nbsp; SRV  10 1 5060 sip-1.example.com.
_sip._tcp.example.com.  300 IN&= nbsp; SRV  20 1 5060 sip-2.example.com.


So then I grab the A and AAAA records for sip-1.example.com and sip-2.example.com:

sip-1.example.com.  &nbs= p; 300  IN  AAAA  2001:0db8:58:c02::face
sip-1.example.com.  &nbs= p; 300  IN  AAAA  2001:0db8:c:a06::2:cafe
sip-1.example.com.  &nbs= p; 300  IN  AAAA  2001:0db8:44:204::d1ce

sip-1.example.com.  &nbs= p; 1800  IN  A  192.0.2.45
sip-1.example.com.  &nbs= p; 1800  IN  A  203.0.113.109
sip-1.example.com.  &nbs= p; 1800  IN  A  198.51.100.24

sip-2.example.com.  &nbs= p; 300  IN  AAAA  2001:0db8:58:c02::dead
sip-2.example.com.  &nbs= p; 300  IN  AAAA  2001:0db8:c:a06::2:beef
sip-2.example.com.  &nbs= p; 300  IN  AAAA  2001:0db8:44:204::c0de

sip-2.example.com.  &nbs= p; 1800  IN  A  192.0.2.75
sip-2.example.com.  &nbs= p; 1800  IN  A  203.0.113.38
sip-2.example.com.  &nbs= p; 1800  IN  A  198.51.100.140


What I believe we're saying is that I will process these addresses in a bat= ch, altogether, using RFC6724 section 6 rules:
  • 2001:0db8:58:c02::face
  • 2001:0db8:c:a06::2:cafe
  • 2001:0= db8:44:204::d1ce
  • 192.0.2.45
  • 203.0.113.109
  • 198.51= .100.24

And then (but only then, after I've exhausted that entire batch of addresse= s), I'll process these addresses in a batch, altogether, using RFC6724 sect= ion 6 rules:
  • 2001:0db8:58:c02::dead
  • 2001:0db8:c:a06::2:beef
  • 2001:0= db8:44:204::c0de
  • 192.0.2.75
  • 203.0.113.38
  • 198.51.= 100.140

... and, most importantly, I won't mix the batches together.

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_F0DCC195E98348249FF39AE36B80A4D3ciscocom_-- From nobody Wed Mar 30 10:48:00 2016 Return-Path: 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 7055112D835 for ; Wed, 30 Mar 2016 10:47:59 -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 x22yEiE_qiFG for ; Wed, 30 Mar 2016 10:47:58 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BCD12D826 for ; Wed, 30 Mar 2016 10:47:57 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by comcast with SMTP id lKCNaoZYBpUrhlKDlauSd9; Wed, 30 Mar 2016 17:47:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459360077; bh=TL2TM+wXHzSS4KAZaT9se5EP7faGuRU0mtmKKQuNHAk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=G735mY8jTlDzpYNLvMzfvs9c7SzElD7aljI5X0ZPCMO5AfLoJ3pLR5tm/Ao8H8mK5 Pvpb1V76e19UlaJFR5muZvxTf9b1MvPc1gZwZsjKV8CEHwo1/UDxHDW7tBWb+xmNDz ZWCGWU20mety04ZPrtrSAID22jNPoihRZAcJHYwAXwSeaizw6kYfodoEbIY4pfAcwQ a7Q0K5KcF/LwBFSrjSDxKY8OYk714hUlHmU0Rr7fRVigUrJFnadBJ5VIWpcLqt//T4 VZqUDQuPi9pz95adBUCNmwe0D9F+L0cHhSjaNbq6tSdK+oJO+ru/6LsCgardbtV8WL spl8hqbx9l1eA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-09v.sys.comcast.net with comcast id cHnw1s0091nMCLR01Hnwe6; Wed, 30 Mar 2016 17:47:57 +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 u2UHltfm019155; Wed, 30 Mar 2016 13:47:55 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2UHlslU019148; Wed, 30 Mar 2016 13:47:54 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 30 Mar 2016 13:47:54 -0400 Message-ID: <87zitfsvqt.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org, gsalguei@cisco.com, roman@telurix.com Subject: Re: [sipcore] Outline of a SIP-DTLS document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 17:47:59 -0000 It looks like we have enough interest for it to be worthwhile. I can't work on this for a couple of weeks because the dual-stack work needs to get done but after that we can get a draft started. Thanks, Dale From nobody Wed Mar 30 13:02:53 2016 Return-Path: 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 D0A5912D54F for ; Wed, 30 Mar 2016 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 aCGrpL-O1QGh for ; Wed, 30 Mar 2016 13:02:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18E212D110 for ; Wed, 30 Mar 2016 13:02:50 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UK2nWm080355 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 30 Mar 2016 15:02:50 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: SIPCORE Date: Wed, 30 Mar 2016 15:02:49 -0500 Message-ID: <931D2276-870E-46E4-AB09-255DBF12CD87@nostrum.com> References: <20160329155009.02198180004@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [sipcore] Fwd: [Technical Errata Reported] RFC5360 (4650) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 20:02:53 -0000 What do people think of this errata report? Thanks! Ben. Forwarded message: > From: RFC Errata System > To: jdrosen@cisco.com, Gonzalo.Camarillo@ericsson.com, > dean.willis@softarmor.com, ben@nostrum.com, alissa@cooperw.in, > dean.willis@softarmor.com, drage@alcatel-lucent.com > Cc: brett@broadsoft.com, rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5360 (4650) > Date: Tue, 29 Mar 2016 08:50:09 -0700 (PDT) > > The following errata report has been submitted for RFC5360, > "A Framework for Consent-Based Communications in the Session > Initiation Protocol (SIP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5360&eid=4650 > > -------------------------------------- > Type: Technical > Reported by: Brett Tate > > Section: 5.9.3 > > Original Text > ------------- > The following is an example of a Permission-Missing header field: > > Corrected Text > -------------- > If the URI contains a comma, question mark or semicolon, the > URI MUST be enclosed in angle brackets (< and >). > > The following is an example of a Permission-Missing header field: > > Notes > ----- > Comma and semicolon can cause decode ambiguities when the header > contains addr-spec values instead of name-addr values. For > consistency with RFC 3261 section 20, the same bracket rule is > indicated to resolve the ambiguity. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5360 (draft-ietf-sip-consent-framework-04) > -------------------------------------- > Title : A Framework for Consent-Based Communications in > the Session Initiation Protocol (SIP) > Publication Date : October 2008 > Author(s) : J. Rosenberg, G. Camarillo, Ed., D. Willis > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > From nobody Wed Mar 30 13:04:36 2016 Return-Path: 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 2529612D54F for ; Wed, 30 Mar 2016 13:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 lyIPp5OgwCzT for ; Wed, 30 Mar 2016 13:04:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5E212D110 for ; Wed, 30 Mar 2016 13:04:32 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UK4HPY080442 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Mar 2016 15:04:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Gonzalo Camarillo" , SIPCORE Date: Wed, 30 Mar 2016 15:04:17 -0500 Message-ID: In-Reply-To: <56FC0AB6.7000208@ericsson.com> References: <20160329155009.02198180004@rfc-editor.org> <56FBFA47.2050309@ericsson.com> <56FC0AB6.7000208@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: jdrosen@cisco.com, Keith Drage , alissa@cooperw.in, Dean Willis , RFC Errata System Subject: Re: [sipcore] [Technical Errata Reported] RFC5360 (4650) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 20:04:36 -0000 Please include the sipcore list (copied) for this discussion. Thanks! Ben. On 30 Mar 2016, at 12:19, Gonzalo Camarillo wrote: > Hi, > > I like more the name-addr text but can live with the other alternative > as well. I will let it to the ADs to decide how to resolve all these > errata. > > Cheers, > > Gonzalo > > On 30/03/2016 8:17 PM, Brett Tate wrote: >> Hi, >> >> The errata currently reflects a sentence from RFC 3261 section 20 >> which >> means the same thing as the other RFC 3261 snippet. >> >> Since the mandates are equivalent, duplicating either sentence is >> okay with >> me. >> >> If it matters, the related RFC 3325 errata from 2013 is based upon >> the RFC >> 3261 section 20 sentence. I've recently opened similar errata for >> RFC 3515, >> RFC 5002, RFC 5318, RFC 5360, and RFC 5502. >> >> Thanks, >> Brett >> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>> Sent: Wednesday, March 30, 2016 12:10 PM >>> To: Dean Willis; RFC Errata System >>> Cc: Keith Drage; brett@broadsoft.com; alissa@cooperw.in; >>> ben@nostrum.com; >>> jdrosen@cisco.com >>> Subject: Re: [Technical Errata Reported] RFC5360 (4650) >>> >>> Hi, >>> >>> yes, in RFC 3261 the following text is used instead: >>> >>>> Even if the "display- >>>> name" is empty, the "name-addr" form MUST be used if the >>>> "addr-spec" >>>> contains a comma, question mark, or semicolon. >>> >>> So, instead of talking about angle brackets, we probably want to >>> talk >>> about >>> the "name-addr" form being used in those cases. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 29/03/2016 8:51 PM, Dean Willis wrote: >>>> Seems reasonable to me. >>>> >>>> On Mar 29, 2016 10:50 AM, "RFC Errata System" >>>> > >>>> wrote: >>>> >>>> The following errata report has been submitted for RFC5360, >>>> "A Framework for Consent-Based Communications in the Session >>>> Initiation Protocol (SIP)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5360&eid=4650 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Brett Tate >>> > >>>> >>>> Section: 5.9.3 >>>> >>>> Original Text >>>> ------------- >>>> The following is an example of a Permission-Missing header >>>> field: >>>> >>>> Corrected Text >>>> -------------- >>>> If the URI contains a comma, question mark or semicolon, the >>>> URI MUST be enclosed in angle brackets (< and >). >>>> >>>> The following is an example of a Permission-Missing header >>>> field: >>>> >>>> Notes >>>> ----- >>>> Comma and semicolon can cause decode ambiguities when the >>>> header >>>> contains addr-spec values instead of name-addr values. For >>>> consistency with RFC 3261 section 20, the same bracket rule is >>>> indicated to resolve the ambiguity. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, >>>> please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> (IESG) >>>> can log in to change the status and edit the report, if >>>> necessary. >>>> >>>> -------------------------------------- >>>> RFC5360 (draft-ietf-sip-consent-framework-04) >>>> -------------------------------------- >>>> Title : A Framework for Consent-Based >>>> Communications >>>> in the Session Initiation Protocol (SIP) >>>> Publication Date : October 2008 >>>> Author(s) : J. Rosenberg, G. Camarillo, Ed., D. >>>> Willis >>>> Category : PROPOSED STANDARD >>>> Source : Session Initiation Protocol >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >>>> From nobody Wed Mar 30 13:05:39 2016 Return-Path: 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 3E1C512D8FF for ; Wed, 30 Mar 2016 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 H1kXdV5EDKRh for ; Wed, 30 Mar 2016 13:05:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3EE12D91D for ; Wed, 30 Mar 2016 13:05:35 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UK5QkX080529 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Mar 2016 15:05:27 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: SIPCORE Date: Wed, 30 Mar 2016 15:05:26 -0500 Message-ID: In-Reply-To: <0fe26c2758e2dde58b55d07c41711d80@mail.gmail.com> References: <20160330170846.981D918000C@rfc-editor.org> <0fe26c2758e2dde58b55d07c41711d80@mail.gmail.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: rsparks@dynamicsoft.com, alissa@cooperw.in, drage@alcatel-lucent.com, dean.willis@softarmor.com, RFC Errata System Subject: Re: [sipcore] [Technical Errata Reported] RFC3515 (4652) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 20:05:38 -0000 (copying sipcore) On 30 Mar 2016, at 12:12, Brett Tate wrote: > Hi, > > My proposed resolution is similar to what occurred within RFC 3325 errata > (3744 and 3894). > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Wednesday, March 30, 2016 1:09 PM >> To: rsparks@dynamicsoft.com; ben@nostrum.com; alissa@cooperw.in; >> dean.willis@softarmor.com; drage@alcatel-lucent.com >> Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC3515 (4652) >> >> The following errata report has been submitted for RFC3515, "The Session >> Initiation Protocol (SIP) Refer Method". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4652 >> >> -------------------------------------- >> Type: Technical >> Reported by: Brett Tate >> >> Section: 2.1 >> >> Original Text >> ------------- >> The Refer-To header field MAY be encrypted as part of end-to-end > encryption. >> >> Corrected Text >> -------------- >> If the URI contains a comma, question mark or semicolon, the URI MUST be >> enclosed in angle brackets (< and >). >> >> The Refer-To header field MAY be encrypted as part of end-to-end > encryption. >> >> Notes >> ----- >> If addr-spec is used when there are parameters, it is ambiguous if the >> parameters are URI parameters or header parameters. For consistency > with RFC >> 3261 section 20, the same bracket rule is indicated even if comma and >> question mark do not cause an issue. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please use >> "Reply All" to discuss whether it should be verified or rejected. When a >> decision is reached, the verifying party (IESG) can log in to change the >> status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3515 (draft-ietf-sip-refer-07) >> -------------------------------------- >> Title : The Session Initiation Protocol (SIP) Refer Method >> Publication Date : April 2003 >> Author(s) : R. Sparks >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG From nobody Wed Mar 30 13:06:13 2016 Return-Path: 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 7471512D92B; Wed, 30 Mar 2016 13:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 Vs4B1FC1diTn; Wed, 30 Mar 2016 13:06:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7B012D925; Wed, 30 Mar 2016 13:06:08 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UK639n080653 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Mar 2016 15:06:03 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Gonzalo Camarillo" , SIPCORE Date: Wed, 30 Mar 2016 15:06:02 -0500 Message-ID: In-Reply-To: <56FBFAD5.1090806@ericsson.com> References: <20160329160146.E71EB180004@rfc-editor.org> <56FBFAD5.1090806@ericsson.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Jani.Hautakorpi@ericsson.com, RFC Errata System , iesg@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC5318 (4651) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 20:06:10 -0000 (copying sipcore) On 30 Mar 2016, at 11:12, Gonzalo Camarillo wrote: > Hi Brett, > > I have the same comment as on the other document. I would talk about the > name-addr form instead. Let's agree on the text we want to use for the > three documents, since it is the same issue. > > Cheers, > > Gonzalo > > On 29/03/2016 7:06 PM, Brett Tate wrote: >> Hi, >> >> My proposed resolution is similar to what occurred within RFC 3325 errata >> (3744 and 3894). >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: Tuesday, March 29, 2016 12:02 PM >>> To: Jani.Hautakorpi@ericsson.com; Gonzalo.Camarillo@ericsson.com; >>> iesg@ietf.org >>> Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC5318 (4651) >>> >>> The following errata report has been submitted for RFC5318, "The Session >>> Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5318&eid=4651 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Brett Tate >>> >>> Section: 5 >>> >>> Original Text >>> ------------- >>> The members P-Header parameter MUST contain a cid-url, which is defined >> in >>> RFC 2392 [2]. >>> >>> Corrected Text >>> -------------- >>> The members P-Header parameter MUST contain a cid-url, which is defined >> in >>> RFC 2392 [2]. >>> >>> If the URI contains a comma, question mark or semicolon, the URI MUST be >>> enclosed in angle brackets (< and >). >>> >>> Notes >>> ----- >>> Comma and semicolon can cause decode ambiguities when the header >> contains >>> addr-spec values instead of name-addr values. For consistency with RFC >> 3261 >>> section 20, the same bracket rule is indicated to resolve the ambiguity. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please use >>> "Reply All" to discuss whether it should be verified or rejected. When a >>> decision is reached, the verifying party (IESG) can log in to change the >>> status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5318 (draft-hautakorpi-sipping-uri-list-handling-refused-03) >>> -------------------------------------- >>> Title : The Session Initiation Protocol (SIP) >> P-Refused-URI- >>> List Private-Header (P-Header) >>> Publication Date : December 2008 >>> Author(s) : J. Hautakorpi, G. Camarillo >>> Category : INFORMATIONAL >>> Source : IETF - NON WORKING GROUP >>> Area : N/A >>> Stream : IETF >>> Verifying Party : IESG From nobody Wed Mar 30 14:40:08 2016 Return-Path: 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 3A1CB12D861 for ; Wed, 30 Mar 2016 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 aQYpZ8Eu8xGm for ; Wed, 30 Mar 2016 14:40:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5866A12D513 for ; Wed, 30 Mar 2016 14:40:04 -0700 (PDT) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2ULe1um090081 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 30 Mar 2016 16:40:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: sipcore@ietf.org References: <20160329160146.E71EB180004@rfc-editor.org> <56FBFAD5.1090806@ericsson.com> From: Robert Sparks Message-ID: <56FC47B1.3090901@nostrum.com> Date: Wed, 30 Mar 2016 16:40:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ben Campbell Subject: [sipcore] name-addr vs addr-spec requirements (was Re: [Technical Errata Reported] RFC5318 (4651)) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 21:40:06 -0000 This cluster of errata (4650, 4651, 4652) are on the wrong edge of making a technical change from my perspective. It's a good technical change to make, and it _should_ have been stated as such in the documents the errata are filed against, but it is still a technical change. I would prefer the work to clarify the documents be done with a draft that goes through IETF LC rather than use errata. That draft could solve the problem this cluster points to much more generally, updating 3261 to require that _anywhere_ name-addr/addr-spec are used as alternates, name-addr MUST be used if comma, question mark, or semicolon appear. The text could leave an "unless explicitly specified otherwise" out. That draft could have a section capturing the places where we failed to say that so far, and update the relevant RFCs (the ones these errata point to) as well. RjS On 3/30/16 3:06 PM, Ben Campbell wrote: > (copying sipcore) > > On 30 Mar 2016, at 11:12, Gonzalo Camarillo wrote: > >> Hi Brett, >> >> I have the same comment as on the other document. I would talk about the >> name-addr form instead. Let's agree on the text we want to use for the >> three documents, since it is the same issue. >> >> Cheers, >> >> Gonzalo >> >> On 29/03/2016 7:06 PM, Brett Tate wrote: >>> Hi, >>> >>> My proposed resolution is similar to what occurred within RFC 3325 errata >>> (3744 and 3894). >>> >>>> -----Original Message----- >>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>> Sent: Tuesday, March 29, 2016 12:02 PM >>>> To: Jani.Hautakorpi@ericsson.com; Gonzalo.Camarillo@ericsson.com; >>>> iesg@ietf.org >>>> Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org >>>> Subject: [Technical Errata Reported] RFC5318 (4651) >>>> >>>> The following errata report has been submitted for RFC5318, "The Session >>>> Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5318&eid=4651 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Brett Tate >>>> >>>> Section: 5 >>>> >>>> Original Text >>>> ------------- >>>> The members P-Header parameter MUST contain a cid-url, which is defined >>> in >>>> RFC 2392 [2]. >>>> >>>> Corrected Text >>>> -------------- >>>> The members P-Header parameter MUST contain a cid-url, which is defined >>> in >>>> RFC 2392 [2]. >>>> >>>> If the URI contains a comma, question mark or semicolon, the URI MUST be >>>> enclosed in angle brackets (< and >). >>>> >>>> Notes >>>> ----- >>>> Comma and semicolon can cause decode ambiguities when the header >>> contains >>>> addr-spec values instead of name-addr values. For consistency with RFC >>> 3261 >>>> section 20, the same bracket rule is indicated to resolve the ambiguity. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, please use >>>> "Reply All" to discuss whether it should be verified or rejected. When a >>>> decision is reached, the verifying party (IESG) can log in to change the >>>> status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC5318 (draft-hautakorpi-sipping-uri-list-handling-refused-03) >>>> -------------------------------------- >>>> Title : The Session Initiation Protocol (SIP) >>> P-Refused-URI- >>>> List Private-Header (P-Header) >>>> Publication Date : December 2008 >>>> Author(s) : J. Hautakorpi, G. Camarillo >>>> Category : INFORMATIONAL >>>> Source : IETF - NON WORKING GROUP >>>> Area : N/A >>>> Stream : IETF >>>> Verifying Party : IESG > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Mar 31 04:35:54 2016 Return-Path: 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 CC4A212D5D3 for ; Thu, 31 Mar 2016 04:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 GtzaV1Z9C5bd for ; Thu, 31 Mar 2016 04:35:50 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE82812D5D1 for ; Thu, 31 Mar 2016 04:35:48 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q128so108294309iof.3 for ; Thu, 31 Mar 2016 04:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=uTtObuKvTAc9eMdrulZzyTcWjSz95tht3RjITbXNhLc=; b=P8jHGVwspsGKtw+jHgsQPW5FwmQnksOR/k739nqCwli2vQzQ/DNzw78QgI2Qlafeyo BsFFYWH5X4hfsVEkhcBcSeQJ+0UUkYPFmW2d8Rcu/ULXdWLLTN3OIlhv2l2CoFx+Qy14 /PgV9FrSCVXqFaTqI3oT0R964pNty1I59aMrK9Ac53VNmRd5rhUVdfULqMML1wMKoQbx GrYnpKx34e4FfCdE0bWjRYQFkVg6VbV/u7xjcATg9YRsLo3WqP3VCD7J4bbWnABf7bWG VOljWBhFHqqp8skfeeM4O/1+Fb67nILohw1bUlt5mBck8nQx4/v1jpM9QRKp5JpnwljF eEjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=uTtObuKvTAc9eMdrulZzyTcWjSz95tht3RjITbXNhLc=; b=P6AxKOA5jrrOy17mT9CXM2ID2JMnZnQKz/V5o9NYuAJsXjZtKXb+BH1S+2FztWTIt8 zxoToh5Skb1zHCcqGIEBTyEbeCyaS2GLp3rMocIgAZEObzCHEUFN4gQinz+rdIW0WN// p6bPeBW3+QJH6L55YUZ0pxt3uobuWquXWGp8+YQJ2WwvFQFqfqhEp2PY+UXUteKKEBO9 boQPIpyGI3GAPLveiUm8rU+makm7XzhCjRioXDVfqf4tduXjuIZuzW1RvsEXmoctiV/j HWL0UbOyzje5Y53giZiybSnBMgl2sNwtPNo4ctQqIOdZvHY5iKzCxBDXOZmTlBYhjadk uOxA== X-Gm-Message-State: AD7BkJKC4WDYMeM6pjCYcaXOv3Zc54uLehO+5IRbuaCqFcdZHRjw2eEPNQ2N/GZNjQok+iNTwTiQKuIHSBz7+GFQ X-Received: by 10.107.2.69 with SMTP id 66mr5339974ioc.8.1459424148029; Thu, 31 Mar 2016 04:35:48 -0700 (PDT) From: Brett Tate References: <20160329145448.53405180004@rfc-editor.org> 5ee96ec3f7f636b401ca1132aabf95c3@mail.gmail.com In-Reply-To: 5ee96ec3f7f636b401ca1132aabf95c3@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLWkLUImq/GIANv3gUjVXOWVpZox51mdRlAgALrvkA= Date: Thu, 31 Mar 2016 07:35:47 -0400 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: German.Blanco@ericsson.com, iesg@ietf.org, Gonzalo.Camarillo@ericsson.com, RFC Errata System Subject: Re: [sipcore] [Technical Errata Reported] RFC5002 (4649) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 11:35:51 -0000 Copying sipcore since similar errata being discussed. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, March 29, 2016 10:59 AM > To: 'RFC Errata System'; 'Gonzalo.Camarillo@ericsson.com'; > 'German.Blanco@ericsson.com'; 'iesg@ietf.org' > Subject: RE: [Technical Errata Reported] RFC5002 (4649) > > Hi, > > My proposed resolution is similar to what occurred within RFC 3325 errata > (3744 and 3894). > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, March 29, 2016 10:55 AM > > To: Gonzalo.Camarillo@ericsson.com; German.Blanco@ericsson.com; > > iesg@ietf.org > > Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC5002 (4649) > > > > The following errata report has been submitted for RFC5002, "The > > Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5002&eid=4649 > > > > -------------------------------------- > > Type: Technical > > Reported by: Brett Tate > > > > Section: 5 > > > > Original Text > > ------------- > > The following is an example of a P-Profile-Key header field that > > contains a Wildcarded Public Service Identity: > > > > Corrected Text > > -------------- > > If the URI contains a comma, question mark or semicolon, the URI MUST > > be enclosed in angle brackets (< and >). > > > > The following is an example of a P-Profile-Key header field that > > contains a Wildcarded Public Service Identity: > > > > Notes > > ----- > > If addr-spec is used when there are parameters, it is ambiguous if the > > parameters are URI parameters or header parameters. For consistency > > with RFC > > 3261 section 20, the same bracket rule is indicated even if comma and > > question mark do not cause an issue. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5002 (draft-camarillo-sipping-profile-key-02) > > -------------------------------------- > > Title : The Session Initiation Protocol (SIP) P-Profile-Key > > Private Header (P-Header) > > Publication Date : August 2007 > > Author(s) : G. Camarillo, G. Blanco > > Category : INFORMATIONAL > > Source : IETF - NON WORKING GROUP > > Area : N/A > > Stream : IETF > > Verifying Party : IESG From nobody Thu Mar 31 04:36:52 2016 Return-Path: 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 60BA112D5D0 for ; Thu, 31 Mar 2016 04:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 gE05n5I5M6pU for ; Thu, 31 Mar 2016 04:36:48 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2E712D5AA for ; Thu, 31 Mar 2016 04:36:47 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id ui10so55872869igc.1 for ; Thu, 31 Mar 2016 04:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=LKVCp4NeAHZ+OstUIo5mhyhZdyMu6RnYiY3aw1ahV58=; b=Bmz5Gu69iJTnn0EhhJY8r6B1OAQFupqx5G5L6scuaCJ989HHrM7O3H3gTgemCg4ZCw q/dYs+XVKMsN+uk21u/QbQr6CuYCQ5uvOL9hvyBpOgjKTNF4jvNVywm6XnkEpvJz4Cvz LABr4Fj0z7d764ls017hTZQHdN4OmJQ2NYYxf84xmaCygetHE5sCTnEMzpESxDY4y+A+ uKBTB2NpcRjn8aaWtNBTmj1Z3WoJ9M8wBIdJ97OtyLzU0M819d7exhHE2ui1JWAA8IQb KnTndHyEitG1XgabST6XUJmcjOez7gMK7D07dh34idQQ1xyos4M04eDNOkqtA23y4Ry8 JnOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=LKVCp4NeAHZ+OstUIo5mhyhZdyMu6RnYiY3aw1ahV58=; b=KWxn1pTaESmH0qqV0vdgrcB7xjXCS0wZgqwg3cV54hG3OQvyPTPPCLmxrmDATCBGma 4+FHKcP8cZR5jkdPRMTKBe54qtiAba2X1B4oQg73YBEqXP0za4C0u+boCQqHiehVgpjf uMIZmthZuvC/jMFmjzaB29hftRR6QkdYoTK6j59g4MyheM1yfLGHkCiSkTbIVftwDkEq rKIiWdwj3yadzvcu7RyorFNxGKHtGFg8WpmZucWNMnZVQwon/A3tBjfpL0tvqoQLl42M omZzA6VJrs+V4e6JP1vvFhYnsRbeuDjnXdzq982E6iHqs/e8bFaHFQrFcSbU5Laa9c2Z KN/w== X-Gm-Message-State: AD7BkJJ1K9gvmffbrryuk+k8eXK6+EFaxV0Z2V4ym8n+L//a+sVqFwOnCZdvvhaPTYvLFs7RwNYuKLqgKUaZqayY X-Received: by 10.50.111.8 with SMTP id ie8mr2530006igb.46.1459424206584; Thu, 31 Mar 2016 04:36:46 -0700 (PDT) From: Brett Tate References: <20160329135428.51F55180004@rfc-editor.org> fe4e28b6108e92c8e3b3b87633ae803e@mail.gmail.com In-Reply-To: fe4e28b6108e92c8e3b3b87633ae803e@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIs2UBGDB8Ij4av+iZyog60lg6Fcp651mcwgAL6I4A= Date: Thu, 31 Mar 2016 07:36:46 -0400 Message-ID: <8ebfaf07d50da3c1dafb4083e5d2862b@mail.gmail.com> To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HansErik.van.Elburg@ericsson.com, iesg@ietf.org, RFC Errata System Subject: Re: [sipcore] [Technical Errata Reported] RFC5502 (4648) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 11:36:50 -0000 Copying sipcore since similar errata being discussed. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, March 29, 2016 10:23 AM > To: 'RFC Errata System'; 'HansErik.van.Elburg@ericsson.com'; 'iesg@ietf.org' > Subject: RE: [Technical Errata Reported] RFC5502 (4648) > > Hi, > > My proposed resolution is similar to what occurred within RFC 3325 errata > (3744 and 3894). > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, March 29, 2016 9:54 AM > > To: HansErik.van.Elburg@ericsson.com; iesg@ietf.org > > Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC5502 (4648) > > > > The following errata report has been submitted for RFC5502, "The SIP > > P- Served-User Private-Header (P-Header) for the 3GPP IP Multimedia > > (IM) Core Network (CN) Subsystem". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5502&eid=4648 > > > > -------------------------------------- > > Type: Technical > > Reported by: Brett Tate > > > > Section: 6 > > > > Original Text > > ------------- > > EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are > > defined in RFC 3261 [2]. > > > > > > Corrected Text > > -------------- > > EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are > > defined in RFC 3261 [2]. > > > > If the URI contains a comma, question mark or semicolon, the URI MUST > > be enclosed in angle brackets (< and >). > > > > Notes > > ----- > > If addr-spec is used when there are parameters, it is ambiguous if the > > parameters are URI parameters or served-user-param. For consistency > > with RFC > > 3261 section 20, the same bracket rule is indicated even if comma and > > question mark do not cause an issue. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5502 (draft-vanelburg-sipping-served-user-08) > > -------------------------------------- > > Title : The SIP P-Served-User Private-Header (P-Header) for > the > > 3GPP IP Multimedia (IM) Core Network (CN) Subsystem > > Publication Date : April 2009 > > Author(s) : J. van Elburg > > Category : INFORMATIONAL > > Source : IETF - NON WORKING GROUP > > Area : N/A > > Stream : IETF > > Verifying Party : IESG From nobody Thu Mar 31 07:07:37 2016 Return-Path: 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 8630C12D102 for ; Thu, 31 Mar 2016 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ofsnWKIT0ksZ for ; Thu, 31 Mar 2016 07:07:32 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CD412D100 for ; Thu, 31 Mar 2016 07:07:31 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by comcast with SMTP id ldF7aTRmebFYYldFyaalPe; Thu, 31 Mar 2016 14:07:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459433250; bh=EestvSY/l+zObw9sHdFFdfwEiA0dPzj0Xvf7sNqvMhg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Hok9HGG0h6hU5wOrbC2Rf/Z2lLZrRUtkYXt5+b06ook8vmW+ICxNSaPLBT1e98IC7 jdvhjT8JWFADdxPTcRJH23D9aE5k7pwNo3ju74+JTL/IKtHzQAiiE7J+fB0JjX4rAw M2ixzX2PbgFvyc0R38psRNkAeqa0+PJ+u8zgAxJDQO/1XDDErkcL2c9MLJBWSETvnC no1jP9inyErZhqIy9lUTOQvZ59eFljeAfsS7JuybotHWoHFlBnSsj3sVOZXY/8mbjD 8VeAJwowzrAVoPkD85fmaGggnpb4nKTKupgsbFAlGDmiyfOGhuLfpjslG8q0Ezhi3I RNwmQ6LyHqt9w== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id ce7W1s00G3KdFy101e7WmZ; Thu, 31 Mar 2016 14:07:30 +0000 To: sipcore@ietf.org References: <20160329135428.51F55180004@rfc-editor.org> <8ebfaf07d50da3c1dafb4083e5d2862b@mail.gmail.com> From: Paul Kyzivat Message-ID: <56FD2F21.2070609@alum.mit.edu> Date: Thu, 31 Mar 2016 10:07:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <8ebfaf07d50da3c1dafb4083e5d2862b@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:07:35 -0000 ISTM that it would be good to discuss all of these together, and perhaps solicit pointers to any others that need a similar fix. Thanks, Paul On 3/31/16 7:36 AM, Brett Tate wrote: > Copying sipcore since similar errata being discussed. > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: Tuesday, March 29, 2016 10:23 AM >> To: 'RFC Errata System'; 'HansErik.van.Elburg@ericsson.com'; > 'iesg@ietf.org' >> Subject: RE: [Technical Errata Reported] RFC5502 (4648) >> >> Hi, >> >> My proposed resolution is similar to what occurred within RFC 3325 > errata >> (3744 and 3894). >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: Tuesday, March 29, 2016 9:54 AM >>> To: HansErik.van.Elburg@ericsson.com; iesg@ietf.org >>> Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC5502 (4648) >>> >>> The following errata report has been submitted for RFC5502, "The SIP >>> P- Served-User Private-Header (P-Header) for the 3GPP IP Multimedia >>> (IM) Core Network (CN) Subsystem". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5502&eid=4648 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Brett Tate >>> >>> Section: 6 >>> >>> Original Text >>> ------------- >>> EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are >>> defined in RFC 3261 [2]. >>> >>> >>> Corrected Text >>> -------------- >>> EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are >>> defined in RFC 3261 [2]. >>> >>> If the URI contains a comma, question mark or semicolon, the URI MUST >>> be enclosed in angle brackets (< and >). >>> >>> Notes >>> ----- >>> If addr-spec is used when there are parameters, it is ambiguous if the >>> parameters are URI parameters or served-user-param. For consistency >>> with RFC >>> 3261 section 20, the same bracket rule is indicated even if comma and >>> question mark do not cause an issue. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or rejected. >>> When a decision is reached, the verifying party (IESG) can log in to >>> change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5502 (draft-vanelburg-sipping-served-user-08) >>> -------------------------------------- >>> Title : The SIP P-Served-User Private-Header (P-Header) > for >> the >>> 3GPP IP Multimedia (IM) Core Network (CN) Subsystem >>> Publication Date : April 2009 >>> Author(s) : J. van Elburg >>> Category : INFORMATIONAL >>> Source : IETF - NON WORKING GROUP >>> Area : N/A >>> Stream : IETF >>> Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Mar 31 07:47:04 2016 Return-Path: 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 F1EC912D199 for ; Thu, 31 Mar 2016 07:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 k-t4csvzOfro for ; Thu, 31 Mar 2016 07:47:00 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F05812D153 for ; Thu, 31 Mar 2016 07:46:48 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id nk17so127933661igb.1 for ; Thu, 31 Mar 2016 07:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=YN34kksz5Rsb/ofgjyUJEwGPrwymq8On6lccuJyv2O0=; b=gU4W8I2ojFRM2XJp6AIKx57h+v/M5L7HgH9FoHouSWJFI9UaDgm7JD2fljk3eZRqGk PRduTZ1HwF3DhWWPTaXCl/Vqy5UsZxCf0KUwnrgwb2/rc3x+MM6s685ChwtzpfQd7qxi lPkI/YfQrG3wYIrQs/3t5D3yM2RKYKvDcEXviDZ74RM0z9hzf2RXZADGvdg7vq5IyerR mBI7hsWhmtWn2f9RObXycVP7Mx7PVEBZUzr3hH8QVpiOMYGL9Pkauci27+JUk3l5StkL ojJuLua94rds7rHJOoMjNhgLFFYO5qUyXMrpH/4i/Ztmf27vU7S9rmoQT0pB34u04uw5 vp/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=YN34kksz5Rsb/ofgjyUJEwGPrwymq8On6lccuJyv2O0=; b=FKJdFj7896nXgO6mURBqFWYFhvGwtnx6sKRj6hcuTmnFEVu/P2X+0eA6+zrY3roQNx j+InDTxhon2HmKjC0Nd2gzUTUOHe7gVKVcL5PrTBLrOI0s4cBfmfrHMVr3lH7R0zivAT lLV8gMXbA2hrlBrw6DEK28EcZVwjF2hAyq4CHBCKxh0zBjZ/2+qCJ5cZGVAIy/p3cCG6 SC9ueI/tApRz0PJqnm8gj+nFYt3wP3QRwJANoEXStm47h9d+8Ku+zsvcG2nVhakfJI0M FKQIbRYo1WUOlCS5gH0UZQbSVpKay5kclt2aQOQyPuFe0SONzwOXDjhL1H9ioJCZjiUN 9PUw== X-Gm-Message-State: AD7BkJLpigeVd/Spi+nVcTv1RjNXyTsmudWuU9D6ILGC66YiSGk+3FczUoxp3bhD96CUh4uReIApCBrLgEZLfgDS X-Received: by 10.50.61.232 with SMTP id t8mr3985630igr.83.1459435607380; Thu, 31 Mar 2016 07:46:47 -0700 (PDT) From: Brett Tate References: <20160329135428.51F55180004@rfc-editor.org> <8ebfaf07d50da3c1dafb4083e5d2862b@mail.gmail.com> <56FD2F21.2070609@alum.mit.edu> In-Reply-To: <56FD2F21.2070609@alum.mit.edu> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIs2UBGDB8Ij4av+iZyog60lg6FcgHIhIa7AmaiPsGem4JkwA== Date: Thu, 31 Mar 2016 10:46:46 -0400 Message-ID: To: Paul Kyzivat , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 14:47:03 -0000 Hi, I agree; that was why I sent the following email in October 2013 while sipcore was working on similar errata for RFC 3325. I used that email and aspects of the RFC 3325 errata to produce the recent errata for RFC 3515, RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any headers register with IANA since October 2013. http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html Thanks, Brett > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, March 31, 2016 10:07 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... > > ISTM that it would be good to discuss all of these together, and perhaps > solicit pointers to any others that need a similar fix. > > Thanks, > Paul > > On 3/31/16 7:36 AM, Brett Tate wrote: > > Copying sipcore since similar errata being discussed. > > > >> -----Original Message----- > >> From: Brett Tate [mailto:brett@broadsoft.com] > >> Sent: Tuesday, March 29, 2016 10:23 AM > >> To: 'RFC Errata System'; 'HansErik.van.Elburg@ericsson.com'; > > 'iesg@ietf.org' > >> Subject: RE: [Technical Errata Reported] RFC5502 (4648) > >> > >> Hi, > >> > >> My proposed resolution is similar to what occurred within RFC 3325 > > errata > >> (3744 and 3894). > >> > >>> -----Original Message----- > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>> Sent: Tuesday, March 29, 2016 9:54 AM > >>> To: HansErik.van.Elburg@ericsson.com; iesg@ietf.org > >>> Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org > >>> Subject: [Technical Errata Reported] RFC5502 (4648) > >>> > >>> The following errata report has been submitted for RFC5502, "The SIP > >>> P- Served-User Private-Header (P-Header) for the 3GPP IP Multimedia > >>> (IM) Core Network (CN) Subsystem". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> http://www.rfc-editor.org/errata_search.php?rfc=5502&eid=4648 > >>> > >>> -------------------------------------- > >>> Type: Technical > >>> Reported by: Brett Tate > >>> > >>> Section: 6 > >>> > >>> Original Text > >>> ------------- > >>> EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are > >>> defined in RFC 3261 [2]. > >>> > >>> > >>> Corrected Text > >>> -------------- > >>> EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are > >>> defined in RFC 3261 [2]. > >>> > >>> If the URI contains a comma, question mark or semicolon, the URI > >>> MUST be enclosed in angle brackets (< and >). > >>> > >>> Notes > >>> ----- > >>> If addr-spec is used when there are parameters, it is ambiguous if > >>> the parameters are URI parameters or served-user-param. For > >>> consistency with RFC > >>> 3261 section 20, the same bracket rule is indicated even if comma > >>> and question mark do not cause an issue. > >>> > >>> Instructions: > >>> ------------- > >>> This erratum is currently posted as "Reported". If necessary, please > >>> use "Reply All" to discuss whether it should be verified or rejected. > >>> When a decision is reached, the verifying party (IESG) can log in to > >>> change the status and edit the report, if necessary. > >>> > >>> -------------------------------------- > >>> RFC5502 (draft-vanelburg-sipping-served-user-08) > >>> -------------------------------------- > >>> Title : The SIP P-Served-User Private-Header (P-Header) > > for > >> the > >>> 3GPP IP Multimedia (IM) Core Network (CN) Subsystem > >>> Publication Date : April 2009 > >>> Author(s) : J. van Elburg > >>> Category : INFORMATIONAL > >>> Source : IETF - NON WORKING GROUP > >>> Area : N/A > >>> Stream : IETF > >>> Verifying Party : IESG > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Mar 31 14:48:33 2016 Return-Path: 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 D495412D882 for ; Thu, 31 Mar 2016 14:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6y2qNzsVT3gf for ; Thu, 31 Mar 2016 14:48:30 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4575A12D580 for ; Thu, 31 Mar 2016 14:48:30 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id lkRpa3CKKLCmUlkS5aqlTX; Thu, 31 Mar 2016 21:48:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459460909; bh=dfppx+bBArSXZm481udFRBuOhHDyVU7l3Mg3eejdsvw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Krm01oIfkTUmrCQaeFi/BQuIxY0/4kRR8rPSEdGYpeo8DKYGAvxNkykbM1VJi+bBN DJcgneAAvSNsSK+GSyBDjfH7iiXiwzhD6+nxU3Op3o2clpQMh6+1fKPRXCmilU4Nc/ LIzuUNEiKQyOdchzWjYew5IHmdIlfbP+8u6L51qjcIrJybEFPkXnRHVYtxpPGDNoPe 63emP6cfv4CbWHVApcnzGKFDn6nPg1F6KjGE/9XD3XVGmMRdvmPeiAPRYK/DqOXl3c esKxGC7OGJ71R/DCPBvdxe77DFXm+yrPdrl0fKaS+Ya5SYZCosm0EoXsdNfGJ0gLRY GSddkoef1SZdA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id cloU1s00E1nMCLR01loVpt; Thu, 31 Mar 2016 21:48:29 +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 u2VLmRC1013299; Thu, 31 Mar 2016 17:48:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2VLmRxY013295; Thu, 31 Mar 2016 17:48:27 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Brett Tate In-Reply-To: (brett@broadsoft.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 31 Mar 2016 17:48:27 -0400 Message-ID: <87pouaqpxw.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 21:48:31 -0000 Brett Tate writes: > I agree; that was why I sent the following email in October 2013 while > sipcore was working on similar errata for RFC 3325. I used that email and > aspects of the RFC 3325 errata to produce the recent errata for RFC 3515, > RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any headers > register with IANA since October 2013. > > http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html Why don't we put in an erratum that edits RFC 3261 section 20.10. The old text is: Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the "<". The new text adds: In any header field whose value syntax is (name-addr / addr-spec) *(SEMI generic-param) or (name-addr / addr-spec) *(SEMI generic-param) *(COMMA (name-addr / addr-spec) *(SEMI generic-param)) the "addr-spec" alternative may not be used if its value would contain a comma, semicolon, or question mark. In a sense, that's what everybody *thinks* RFC 3261 requires. Dale From nobody Thu Mar 31 15:09:00 2016 Return-Path: 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 8E1C812D1B0 for ; Thu, 31 Mar 2016 15:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 ir7RCHq_FPz8 for ; Thu, 31 Mar 2016 15:08:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD0E12D131 for ; Thu, 31 Mar 2016 15:08:56 -0700 (PDT) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2VM8urT061258 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 31 Mar 2016 17:08:56 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: sipcore@ietf.org References: <87pouaqpxw.fsf@hobgoblin.ariadne.com> From: Robert Sparks Message-ID: <56FD9FF7.7020207@nostrum.com> Date: Thu, 31 Mar 2016 17:08:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <87pouaqpxw.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFCs 3515, 5502, 5360, ... X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 22:08:58 -0000 Again, I don't think errata is the right way to skin this. RjS On 3/31/16 4:48 PM, Dale R. Worley wrote: > Brett Tate writes: >> I agree; that was why I sent the following email in October 2013 while >> sipcore was working on similar errata for RFC 3325. I used that email and >> aspects of the RFC 3325 errata to produce the recent errata for RFC 3515, >> RFC 5002, RFC 5318, RFC 5360, and RFC 5502. I have not check any headers >> register with IANA since October 2013. >> >> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html > Why don't we put in an erratum that edits RFC 3261 section 20.10. The > old text is: > > Even if the "display-name" is empty, the "name-addr" form MUST be > used if the "addr-spec" contains a comma, semicolon, or question > mark. There may or may not be LWS between the display-name and the > "<". > > The new text adds: > > In any header field whose value syntax is > (name-addr / addr-spec) *(SEMI generic-param) > or > (name-addr / addr-spec) *(SEMI generic-param) > *(COMMA (name-addr / addr-spec) *(SEMI generic-param)) > the "addr-spec" alternative may not be used if its value would > contain a comma, semicolon, or question mark. > > In a sense, that's what everybody *thinks* RFC 3261 requires. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore