From nobody Thu May 14 10:04:06 2015 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 248BA1A8AA9 for ; Thu, 14 May 2015 10:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 gYUZyQXoWZJx for ; Thu, 14 May 2015 10:04:03 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (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 384361A87C7 for ; Thu, 14 May 2015 10:04:03 -0700 (PDT) Received: by qcyk17 with SMTP id k17so43095409qcy.1 for ; Thu, 14 May 2015 10:04:02 -0700 (PDT) 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:content-type; bh=dctJcFRkE0JJBMF359CQxbx6InbBqvcIT9nR68GvUEo=; b=ITX56Enen4zJZvQa/I4EcGPQgOkaGzf6EguspT0gtpasXu2IKTIXq1ELk+EYBRPYNS cvV52dZe16Sf6vg+12rhmK4cGb0r4v8LqA9j/3uQrMzEpy6/9hWCKK+8bjkbcFnR7y9n N3RQcLiM8whO5aJMHeS2Pcxybco3oZI4z66CjbVj3nvcX4f824hNKRu6h5QH+1KkZ7So s2+zRDf6tKhZg4fifN8byVWHtyIV45JitGQioT0mh+aztPSwHYmOKBPK7LposUEJJWMq BEMmFMiLi26sNS8mOWlo+1muQdqpj5CGfuzvJexbUCwkQuellgHZqRfUW1SJi2KOVawV i0jQ== X-Gm-Message-State: ALoCoQmlF5o+lHXh9UgECosx52zOG7JFf19X1VDQj1B7rxwLTbUfwpyLgyDVXFWBgErdZhWYu7Bq X-Received: by 10.140.133.18 with SMTP id 18mr7082653qhf.84.1431623042481; Thu, 14 May 2015 10:04:02 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCOZ9t1S+3gOosCSGSW1Cp+wgg9ww== Date: Thu, 14 May 2015 13:04:01 -0400 Message-ID: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests 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, 14 May 2015 17:04:05 -0000 Hi, Concerning RFC 7118, "wss" was not defined as a transport for SIP-URI. If dialog setup with "transport=ws" as a SIP-URI parameter within Contact or Record-Route entry when the connection is actually secured using wss (such as within RFC 7118 section 8.2 example), should wss continue to be used? Based upon RFC 7118 section 8.2 example (such as ACK sent over wss), I assume yes; however I didn't notice anything within RFC 7118 discussing the topic. Thanks, Brett P.S. Trying here since no reply received on sip-implementors. From nobody Mon May 18 08:53:11 2015 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 5A34A1AC435 for ; Mon, 18 May 2015 08:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.821 X-Spam-Level: X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 NZVgnIRSVGTt for ; Mon, 18 May 2015 08:53:02 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 58AB61AC434 for ; Mon, 18 May 2015 08:53:00 -0700 (PDT) Received: by lagr1 with SMTP id r1so145108447lag.0 for ; Mon, 18 May 2015 08:52:58 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=8CTPcu+VPR4I8w3XXXuo89Ro7mYVNxHr9gyoZFTAqUE=; b=AVl6f1Okzcb5HGzBgyXKu4HgeJx5iHp2COoYqpeghqLtH6Itw8fTGNZvjlejD45XI5 T8l9UbSXdY4LOBK6imtU74g34pr1RHnbAdJtbZhylg0HdKXwHoO4M2EktX5Btk2SW+X9 NRAGn5C/tUk8ZRtmpWvu5J/CPsotIGKEbVI5a8MM/G1KFdcU3CXwKqsi979N13enpYt7 d1xaEZEeUMAvljtzcXqKhTbvSUvUBU6eh4kx0deS4LreMpcApgRgjc6LAzTShyH2FRqh ALmiIDXRwe80IaVa175Elpco8qeDYpoFCE9D/X0fg9PK945UTCFg+kwxF6vnjAlOLX/q nV8Q== X-Gm-Message-State: ALoCoQkwriJhfmBfnZJzbgMchyHrnrdAwFBFxEBv2OdMMYBQc478KV/VV8585FE5Fes335cgHCl1 X-Received: by 10.152.28.73 with SMTP id z9mr17633669lag.93.1431964378749; Mon, 18 May 2015 08:52:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.91 with HTTP; Mon, 18 May 2015 08:52:38 -0700 (PDT) In-Reply-To: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> References: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 18 May 2015 17:52:38 +0200 Message-ID: To: Brett Tate Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests 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: Mon, 18 May 2015 15:53:03 -0000 2015-05-14 19:04 GMT+02:00 Brett Tate : > Concerning RFC 7118, "wss" was not defined as a transport for SIP-URI. I= f > dialog setup with "transport=3Dws" as a SIP-URI parameter within Contact = or > Record-Route entry when the connection is actually secured using wss (suc= h > as within RFC 7118 section 8.2 example), should wss continue to be used? > Based upon RFC 7118 section 8.2 example (such as ACK sent over wss), I > assume yes; however I didn't notice anything within RFC 7118 discussing > the topic. Hi, my opinion (based on so many old threads about secure SIP transport, "tls" and "wss") is that this is not a specific issue in RFC 7118, but in the whole "secure SIP design". The only way to mandate a secure SIP full path is by using the sips schema, but sips is just broken. I'm pretty sure that the same issue reported here about "wss" also applies to "tls". RFC 7118 does not attempt to make any change on this subject. --=20 I=C3=B1aki Baz Castillo From nobody Tue May 19 06:38:34 2015 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 C35121B2F19 for ; Tue, 19 May 2015 06:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.621 X-Spam-Level: * X-Spam-Status: No, score=1.621 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 IJJ1Vrj64Ty3 for ; Tue, 19 May 2015 06:38:29 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (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 A9E171B2EF1 for ; Tue, 19 May 2015 06:36:54 -0700 (PDT) Received: by qgde91 with SMTP id e91so7064904qgd.0 for ; Tue, 19 May 2015 06:36:53 -0700 (PDT) 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:content-type; bh=RD6Bmjwo1h1UAyKY9YDm3x4dmRGEgRQkMC5+7SmYrhg=; b=KcVsaxT9OSKTtlE0QIpzx5sQ1ONGtkpPoXvCxMklJAkQN/KpnWdxh7qyjrmh2Qit2h xp5r6cIMeFcJloBE+8sxL2JpIoQkUsyE/CN00btM2jjyTQSr2w2JKCE2mhxVRVtB8ghv aVxuuchWlR80BS1So7W1i9Sn4IbI3mOiu3oCqvgzpY0wUMjbuPAU8eNfzFwxKy6d16YK pWwNKKTdzUVUKAfn94YDdd9G3LVSTdZx/QKVlwFHbmLwvVv/EZCl9wg6IxH92daFeKAX pdmihBOEttSc9G87pkJ8TtXtXldDhYa3c9BkPpuuAhvCGI+Vgd+6E8SHrLBzhKVn0lzd U85Q== X-Gm-Message-State: ALoCoQnaRrmEKW8PZM8mC/ExBzEi6wtfmiRXYa0gCahcLkRTQQzln4zkqTr4W+4Ly2+PmPzdokh2 X-Received: by 10.140.41.104 with SMTP id y95mr35466489qgy.28.1432042613758; Tue, 19 May 2015 06:36:53 -0700 (PDT) From: Brett Tate References: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIklay2fMG+VThgjQBl+03nnLqFMwGu1CNwnM2alDA= Date: Tue, 19 May 2015 09:36:53 -0400 Message-ID: <2873b76f4b64c5ab6b5bf9e200c23667@mail.gmail.com> To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests 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, 19 May 2015 13:38:33 -0000 Hi, Thanks for the response. Reply is inline. > > Concerning RFC 7118, "wss" was not defined as a transport > > for SIP-URI. If dialog setup with "transport=ws" as a > > SIP-URI parameter within Contact or Record-Route entry > > when the connection is actually secured using wss (such > > as within RFC 7118 section 8.2 example), should wss > > continue to be used? Based upon RFC 7118 section 8.2 > > example (such as ACK sent over wss), I assume yes; however > > I didn't notice anything within RFC 7118 discussing the > > topic. Based upon recent discussion on sip-implementors, it sounds like errata should be opened against the RFC 7118 section 8.2 example. I haven't noticed anything within RFC 7118 (or RFC 5626) which would allow Alice to send ACK (for 2xx) using wss when the Record-Route entry indicated transport=ws. The errata would be to 1) fix the example, 2) add normative text to allow it to be compliant, or 3) mention using a "local policy" to determine the transport (which appears to comply with RFC 3261). The following section 5.5 snippet potentially indicates why the example doesn't rely upon NAPTR/SRV to continue to use wss. "At the time this document was written, DNS NAPTR/Service Record (SRV) queries could not be performed by commonly available WebSocket client stacks (in JavaScript engines and web browsers)." > Hi, my opinion (based on so many old threads about secure > SIP transport, "tls" and "wss") is that this is not a > specific issue in RFC 7118, but in the whole "secure SIP > design". The only way to mandate a secure SIP full path is > by using the sips schema, but sips is just broken. > > I'm pretty sure that the same issue reported here about > "wss" also applies to "tls". RFC 7118 does not attempt to > make any change on this subject. I'm not sure that I understand the response. RFC 5630 discusses the transport=tls deprecation; I assume transport=wss was not added for similar reasons. Based upon the following thread, sips support doesn't appear to be very common. If not using sips, the RFC 7118 section 8.2 example would need to supply a Record-Route entry which relies upon NAPTR/SRV usage to select wss. http://www.ietf.org/mail-archive/web/sipcore/current/msg06562.html Thanks, Brett From nobody Tue May 19 06:48:52 2015 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 85CAB1B2F43 for ; Tue, 19 May 2015 06:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.622 X-Spam-Level: * X-Spam-Status: No, score=1.622 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 KmEggm_9nXen for ; Tue, 19 May 2015 06:48:46 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 73B441B2F40 for ; Tue, 19 May 2015 06:48:32 -0700 (PDT) Received: by laat2 with SMTP id t2so24928023laa.1 for ; Tue, 19 May 2015 06:48:30 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=0q2GAiW5kTfiTIAqmZnRcnqlQIp7TYEjZoY2bm6PmYs=; b=Vtk5bW6o5yw73QYYJDEko4EHTYDLVoZircp8Wi34TPnftSzLCcpA0ueNQ3XUzp0XXr 8iG/qCmgighFqVxoIeKaSRWqlgmRFimlWQdTGRrDxD2FXe6F5ir9YLkFqg/+uWFs3Omi jZW9lprtjQuFOquZ85i3dvDEshcDkv3RhRqDPFO+z9QEM/gADeXfQ+NX3ONIrsZ1+y07 /hjp5yJZ4JbmcwbNS0lHOhr1jc5gZxeirO0xnLOZgP8PurT3T02aihoEDAfOGtGdXk6I 1VRIemHATRVJhydCrhEVFGRIj2wsMfdmDb5kwIfmeML0ShH+afAUIGmowe3Gt+EYP7ND K7qA== X-Gm-Message-State: ALoCoQnv0pQEsslbgWWW8iC4wbB4mVuQi188VohSIvB4xypzAaNueFHpQVRMvFbaiPQevRTiHh+9 X-Received: by 10.152.243.9 with SMTP id wu9mr21356916lac.63.1432043310376; Tue, 19 May 2015 06:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.91 with HTTP; Tue, 19 May 2015 06:48:09 -0700 (PDT) In-Reply-To: <2873b76f4b64c5ab6b5bf9e200c23667@mail.gmail.com> References: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> <2873b76f4b64c5ab6b5bf9e200c23667@mail.gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 19 May 2015 15:48:09 +0200 Message-ID: To: Brett Tate Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests 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, 19 May 2015 13:48:52 -0000 2015-05-19 15:36 GMT+02:00 Brett Tate : > Hi, > > Thanks for the response. Reply is inline. > >> > Concerning RFC 7118, "wss" was not defined as a transport >> > for SIP-URI. If dialog setup with "transport=3Dws" as a >> > SIP-URI parameter within Contact or Record-Route entry >> > when the connection is actually secured using wss (such >> > as within RFC 7118 section 8.2 example), should wss >> > continue to be used? Based upon RFC 7118 section 8.2 >> > example (such as ACK sent over wss), I assume yes; however >> > I didn't notice anything within RFC 7118 discussing the >> > topic. > > Based upon recent discussion on sip-implementors, it sounds like errata > should be opened against the RFC 7118 section 8.2 example. I haven't > noticed anything within RFC 7118 (or RFC 5626) which would allow Alice to > send ACK (for 2xx) using wss when the Record-Route entry indicated > transport=3Dws. http://tools.ietf.org/html/rfc5630#section-3.1.3 (note that RFC 5630 updates RFC 3261) ---------------- If one wants to use "best-effort TLS" for SIP, one just needs to use a SIP URI, and send the request over TLS. Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the header fields in a SIP message (From, To, Request-URI, Contact header field, Route, etc.). When TLS is used, the Via header field indicates TLS. ---------------- So the client just needs to follow same criteria for the ACK (same criteria it decided for sending the initial INVITE). > The errata would be to 1) fix the example, How? The example is valid according to RFC 5630 section 3.1.3 above. One may suggest that the Record-Route added by the proxy should have sips schema rather than sip, but that would be incorrect as sips means "sips all the path". > 2) add normative text to allow it IMHO there is something to fix or properly document, but again: not an issue in RFC 7118. The very same scenario would apply if you take example 8.2 in RFC 7118 and replace "ws" with "tcp" and "WSS" with "TLS". It is the SIP secure transport mechanism what is broken. > or 3) mention using a "local policy" to determine the > transport (which appears to comply with RFC 3261). I expect that is already stated by RFC 5630 section 3.1.3. In any case, I think that should be specified in that RFC.. > The following section 5.5 snippet potentially indicates why the example > doesn't rely upon NAPTR/SRV to continue to use wss. > > "At the time this document was written, DNS NAPTR/Service Record > (SRV) queries could not be performed by commonly available > WebSocket client stacks (in JavaScript engines and web browsers)." Neither RFC 5630 section 3.1.3 relies on DNS NAPTR/SRV records. >> Hi, my opinion (based on so many old threads about secure >> SIP transport, "tls" and "wss") is that this is not a >> specific issue in RFC 7118, but in the whole "secure SIP >> design". The only way to mandate a secure SIP full path is >> by using the sips schema, but sips is just broken. >> >> I'm pretty sure that the same issue reported here about >> "wss" also applies to "tls". RFC 7118 does not attempt to >> make any change on this subject. > I'm not sure that I understand the response. RFC 5630 discusses the > transport=3Dtls deprecation; I assume transport=3Dwss was not added for s= imilar > reasons. Yes. Best regards. --=20 I=C3=B1aki Baz Castillo From nobody Tue May 19 11:38:11 2015 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 0CFD81A1BB5 for ; Tue, 19 May 2015 11:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.82 X-Spam-Level: X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 bCxXBR-FnVac for ; Tue, 19 May 2015 11:38:09 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 974D11A0047 for ; Tue, 19 May 2015 11:38:09 -0700 (PDT) Received: by qgew3 with SMTP id w3so12106027qge.2 for ; Tue, 19 May 2015 11:38:08 -0700 (PDT) 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:content-type; bh=0DTVmpe+1ufKXF/J+6j3cohEedwgXcEFzhYlKcPzDig=; b=bSi7obh4GH+sG7BCoZ2hlrb3zWk1C6OsWGIV3dp+C5OzJvgTiA7Z/YWiwoEYTHogFE fzkJoAMIvgUTT+k811xOB5WChwsmaB3ZPTN7NfZ+LZRwH4bWgmMQdFoJ3fI7zn9O3gpy Qpr3POqF5hKc68TPRt0YE5xGlWwOZbPcKPD9aojhcpSynMkdbtiSVCbJPUSbhZv04Wyd 9cWRV298Lp5AID3Rjd3nTbCMw75cq5MLkJZFlFuFe24AiUenyEIQ8mjWru3tTulsYLaX 8IMtvTVugOf1X4XrIXYVZxGEvbqVpVF125cbrMww8dKMD5+10in4l5ExSa7bTx2eK5zj tBYg== X-Gm-Message-State: ALoCoQn7uemBj/OwmhzPxAUB2ZyS4ThFBjXGlWVZQIayitaRyn5KbhZ35be41WI3KeHKEN7kExSJ X-Received: by 10.55.22.3 with SMTP id g3mr62253284qkh.54.1432060688715; Tue, 19 May 2015 11:38:08 -0700 (PDT) From: Brett Tate References: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> <2873b76f4b64c5ab6b5bf9e200c23667@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIklay2fMG+VThgjQBl+03nnLqFMwGu1CNwAhZXaZgBSj+r9pyy9Dww Date: Tue, 19 May 2015 14:38:07 -0400 Message-ID: <14aa22e39d0524da14b4c42e6e61b5d5@mail.gmail.com> To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests 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, 19 May 2015 18:38:11 -0000 Hi, Thanks for the response; reply is inline. > > Based upon recent discussion on sip-implementors, it sounds like > > errata should be opened against the RFC 7118 section 8.2 example. I > > haven't noticed anything within RFC 7118 (or RFC 5626) which would > > allow Alice to send ACK (for 2xx) using wss when the Record-Route > > entry indicated transport=ws. > > http://tools.ietf.org/html/rfc5630#section-3.1.3 > > (note that RFC 5630 updates RFC 3261) > > ---------------- > If one wants to use "best-effort TLS" for SIP, one just needs to use > a SIP URI, and send the request over TLS. > > Using SIP over TLS is very simple. A UA opens a TLS connection and > uses SIP URIs instead of SIPS URIs for all the header fields in a SIP > message (From, To, Request-URI, Contact header field, Route, etc.). > When TLS is used, the Via header field indicates TLS. > ---------------- > > So the client just needs to follow same criteria for the > ACK (same criteria it decided for sending the initial INVITE). AFAIK, that quote doesn't mean to disregard the RFC 3263 rules concerning transport selection. For instance concerning mid-dialog requests, I don't think that snippet indicates that it is appropriate to attempt TLS when the Record-Route SIP-URI contains port and transport TCP. However, a local policy could cause such behavior. > > The errata would be to 1) fix the example, > > How? It looks like removing port 443 works; however it relies upon using SRV. I actually like the example as it is. I'm just not sure I'd be able to defend the behavior since I think RFC 3263 indicates that it should cause transport "ws" (instead of "wss") to be used. > > 2) add normative text to allow it > > IMHO there is something to fix or properly document, but > again: not an issue in RFC 7118. The very same scenario > would apply if you take example 8.2 in > RFC 7118 and replace "ws" with "tcp" and "WSS" with "TLS". AFAIK, the mentioned replacement has the same issue. From nobody Thu May 21 07:26:48 2015 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 AFF3A1A1AB3 for ; Thu, 21 May 2015 07:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 YkQy_euwdU0r for ; Thu, 21 May 2015 07:26:47 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 F2BDE1A1AA8 for ; Thu, 21 May 2015 07:26:36 -0700 (PDT) Received: by labbd9 with SMTP id bd9so104737861lab.2 for ; Thu, 21 May 2015 07:26:35 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=twQSmcwdFnmFWGK7/ijwr7Qm28xVPOf7fC1UFWDervc=; b=I/xHltnyHaZE+tj9adi4acqykFHCMRnumz+ZQv5KLbS+4+m2IFCboVhpT8c1tVR2Rv JnEc5OxOzSNAma9GvLcMEia2BhfKjbh97fk9WJ+9wCDdbGBVG/ZbF/lFYqzw615swM0Q 7X3imf/dfubXlTqgZTBEmXmCGzbG5xhdmwlc+/7LBqbRs6NA/fbrElpHQatr3P7uwxwy O8EncdNcHSv0exQK5c94gRM83E1qL5jcaFylSp4sDl1E898bRLwFmgjkZy+KyyHzrRT9 ONhvOHw/pmlX97CWc6WDBFxyxmHd0TeWaKM0zuiuyrj+WfcKaQ7GFEo3fUmKd5Vta8QR Ielg== X-Gm-Message-State: ALoCoQlVqBvQfS8KxWl1ACmMLAEHt3MqltXiFkJGAxztLU9B6ZJNmcgzThty1f9H8qHVslalMsaM X-Received: by 10.152.246.34 with SMTP id xt2mr2490851lac.110.1432218395482; Thu, 21 May 2015 07:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.91 with HTTP; Thu, 21 May 2015 07:26:15 -0700 (PDT) In-Reply-To: <14aa22e39d0524da14b4c42e6e61b5d5@mail.gmail.com> References: <02e287077522f79de1fa6f1a2ffd4078@mail.gmail.com> <2873b76f4b64c5ab6b5bf9e200c23667@mail.gmail.com> <14aa22e39d0524da14b4c42e6e61b5d5@mail.gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 21 May 2015 16:26:15 +0200 Message-ID: To: Brett Tate Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] RFC 7118: impacts of transport=ws on mid-dialog requests 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, 21 May 2015 14:26:47 -0000 2015-05-19 20:38 GMT+02:00 Brett Tate : >> > The errata would be to 1) fix the example, >> >> How? > > It looks like removing port 443 works; however it relies upon using SRV. > > I actually like the example as it is. I'm just not sure I'd be able to > defend the behavior since I think RFC 3263 indicates that it should cause > transport "ws" (instead of "wss") to be used. Right, but as said in my other email, note that this is about an Outbound connection which is supposed to remain open and reused for all future requests. The problem is that, if the client follows RFC 5630 section 3.1.3 to send the initial INVITE there is no way for the proxy to "let" the client reuse the same connection for in-dialog requests, which breaks RFC 5626 somehow. >> > 2) add normative text to allow it >> >> IMHO there is something to fix or properly document, but >> again: not an issue in RFC 7118. The very same scenario >> would apply if you take example 8.2 in >> RFC 7118 and replace "ws" with "tcp" and "WSS" with "TLS". > > AFAIK, the mentioned replacement has the same issue. That's why I still think that the issue should not be placed at RFC 7118, but I may be wrong. --=20 I=C3=B1aki Baz Castillo From nobody Fri May 29 15:00:45 2015 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 D60581A879B for ; Fri, 29 May 2015 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Q24pcktBR45K for ; Fri, 29 May 2015 09:11:12 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 6F9DD1A87E7 for ; Fri, 29 May 2015 09:11:12 -0700 (PDT) Received: by obbnx5 with SMTP id nx5so60726426obb.0 for ; Fri, 29 May 2015 09:11:12 -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:content-type; bh=sOOdEEP+9FLRcfjLiblOIcJ9s/KeseqRl5yxHggmm0Y=; b=JRxrN2yvky+JekVL947wR3JHtbiJETCsmRYVagKevoMGsb8PYp+knQS+s2WSge56N8 HSpwCKUdisDUltf2iO5bdnrWh9pQ2yFl7jhSeEQ9B4hIxgN152EgtI+lul9BFLlApXXM Qsj6gpvoz8hxNUAEklJsM5H4fcN2PjN95+rAcJLun9ZjPS4MXPQL8Q4nPoV4lD0AMJZx U7c1g8HmP5JfisSIBBJ1NRXtCi2cvGq1EHGByIR9hAxtLt7cG6SXv833aqO7MgMyS1z4 cZ3c0uaf6dTjNET3xAwO6nmZFelQcDrLTD2poAIZdZm3f8ZmfEI93S30bSiUEYf4Lhnj 4HfA== MIME-Version: 1.0 X-Received: by 10.202.203.77 with SMTP id b74mr7226849oig.1.1432915871953; Fri, 29 May 2015 09:11:11 -0700 (PDT) Received: by 10.202.108.150 with HTTP; Fri, 29 May 2015 09:11:11 -0700 (PDT) Date: Fri, 29 May 2015 21:41:11 +0530 Message-ID: From: Ambrish Kumar To: sip-implementors@lists.cs.columbia.edu, sipcore@ietf.org Content-Type: multipart/alternative; boundary=001a1134fb448a7aac05173ab951 Archived-At: X-Mailman-Approved-At: Fri, 29 May 2015 15:00:44 -0700 Subject: [sipcore] When Does RTP should start flowing after 18x or 200OK/ACK 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, 29 May 2015 16:11:14 -0000 --001a1134fb448a7aac05173ab951 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Team, I am working on Lawful interception and integrating our IMS nodes (SBC) with LEA. We have got a very unusual ask form IB/RAW where they want to listen the RTP flow before call is actually answered by =E2=80=9CB=E2=80=9D We need your help and confirmation from any RFC which clarifies when does Media should start flowing in network : 1. Is it possible RTP media should start flowing right after offer-answer model is completed say after 18x response? 2. Or RTP Media should start flowing after 200 OK ACK response. I know most of implementation start pushing media after 200 OK ACK. But does standard mandates to start flow TWO WAY RTP right after offer-answer model is completed. Regards, Ambrish --001a1134fb448a7aac05173ab951 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Team,

I=C2=A0 am workin= g on Lawful interception and integrating =C2=A0our IMS nodes (SBC) with LEA= . We have got a very unusual ask form IB/RAW where they want to listen the = RTP flow before call is= actually answered by =E2=80=9CB=E2=80=9D

= We need your help and confirmation from=C2=A0any RFC which clarifies=C2=A0w= hen does Media should start flowing in network :
1. Is it possibl= e=C2=A0RTP media should start flowing right after offer-answer model is com= pleted say after 18x response?

2. Or=C2=A0RTP Medi= a should start flowing after=C2=A0200=C2=A0OK ACK response.
=C2= =A0
I= =C2=A0=C2=A0 know most of implementation start pushing media after 200 OK A= CK. But does standard mandates to start flow TWO WAY RTP right after offer-= answer model is completed.

Regards,
Ambrish
--001a1134fb448a7aac05173ab951-- From nobody Fri May 29 15:17:14 2015 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 D898A1A898C for ; Fri, 29 May 2015 15:17:12 -0700 (PDT) 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 mRQxK98iACQ2 for ; Fri, 29 May 2015 15:17:11 -0700 (PDT) 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 3B96D1A897F for ; Fri, 29 May 2015 15:17:11 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-11v.sys.comcast.net with comcast id ZyHA1q0052Qkjl901yHAn2; Fri, 29 May 2015 22:17:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id ZyH91q00h3Ge9ey01yHAAS; Fri, 29 May 2015 22:17:10 +0000 Message-ID: <5568E564.2020709@alum.mit.edu> Date: Fri, 29 May 2015 18:17:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ambrish Kumar References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1432937830; bh=KfJSOMHkHSupakSLCA+8wVUMYONOAOhQDoR4P9Qz+AU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DAnm+FhChLafMndrMcCn9uqON2zda49ZcX11dR88GwWWNx17LE90Oc1bpNyh0M1ln uYD+ZPnccjiQZV1NOvjV7dD7tjdSezymyo2cnoGNKixjVsJTpYntKw3enm/pEAcNmO mHaFgpppKBedGwUtTcJqxz1+lLjNkbEVji9u50goHNhWCmgUCX0jgi1qHQZV16R6lA b3POSCoxpQAGcmPfW0z/AxmTM/dt2qlWVabbtFKpxvyTEm+UboBfsIm5kLLu4Y5kmp UHfXNKytuCoaffJr6gmrt++jXsd5FpRKcPSzC8ITt+pjg8zjfibsrxkPFynAnb8pOS kYKTaoQgD1kFA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] When Does RTP should start flowing after 18x or 200OK/ACK 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, 29 May 2015 22:17:13 -0000 Ambrish, You sent this to sip-implementors (the proper place for such a query). And I replied to you there. Sending it to sipcore is/was not appropriate for questions like this, and is annoying to the people on the sipcore list (since most of them are probably on sip-implementors too.) Thanks, Paul On 5/29/15 12:11 PM, Ambrish Kumar wrote: > Dear Team, > > I am working on Lawful interception and integrating our IMS nodes > (SBC) with LEA. We have got a very unusual ask form IB/RAW where they > want to listen the RTP flow before call is actually answered by “B” > > We need your help and confirmation from any RFC which clarifies when > does Media should start flowing in network : > 1. Is it possible RTP media should start flowing right after > offer-answer model is completed say after 18x response? > > 2. Or RTP Media should start flowing after 200 OK ACK response. > I know most of implementation start pushing media after 200 OK ACK. > But does standard mandates to start flow TWO WAY RTP right after > offer-answer model is completed. > > Regards, > Ambrish > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >